From: | Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
---|---|
To: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PavelStehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |
Date: | 2012-05-01 15:49:28 |
Message-ID: | CAARyMpA6sPU2pyEjeybU+5KUCi+EnWuSTHqB5uuCZPR63wO7Hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing <hannu(at)2ndquadrant(dot)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 <hannu(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-05-01 16:02:18 | Re: proposal: additional error fields |
Previous Message | Andres Freund | 2012-05-01 15:42:45 | Re: extending relations more efficiently |