Re: [HACKERS] When do we lose column names?

2012-02-14 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 02/13/2012 11:00 AM, Tom Lane wrote: This is surely fixable by passing a bit more information down. If you (Andrew) have something that covers everything but this issue, pass it over and I'll take a whack at it. What I have fixes one of the

Re: [HACKERS] When do we lose column names?

2012-02-14 Thread Andrew Dunstan
On 02/14/2012 05:39 PM, Tom Lane wrote: OK, I fixed this up and committed it. I made some cosmetic changes (the most notable being that the definition of RowExpr is really changing here, and so should its comment). The adjust_appendrel_attrs situation was fixed by passing in the PlannerInfo,

Re: [HACKERS] When do we lose column names?

2012-02-13 Thread Robert Haas
On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan aduns...@postgresql.org wrote: Other candidates I have found that don't set colnames and should probably use dummy names are:   * src/backend/parser/gram.y (row: production)   *

Re: [HACKERS] When do we lose column names?

2012-02-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan aduns...@postgresql.org wrote: Do we actually need to bother with these cases? In flatten_join_alias_vars_mutator(), we've got a RangeTblEntry to work with. I think the column names are to be found in

Re: [HACKERS] When do we lose column names?

2012-02-13 Thread Andrew Dunstan
On 02/13/2012 11:00 AM, Tom Lane wrote: Robert Haasrobertmh...@gmail.com writes: On Sat, Feb 11, 2012 at 11:11 AM, Andrew Dunstan aduns...@postgresql.org wrote: Do we actually need to bother with these cases? In flatten_join_alias_vars_mutator(), we've got a RangeTblEntry to work with. I

Re: [HACKERS] When do we lose column names?

2012-02-11 Thread Andrew Dunstan
On 02/09/2012 03:06 PM, Andrew Dunstan wrote: On 02/09/2012 02:54 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: OK, the one place that needs to be fixed to avoid the crash caused by the json regression tests with the original patch is in

Re: [HACKERS] When do we lose column names?

2012-02-09 Thread Andrew Dunstan
On 02/07/2012 03:03 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 02/07/2012 12:47 PM, Tom Lane wrote: In general I think we'd have to require that colnames be supplied in all RowExprs if we go this way. Anyplace that's trying to slide by without will have to be fixed.

Re: [HACKERS] When do we lose column names?

2012-02-09 Thread Alvaro Herrera
Excerpts from Andrew Dunstan's message of jue feb 09 16:38:27 -0300 2012: OK, the one place that needs to be fixed to avoid the crash caused by the json regression tests with the original patch is in src/backend/parser/parse_expr.c:transformRowExpr(). Other candidates I have found

Re: [HACKERS] When do we lose column names?

2012-02-09 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: OK, the one place that needs to be fixed to avoid the crash caused by the json regression tests with the original patch is in src/backend/parser/parse_expr.c:transformRowExpr(). Other candidates I have found that don't set colnames and should

Re: [HACKERS] When do we lose column names?

2012-02-09 Thread Andrew Dunstan
On 02/09/2012 02:54 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: OK, the one place that needs to be fixed to avoid the crash caused by the json regression tests with the original patch is in src/backend/parser/parse_expr.c:transformRowExpr(). Other candidates I have

Re: [HACKERS] When do we lose column names?

2012-02-07 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 11/16/2011 10:38 PM, Tom Lane wrote: Upon further review, this patch would need some more work even for the RowExpr case, because there are several places that build RowExprs without bothering to build a valid colnames list. It's clearly soluble

Re: [HACKERS] When do we lose column names?

2012-02-07 Thread Andrew Dunstan
On 02/07/2012 12:47 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net writes: On 11/16/2011 10:38 PM, Tom Lane wrote: Upon further review, this patch would need some more work even for the RowExpr case, because there are several places that build RowExprs without bothering to build a

Re: [HACKERS] When do we lose column names?

2012-02-07 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: On 02/07/2012 12:47 PM, Tom Lane wrote: In general I think we'd have to require that colnames be supplied in all RowExprs if we go this way. Anyplace that's trying to slide by without will have to be fixed. I don't recall how many places that is.

Re: [HACKERS] When do we lose column names?

2012-02-06 Thread Andrew Dunstan
On 11/16/2011 10:38 PM, Tom Lane wrote: I wrote: PFC, a patch that does this. Upon further review, this patch would need some more work even for the RowExpr case, because there are several places that build RowExprs without bothering to build a valid colnames list. It's clearly soluble if

[HACKERS] When do we lose column names?

2011-11-16 Thread Andrew Dunstan
Consider the following query: select (x).key as k, (x).value as v from (select each(hstore(q)) as x from (select oid, c.* from pg_class c where oid = 'parent'::regclass) q) t; This gives results like this: k | v -+ f1 | 16410 f2 | parent f3 |

Re: [HACKERS] When do we lose column names?

2011-11-16 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: What I'm having difficulty understanding is why the limit clause should make any difference. Without the LIMIT, the query gets flattened to something like this: Index Scan using pg_class_oid_index on pg_catalog.pg_class c (cost=0.00..8.27 rows=1

Re: [HACKERS] When do we lose column names?

2011-11-16 Thread Tom Lane
I wrote: and the issue seems to be that in execution of a RowExpr, the executor doesn't pay any attention to preserving the column names in the generated tupledesc --- see the ExecTypeFromExprList call in execQual.c. ... We could certainly make it do that --- it wouldn't even be terribly

Re: [HACKERS] When do we lose column names?

2011-11-16 Thread Tom Lane
I wrote: PFC, a patch that does this. Upon further review, this patch would need some more work even for the RowExpr case, because there are several places that build RowExprs without bothering to build a valid colnames list. It's clearly soluble if anyone cares to put in the work, but I'm not