Hannu Krosing <hannu@2ndQuadrant.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.
> 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.
regards, tom lane