Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Дата
Msg-id CA+TgmoaqXDmXN-D0eX6+rF2r-189oa9oToC7a2gKjMeFRK0YVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Список pgsql-hackers
On Fri, May 4, 2012 at 12:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Yeah, what I've been thinking about in conjunction with similar problems
>> is some sort of type registry, so that we could code for non-builtin
>> types in certain cases. Maybe we should add that the the developers'
>> meeting agenda.
>
> Maybe.  I don't want to see a json-specific hack for this, but some sort
> of generic way to add type knowledge could be useful, if we could figure
> out what we want.

For this particular case, I think you just need some place to store a
pg_type -> pg_proc mapping.  I'm not exactly sure how to make that not
a JSON-specific hack, since I certainly don't think we'd want to add a
new catalog just for that.

In general, I think it would be very useful to have some way of
identifying particular types - and versions of types - independently
of a particular installation - e.g. by assigning each type a UUID that
never changes and a version number that we bump when we change
something about that type.  That seems like it would be very useful
for schema comparison tools, or for logical replication, where you
want to know whether two types are "the same type" even though they
are in different clusters.  pg_upgrade has had past needs in this area
as well.  However, I'm not sure that'd help solve this particular
problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Future In-Core Replication
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: remove dead ports?