Re: Text-any concatenation volatility acting as optimization barrier - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Text-any concatenation volatility acting as optimization barrier
Date
Msg-id 26911.1328718034@sss.pgh.pa.us
Whole thread Raw
In response to Re: Text-any concatenation volatility acting as optimization barrier  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Text-any concatenation volatility acting as optimization barrier
Re: Text-any concatenation volatility acting as optimization barrier
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp <marti@juffo.org> wrote:
>> Patch attached (in git am format). Passes all regression tests (except
>> 'json' which fails on my machine even on git master).

> Can you provide the diffs from the json test on your machine?  I don't
> see any build-farm failures off-hand...

I'm seeing diffs too after applying Marti's patch: instead of "z", "b",
etc, the field labels in the json values look like "f1", "f2", etc in
the output of queries such as

SELECT row_to_json(q) 
FROM (SELECT $$a$$ || x AS b,         y AS c,         ARRAY[ROW(x.*,ARRAY[1,2,3]),              ROW(y.*,ARRAY[4,5,6])]
ASz      FROM generate_series(1,2) x,           generate_series(4,5) y) q;
 

I believe what is happening is that now that the planner can flatten the
sub-select, the RowExprs are getting expanded differently, and that ties
into the "when do we lose column names" business that Andrew has been
on about.

However, I was not seeing that before applying the patch, so maybe Marti
has another issue too.

I am going to go ahead and commit the patch with the altered json
results, because IMO it is mere accident that these regression cases
were coming out with "nice" field labels anyway.  When and if Andrew
gets the RowExpr cases fixed properly, that will show up as these cases
going back to nicer-looking output.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgstat documentation tables
Next
From: Bruce Momjian
Date:
Subject: Re: Vacuum rate limit in KBps