On 2014-05-09 10:07:10 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> >> b) datum_to_json() thinks it's a good idea to use typcategory to decide
> >> how a type is output. Isn't that pertty fundamentally flawed?
>
> > Indeed. I think the bit that uses TYPCATEGORY_NUMERIC as a hint to decide
> > whether the value can be left unquoted (assuming it looks like a number)
> > might be all right, but the rest of this seems pretty bogus.
>
> Actually, that would be a security hole if it weren't that CREATE TYPE for
> new base types is superuser-only.
Yea. I actual wonder why CREATE TYPE seems to allow createing
TYPCATEGORY_COMPOSITE types - there really doesn't seem to be a usecase.
> After further reflection I think we should lose the TYPCATEGORY_NUMERIC
> business too. ruleutils.c hard-wires the set of types it will consider
> to be numeric, and I see no very good reason not to do likewise here.
> That will remove the need to look up the typcategory at all.
Maybe we should expose that list or the functionality in a neater way?
It's already been copied to test_decoding...
> So we need to:
>
> 1. Refactor so there's only one copy of the control logic.
>
> 2. Smash domains to their base types.
>
> 3. Identify boolean, numeric, and json types by direct tests of type OID.
>
> 4. Identify array and composite types using standard methods.
>
> Anybody see other problems to fix here?
Yea.
5) if (val_type > FirstNormalObjectId)
isn't fundamentally incorrect but imo shouldn't be replaced by something
like !IsCatalogType() (akin to IsCatalogRelation). At least if we decide
that hunk is safe from other POVs - I am not actually 100% sure yet.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services