On Tue, 2012-05-01 at 09:22 -0700, Andrew Dunstan wrote: > > > On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure <mmonc...@gmail.com> > wrote: > On Tue, May 1, 2012 at 10:49 AM, Joey Adams > <joeyadams3.14...@gmail.com> wrote: > > On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing > <ha...@2ndquadrant.com> wrote: > >> Hi hackers > >> > >> After playing around with array_to_json() and row_to_json() > functions a > >> bit it I have a question - why do we even have 2 variants > *_to_json() > > > > Here's the discussion where that decision was made: > > > > > http://archives.postgresql.org/pgsql-hackers/2012-01/msg01339.php > > > > To quote: > > > >>>> why not call all these functions 'to_json' and overload > them? > >>> > >>> I don't honestly feel that advances clarity much. And we > might want to overload each at some stage with options that > are specific to the datum type. We have various foo_to_xml() > functions now. > >> > >> -1 > >> > >> older proposal is more consistent with xml functions > > > > The most compelling argument I see here is the one about > options > > specific to the datum type. > > > I don't find that to be particularly compelling at all. > to_timestamp > for example supports multiple argument versions depending on > the input > type. > > > * If the JSON type does not yet support, say, converting > from a > > number, it will be apparent from the names and types of the > functions, > > rather than being a hidden surprise. On the other hand, > array_to_json > > and composite_to_json already convert ANY values to JSON, so > this > > doesn't matter, anyway. > > > > I am away from base on a consulting assignment all this week, so my > connectivity and time are severely limited, and I don't have time to > respond in depth. > > Let me just point out two things. First, we are approaching a beta > release. The time for changing this is long since gone, IMNSHO.