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

From Robert Haas
Subject Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Date
Msg-id CA+TgmoaqXDmXN-D0eX6+rF2r-189oa9oToC7a2gKjMeFRK0YVQ@mail.gmail.com
Whole thread Raw
In response to 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>)
Responses 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 ?
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Future In-Core Replication
Next
From: Peter Eisentraut
Date:
Subject: Re: remove dead ports?