Re: JSON output functions. - Mailing list pgsql-hackers

From Stefan Keller
Subject Re: JSON output functions.
Date
Msg-id CAFcOn29irgHpD6PPyx7oOb2qU1HUrVD51FA8e-8K9xE9kFG5Qg@mail.gmail.com
Whole thread Raw
In response to Re: JSON output functions.  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: JSON output functions.
List 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@dunslane.net>:
>
>
> On 02/02/2012 12:20 PM, Pavel Stehule wrote:
>>
>> 2012/2/2 Andrew Dunstan<andrew@dunslane.net>:
>>>
>>>
>>> On 02/02/2012 04:35 AM, Abhijit Menon-Sen wrote:
>>>>
>>>> At 2012-02-01 18:48:28 -0500, andrew.dunstan@pgexperts.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Report: race conditions in WAL replay routines
Next
From: Tom Lane
Date:
Subject: Re: initdb and fsync