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
>
>
>
