Re: data to json enhancements - Mailing list pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/27/2012 09:22 AM, Robert Haas wrote:
>> Maybe I am being too pedantic about this and there is a way to make it
>> all work nicely, but it sure feels like using the casting machinery
>> here is blending together two different concepts that are only
>> sometimes the same.

> OK. I think that's a very good point. I guess I was kinda swept away by 
> this being suggested by a couple of influential people.

Well, that doesn't make it wrong, it just means there's more work
needed.  I'm not that thrilled with magic assumptions about function
names either; schema search path issues, for example, will make that
dangerous.  We've gone to considerable lengths to avoid embedding
assumptions about operator names, and assumptions about function names
aren't any better.

There are at least three ways we could use the cast machinery for this:

(1) Reject Robert's assumption that we have to support both
interpretations for every cast situation.  For instance, it doesn't
seem that unreasonable to me to insist that you have to cast to text
and then to json if you want the literal-reinterpretation behavior.
The main problem then is figuring out a convenient way to provide
interpretation #2 for text itself.

(2) Add another hidden argument to cast functions, or perhaps repurpose
one of the ones that exist now.  This is likely to come out rather ugly
because of the need to shoehorn it into an API that's already suffered
a couple of rounds of after-the-fact additions, but it's certainly
possible in principle.  The main thing I'd want is to not define it
in a JSON-only fashion --- so the first thing is to be able to explain
the distinction we're trying to make in a type-independent way.

(3) Invent an auxiliary type along the lines of "json_value" and say
that you create a cast from foo to json_value when you want one
interpretation, or directly to json if you want the other.  Then
things like record_to_json would look for the appropriate type of cast.
This is a bit ugly because the auxiliary type has no reason to live
other than to separate the two kinds of cast, but it avoids creating
any new JSON-specific mechanisms in the type system.

There might be some other ideas I'm not thinking of.
        regards, tom lane