On 09/28/2012 12:42 AM, Andrew Dunstan wrote:
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 <and...@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?
as json is defined to encode only 3 base types - boolean (true/false),
number and string - and two composite types - array and "object" - it
should not be too hard to provide casts for these and then use existing
casts to go on from number and text
Something extra should probably be done for number, perhaps we need
separate casts for float and decimal/numeric but the rest should be
relatively simple.
the json null vs SQL NULL poses and interesting problem though ;)
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
