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

On 09/27/2012 10:36 AM, Tom Lane wrote:
> 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.


The trouble is, ISTM, that both things seem equally intuitive. You could 
easily argue that x::text::json means take x as text and treat it as 
json, or that it means take x as text and produce a valid json value 
from it by escaping and quoting it. It's particularly ambiguous when x 
is itself already a text value. If we go this way I suspect we'll 
violate POLA for a good number of users.

>
> (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.

I agree with the "ugly" part of this analysis :-)

>
> (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.



I could accept this. The reason is that very few types are in fact going 
to need a gadget like this. Yes it's mildly ugly, but really fairly 
unobtrusive.

cheers

andrew

>
> There might be some other ideas I'm not thinking of.


Yeah. You've done better than me though :-)

cheers

andrew