On 09/27/2012 09:22 AM, Robert Haas wrote:
> On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Also, on reflection I'm not sure about commandeering cast-to-json for
>> this --- aren't we really casting to "json member" or something like
>> that? The distinction between a container and its contents seems
>> important here. With a container type as source, it might be important
>> to do something different if we're coercing it to a complete JSON
>> value versus something that will be just one member. I'm handwaving
>> here because I don't feel like going back to re-read the RFC, but
>> it seems like something that should be considered carefully before
>> we lock down an assumption that there can never be a difference.
> I feel like there are two different behaviors that someone might want
> here, and a cast cannot mean both.
[snip]
>
> 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.
[pause for another bout of vigorous self-criticism]
So how about this suggestion: we'll look for a visible function named
"as_json" or some such which has one parameter of the given type and
returns json, and if it's present use it instead of the standard text
representation. As an optimization we'll skip that lookup for builtin
types, since there won't be one. Of course, we'll have one for hstore.
cheers
andrew