Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov> writes:
>> 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.
> 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??
As far as I can tell without having tried it, you'd still get a correct
dump, although it might look different from the original query because
columns would be referred to by their untransformed names (but that'll
happen anyway, unless you go back and change ruleutil.c's way of looking
up column names). For example, with current sources:
regression=# create view qq as select a from tenk1 t1 (a);
CREATE 276745 1
regression=# \d qq View "qq"Attribute | Type | Modifier
-----------+---------+----------a | integer |
View definition: SELECT t1.unique1 AS a FROM tenk1 t1 (a, unique2, two, four, ten, twenty, hundred, thousand,
twothousand,fivethous, tenthous, odd, even, stringu1, stringu2, string4);
The only "external" view of the alias is as the column title, and notice
that that's getting enforced by an AS clause independently of any
aliases. (In the querytree, that title is coming from a refname in the
targetlist entry --- we don't need another copy in the RTE to make it
work.)
BTW, I'm practically certain that I tried this same example last night
and got a rule dump of just
SELECT t1.unique1 AS a FROM tenk1 t1 (a);
which is more like what I would expect. Did you change the behavior
w.r.t. adding additional columns to the alias list just recently, like
since 11PM EST yesterday?
regards, tom lane
PS: Am I the only one who thinks that column aliases done this way are
extremely brain-dead? If you write "FROM table alias (a b c)" then
you've just written a query that depends critically and non-obviously
on which columns are first, second, third in the physical table.
One of the few things I know about good SQL style is that you don't
write INSERT without an explicit column list, because such code will
break (possibly without warning) if you insert/delete/rearrange columns
in the table definition. This alias facility seems to be just another
method of shooting yourself in the foot with that same bullet...