Re: row_to_json bug with index only scans: empty keys! - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: row_to_json bug with index only scans: empty keys!
Date
Msg-id 545E5AE6.9000606@dunslane.net
Whole thread Raw
In response to Re: row_to_json bug with index only scans: empty keys!  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: row_to_json bug with index only scans: empty keys!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/08/2014 12:40 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 11/08/2014 12:14 PM, Tom Lane wrote:
>>> That would be my druthers.  But given the lack of complaints, maybe we
>>> should just stick to the more-backwards-compatible behavior until someone
>>> does complain.  Thoughts?
>> Wouldn't that would mean we might not pick up the expected aliases in
>>       select row_to_json(q) from (select a,b from foo) as q(x,y)
>> ? If so, I'm definitely in favor of fixing this now.
> Well, it's inconsistent now.  In existing releases you might or might not
> get x,y:
>
> regression=# create table foo (f1 int, f2 int);
> CREATE TABLE
> regression=# insert into foo values(1,2);
> INSERT 0 1
> regression=# select row_to_json(q) from (select f1 as a, f2 as b from foo) as q(x,y);
>    row_to_json
> ---------------
>   {"x":1,"y":2}
> (1 row)
>
> regression=# select row_to_json(q) from (select f1 as a, f2 as b from foo offset 0) as q(x,y);
>     row_to_json
> -----------------
>   {"f1":1,"f2":2}
> (1 row)
>
> That seems like something that's worth fixing going forward, but it's a
> lot harder to make the case that we should change it in back branches.
>
>             

Sure. As long as we fix the empty alias issue in the back branches, just 
fixing this prospectively seems fine. But I don't think we should wait 
for more complaints.

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!
Next
From: Andres Freund
Date:
Subject: Re: Add CREATE support to event triggers