Skip site navigation (1) Skip section navigation (2)

Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>
Cc: Hannu Krosing <hannu(at)2ndquadrant(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 16:05:06
Message-ID: CAHyXU0z1e4HfEy2GPByT5Dq-rKpEBTeLsaiQt7=97qfZXsoUJQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 1, 2012 at 10:49 AM, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
> 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.

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

In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-05-01 16:12:11
Subject: Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Previous:From: Pavel StehuleDate: 2012-05-01 16:02:18
Subject: Re: proposal: additional error fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group