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. Otherwise a user-defined type could
fool this logic with a malicious choice of typcategory. jsonb itself was
darn close to being a "malicious choice of typcategory" --- it's entirely
accidental that Michael's example didn't lead to a crash or even more
interesting stuff, since the code was trying to process a jsonb as though
it were a regular composite type. Other choices of typcategory could have
sent the code into the array path for something that's not an array, or
have allowed escaping to be bypassed for something that's not json, etc.
In short, there are defined ways to decide if a type is array or
composite, and this ain't how.
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.
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?
regards, tom lane