Re: [HACKERS] Almost there on column aliases - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] Almost there on column aliases
Date
Msg-id 38A9DDF5.10482FE9@jpl.nasa.gov
Whole thread Raw
In response to Almost there on column aliases  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
Responses Re: [HACKERS] Almost there on column aliases
List pgsql-hackers
> > istm that the column aliases (rte->ref->attrs) should not be written out
> > if the table alias (rte->ref->relname) is not written.
> Hmm.  If it's not possible to specify column aliases without specifying
> a table-name alias, then that's OK ... but I thought table aliases were
> optional.

I don't think so (ie a table alias is required if a column alias is
specified), but my SQL books are at home so I can't verify my
recollection.

> Fair enough, but we don't need those column names any more after the
> parse/analyze phase completes, right?  Maybe we could remove the lists
> at that time, or at least do so before writing out rule querytrees.

Possibly. I'm transforming the qualifications on the join clause as the
join clause is transformed (rather than later during the WHERE
transformation) in the hope that the column (and table) names will have
been replaced by attribute numbers and RTE indices. If that is the case,
and if the "correlation names" or aliases are never needed after that,
then we can drop 'em.

Except that we'll possibly need them to get a valid pg_dump of the
rules? Or is an untransformed copy of the original definition kept
around someplace??

> Since we aren't going to have TOAST in 7.0, I'm concerned that the
> rule representation not get any more verbose than it is already...

Right.
                        - Thomas

-- 
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Most Advanced
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Almost there on column aliases