Re: row_to_json bug with index only scans: empty keys!
От | Tom Lane |
---|---|
Тема | Re: row_to_json bug with index only scans: empty keys! |
Дата | |
Msg-id | 22920.1415468428@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: row_to_json bug with index only scans: empty keys! (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: row_to_json bug with index only scans: empty keys!
|
Список | 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 по дате отправления: