Re: [HACKERS] Almost there on column aliases

> > 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:
> 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.)

Well, there are other queries which *do* rely on the column aliases:

select a, b from t1 ta (a, b, c) natural join t2 tb (a, d);

where the column in the target list called "a" is not allowed to have an
explicit reference to a table name. That is, neither

select t1.a, b from t1 ta (a, b, c) natural join t2 tb (a, d);

nor

select t2.a, b from t1 ta (a, b, c) natural join t2 tb (a, d);

are legal SQL, but, for example,

select a, ta.b from t1 ta (a, b, c) natural join t2 tb (a, d);

is. Not sure how this impacts the rule representation or dump/reload of
views.

> BTW, I'm practically certain that I tried this same example last night
> 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?

Yeah right ;)

I've only committed one set of patches; don't remember what time that
was...

> 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...

It's required for doing complex join syntax, and is allowed for other
joins as well. But we certainly have got along just fine without it, eh?

- Thomas

--
Thomas Lockhart
Caltech/JPL
Interferometry Systems and Technology