From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Subject: | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |
Date: | 2012-05-04 16:30:39 |
Message-ID: | 4FA4042F.3040007@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/04/2012 09:52 AM, Tom Lane wrote:
> Hannu Krosing<hannu(at)2ndQuadrant(dot)com> writes:
>> On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
>>> So given that do we do anything about this now, or wait till 9.3?
>> I'd like the json support in 9.2 updated as follows
> I think it's too late to be entertaining proposals for such changes in
> 9.2. If we had concluded that the existing functions were actively
> wrong or a bad idea, then of course we'd need to do something; but they
> are not, so we can just as well consider additions in the 9.3 cycle
> rather than now. I am not convinced that this proposal is fully baked
> yet, anyway; not to mention that right now we need to have our heads
> down on resolving the remaining open issues, not designing,
> implementing, and reviewing a pile of brand new code for json.
Yeah, that was my feeling. We usually take a release or two to get
things right, fill in what's missing, etc. and I don't think this will
be ant different.
>
>> By allowing developers just to define their own to_json(date) function
>> we give them the power do decide which one to use. And if we honour
>> search_path when looking up the to_json() functions, then they can even
>> choose to have different conventions for different applications.
> This is not going to work anywhere near as nicely as you think. If
> somebody tries to define multiple to_json() functions that override a
> generic to_json(anyelement) one, he will start getting "function is not
> unique" parse failures. The parser will only successfully decide which
> function to call when the input data type exactly matches one of the
> specialized functions, which means you might as well not have the
> generic one at all.
>
>
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-05-04 16:34:22 | Re: Beta time? |
Previous Message | Robert Haas | 2012-05-04 16:29:33 | Re: Future In-Core Replication |