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. Two other reasons I can think of: * If someone tries to google for how to convert an array to JSON, having a function named 'array_to_json' will make that easier. * 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. On Tue, May 1, 2012 at 11:02 AM, Hannu Krosing <ha...@2ndquadrant.com> wrote: > What we currently lack is direct conversion for simple types, though > they are easily achieved by converting to a single-element array and > then stripping outer [] from the result I agree that this function ought to be exposed. Note that such a function (perhaps called datum_to_json) is indeed the same as the proposed to_json function, which tries to convert a value of any type to JSON. > It would be really nice to also have the casts from json to any type, > including records though. What the casts currently do (primarily) is convert between the TEXT and JSON types. So if you have JSON-encoded TEXT, use a cast to convert it to the JSON type (this will perform validation, ensuring that no invalid JSON gets in). Any escape/unescape operations need to be explicit. -Joey -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
