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

From Tom Lane
Subject Re: row_to_json bug with index only scans: empty keys!
Date
Msg-id 22920.1415468428@sss.pgh.pa.us
Whole thread Raw
In response to Re: row_to_json bug with index only scans: empty keys!  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: row_to_json bug with index only scans: empty keys!  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add CREATE support to event triggers
Next
From: Andrew Dunstan
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!