Re: Oid registry
От | Hannu Krosing |
---|---|
Тема | Re: Oid registry |
Дата | |
Msg-id | 5062C0F6.2010607@krosing.net обсуждение исходный текст |
Ответ на | Re: Oid registry (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
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 > > >
В списке pgsql-hackers по дате отправления: