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

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

In response to

Responses

Browse pgsql-hackers by date

  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