I got interested in this problem again now that we have a user complaint
about it (bug #7553).
Ashutosh Bapat writes:
> On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas wrote:
>> On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane wrote:
>>> ... It seems
>>> reasonable to me to try to handle relation renames
On Wed, Feb 1, 2012 at 11:01 PM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane 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 e
On Wed, Feb 1, 2012 at 10:53 PM, Tom Lane wrote:
> Ashutosh Bapat 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 tabl
On Wed, Feb 1, 2012 at 12:23 PM, Tom Lane 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? It seems
> rea
Ashutosh Bapat 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 when the inheritance is expan
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).
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 sch
Ashutosh Bapat 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 aliases themselves can be con
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 c
Robert Haas 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 course, should not be
On Wed, Jan 11, 2012 at 6:43 AM, Ashutosh Bapat
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 ~
> '.*Ramp';
>
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_mi
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
>
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
14 matches
Mail list logo