Hannu Krosing <ha...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers