From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Oid registry |
Date: | 2012-09-25 22:06:19 |
Message-ID: | 50622ADB.9080307@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/25/12 5:58 PM, Tom Lane wrote:
> Yes ... but I really don't want to go down the path of treating those as
> new type properties; it doesn't scale. (And please don't tell me that
> JSON is the last word in container types and there will never be
> requests for any more of these.)
Yeah, I didn't like that part either, but we only add one every five
years or so.
> Can we define these functions as being the cast-from-foo-to-json and
> cast-from-foo-to-xml functions? That would let us use the existing cast
> infrastructure to manage them.
Sounds attractive, but there might be some problems in the details. For
example, you can't cast scalar values to valid json values, because a
valid json value can only be a dictionary or an array. If we had a flag
of some kind saying "cast from foo to json, but only when part of a
larger json serialization, not by itself", then it might work.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-25 22:22:03 | Re: Oid registry |
Previous Message | Daniel Farina | 2012-09-25 22:06:05 | Re: Switching timeline over streaming replication |