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
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,
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)
*
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
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
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
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.
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
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
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
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
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
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.
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
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 |
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
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
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
18 matches
Mail list logo
