Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
От | Andrew Dunstan |
---|---|
Тема | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |
Дата | |
Msg-id | CAD5tBc+qHrNKth+qT-hQmT5RTTaABfjabd-r4acLy9HdwBm7hg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: JSON in 9.2 - Could we have just one to_json() function
instead of two separate versions ?
(Merlin Moncure <mmoncure@gmail.com>)
Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? (Tom Lane <tgl@sss.pgh.pa.us>) Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? (Joey Adams <joeyadams3.14159@gmail.com>) Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
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.
Second, RFC 4627 is absolutely clear: a valid JSON value can only be an object or an array, so this thing about converting arbitrary datum values to JSON is a fantasy. If anything, we should adjust the JSON input routines to disallow anything else, rather than start to output what is not valid JSON.
cheersOn Tue, May 1, 2012 at 10:49 AM, Joey Adams <joeyadams3.14159@gmail.com> wrote:I don't find that to be particularly compelling at all. to_timestamp
> On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing <hannu@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.
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.
Second, RFC 4627 is absolutely clear: a valid JSON value can only be an object or an array, so this thing about converting arbitrary datum values to JSON is a fantasy. If anything, we should adjust the JSON input routines to disallow anything else, rather than start to output what is not valid JSON.
andrew
В списке pgsql-hackers по дате отправления: