On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> 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,
I think that hard-coding "postgresql text" representation as our json
representation without a possibility for the user tio easily fix it
without rewriting foll xx_to_json() functions is borderline "actively
wrong".
Can we at least have the xxx_to_json() functions try cast to json first
and fall back to text if the cast fails.
This would address my worst problem, all the rest can be easily defined
in user functions.
> 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
>
