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

On 09/27/2012 06:58 PM, Hannu Krosing wrote:
> On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
>>
>> 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.
> Maybe cast not to text but to cstring for getting the 
> text-is-already-json ?
>
> That is, reuse the current type io as "literal" casts.
>
> This way a cast of '{"a": 1}'::json::text will fail, as this json 
> value really does not
> represent a text/string value.
>
>>> 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.
> It may be easier to sort this out if we think in terms of symmetry and 
> unambiguity.
>
> let's postulate that mytype::json::mytype and json::mytype::json 
> should always reproduce the original result or they should fail.


Where are all these casts from json going to come from? What is going to 
dequote and unescape strings, or turn objects into hstores? You're 
making this much bigger than what I had in mind. The advantage of Tom's 
option (3) that I liked is that it is very minimal. Any type can provide 
its own function for conversion to json. If it's there we use it, if 
it's not we use its standard text representation. Let's stick to the 
KISS principle.

cheers

andrew