On 09/27/2012 09:22 AM, Robert Haas wrote:
On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
