I got interested in this problem again now that we have a user complaint
about it (bug #7553).
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Looking at the code, it seems that the fake aliases (eref) for relations
(may be views as well) are not generated per say, but they do not get
changed when the relation name changes OR in case of inherited tables, they
do not get changed when the inheritance is expanded
(expand_inherited_rtentry).
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
Looking at the code, it seems that the fake aliases (eref) for relations
(may be views as well) are not generated per say, but they do not get
changed when the relation name changes OR in case of inherited tables, they
do not get changed
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand it isn't
all that far beyond what I had in mind of inventing relation aliases
to cure relation-name conflicts. Should we take the existence of such
cases as evidence that we shouldn't try hard in this area?
On Wed, Feb 1, 2012 at 10:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
Looking at the code, it seems that the fake aliases (eref) for relations
(may be views as well) are not generated per say, but they do not get
changed when the
On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other hand it isn't
all that far beyond what I had in mind of inventing relation aliases
to cure relation-name conflicts. Should we take the
Thanks Tom for giving a stronger case. I found the problem whille looking
at inherited tables, and didn't think beyond inherited tables. Since
inherited tables are expanded when subquery planner is invoked, I thought
the problem will occur only in Explain output as we won't generate queries,
that
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
So, as I understand we have two problems here
1. Prefixing schemaname to the fake alises if there is another RTE with
same name. There may not be a relation with that name (fake alias name
given) in the schema chosen as prefix.
2. Fake
I don't believe that the problem has anything to do with the names of
other tables that might happen to exist in the database. It's a matter
of what RTE names/aliases are exposed for variable references in
different parts of the query.
Names of other tables come into picture when we schema
On Wed, Jan 11, 2012 at 6:43 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
Hi,
After running regression, I ran EXPLAIN on one of the queries in regression
(test create_misc) and got following output
regression=# explain verbose select * into table ramp from road where name ~
Robert Haas robertmh...@gmail.com writes:
It's a feature, not a bug, that we schema-qualify names when VERBOSE
is specified. That was done on purpose for the benefit of external
tools that might need this information to disambiguate which object is
being referenced.
Table *aliases*, of
Hi,
After running regression, I ran EXPLAIN on one of the queries in regression
(test create_misc) and got following output
regression=# explain verbose select * into table ramp from road where name
~ '.*Ramp';
QUERY
PLAN
On Wed, Jan 11, 2012 at 5:13 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
Hi,
After running regression, I ran EXPLAIN on one of the queries in
regression (test create_misc) and got following output
regression=# explain verbose select * into table ramp from road where name
~
On Wed, Jan 11, 2012 at 5:25 PM, Chetan Suttraway
chetan.suttra...@enterprisedb.com wrote:
On Wed, Jan 11, 2012 at 5:13 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
Hi,
After running regression, I ran EXPLAIN on one of the queries in
regression (test create_misc) and got
14 matches
Mail list logo
