Re: JSON output functions.

From: Stefan Keller <sfkeller(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, postgis-devel(at)postgis(dot)refractions(dot)net
Subject: Re: JSON output functions.
Date: 2012-02-05 19:31:02
Message-ID: CAFcOn29irgHpD6PPyx7oOb2qU1HUrVD51FA8e-8K9xE9kFG5Qg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Andrew

Nice work!

Just for completeness: Did you also think of including geometry types
in JSON output functions in later releases? There's a nice extension
of JSON called GeoJSON for a starting point.

Yours, Stefan

2012/2/3 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>
> On 02/02/2012 12:20 PM, Pavel Stehule wrote:
>>
>> 2012/2/2 Andrew Dunstan<andrew(at)dunslane(dot)net>:
>>>
>>>
>>> On 02/02/2012 04:35 AM, Abhijit Menon-Sen wrote:
>>>>
>>>> At 2012-02-01 18:48:28 -0500, andrew(dot)dunstan(at)pgexperts(dot)com wrote:
>>>>>
>>>>> For now I'm inclined not to proceed with that, and leave it as an
>>>>> optimization to be considered later if necessary. Thoughts?
>>>>
>>>> I agree, there doesn't seem to be a pressing need to do it now.
>>>>
>>>
>>> OK, here's my final version of the patch for constructor functions. If
>>> there's no further comment I'll go with this.
>>
>> These function are super, Thank you
>>
>> Do you plan to fix a issue with row attribute names in 9.2?
>
>
>
>
> Yeah. Tom did some initial work which he published here:
> <http://archives.postgresql.org/message-id/28413.1321500388%40sss.pgh.pa.us>,
> noting:
>
>   It's not really ideal with respect to
>   the ValuesScan case, because what you get seems to always be the
>   hard-wired "columnN" names for VALUES columns, even if you try to
>   override that with an alias
>   ...
>   Curiously, it works just fine if the VALUES can be folded
>
> and later he said:
>
>   Upon further review, this patch would need some more work even for the
>   RowExpr case, because there are several places that build RowExprs
>   without bothering to build a valid colnames list.  It's clearly soluble
>   if anyone cares to put in the work, but I'm not personally excited
>   enough to pursue it ..
>
> I'm going to look at that issue first, since the unfolded VALUES clause
> seems like something of an obscure corner case. Feel free to chime in if you
> can.
>
>
> cheers
>
>
> andrew
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-05 19:50:20 Re: initdb and fsync
Previous Message Tom Lane 2012-02-05 19:18:42 Report: race conditions in WAL replay routines