On 09/26/2012 02:48 AM, Andrew Dunstan wrote:
On 09/25/2012 08:35 PM, Peter Eisentraut wrote:
On Tue, 2012-09-25 at 18:22 -0400, Tom Lane wrote:
Actually, after reading another message you sent, I thought you were
going to respond that your proposed transforms feature would cover it.
I had thought about this some time ago, but it's clearer to think of
casts as associating two types, versus transforms associating a type and
a language. JSON and XML tend to be types.
OK, I think this solves the object_to_json problem after all - we'll
look for a cast to json and if it's not there use the string form of
the object. Nice.
This is solved then :)
Would it be possible to also use the cast mechanism to do
anyarray-to-json casts as parallel spelling for array_to_json()
and record-to-json cast for row_to_json()
btw, is anybody currently working on also going the opposite way, that
is loading rows/records from json ?
That still leaves the other uses for having well known Oids (or
possibly UUIDs) for non-builtin types (e.g. so Drivers don't have to
look them up in the catalogs, or having issues when types are added to
the core.)
One way to solve this would be to pass non-system oids to clients as
their names. this would need a change in protocol.
Or we could make it so that server sends a special record with
typename->typeoid mappings at first use of non-system type.
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
