Re: [GENERAL] Possible bug with row_to_json

I wrote:
> Jack Christensen <jack@jackchristensen.com> writes:
>> It ignored the rename.

> I looked into this and found that the culprit is the optimization that
> skips ExecProject() if a scan plan node is not doing any useful
> projection.

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.
        regards, tom lane