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 don't see how not having to_json(type) is any less surprising than type_to_json(). To add: Are we going to have json_length()? Why shouldn't length operate directly on the json type since it has a length? Or are we going to force an implicit cast to text? An elementary point of generic programming through SQL is that you are supposed to keep *what you are trying to do* decoupled from *what you're doing it on*. It allows for very natural and terse programming. The array, xml, and now the json apis essentially violate this principle. The array api I find particularly galling since you end up having to retype 'array' N times in a single expression. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers