On Tue, Aug 13, 2013 at 05:34:12PM -0400, Tom Lane wrote:
> Further poking at this issue shows that there are related behaviors that
> aren't fixed by my proposed patch. The original complaint can be
> replicated in the regression database like this:
>
> select row_to_json(i8) from (select q1 as a, q2 from int8_tbl offset 0) i8;
>
> where we'd expect row_to_json to emit column names "a"/"q2" but we
> actually get "q1"/"q2". But consider this variant:
>
> select row_to_json(i8) from (select q1,q2 from int8_tbl offset 0) i8(x,y);
>
> Arguably, this should show column names x/y but what you get is q1/q2,
> even with my patch. Related cases include
>
> select row_to_json(v) from (values(1,2) limit 1) v(x,y);
> select row_to_json((select i8 from int8_tbl i8(x,y) limit 1));
>
> In the first two of those, the planner isn't bothering to install the
> column aliases into the plan's target lists. While we could fix that,
> it wouldn't help the last case, where the whole-row Var for "int8_tbl"
> is evaluated at scan level; the code for that is looking at the relation's
> tuple descriptor not the scan node's result descriptor. I'm not even
> sure what a clean fix for that case would look like.
>
> Since this behavior can also be demonstrated in 9.2 (and maybe further
> back using xml features?), I don't think we should consider it a
> blocker bug for 9.3. I'm planning to set it on the back burner for
> the moment and go worry about the planner's LATERAL bugs.
Where are we on this? I still see the failure:
regression=> select row_to_json(i8) from (select q1 as a, q2 from
int8_tbl offset 0) i8;
row_to_json
------------------------------------------------
{"q1":123,"q2":456}
{"q1":123,"q2":4567890123456789}
{"q1":4567890123456789,"q2":123}
{"q1":4567890123456789,"q2":4567890123456789}
{"q1":4567890123456789,"q2":-4567890123456789}
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
