Re: [HACKERS] Almost there on column aliases

>> BTW, the rule regress test is presently failing because I modified
>> ruleutils.c to dump the Attr list if it is not null, rather than
>> only if the refname is different from the relname:

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

> And the rules
> regression test should be failing anyway, because I didn't update it
> since I knew that there was something wrong with those plan strings and
> I didn't want to hide that.

The weird thing is that I'm pretty sure the rules test was *passing*
(against the present expected file) last night after I made the change
I just quoted. It wasn't till after I changed the readfuncs/outfuncs
stuff this morning that I started seeing the long lists of column names
in the rules output.

OTOH, "last night" was about 3AM and I was tired. Maybe I remember it
wrong.

>> While this seems like appropriate logic, a bunch of the rule tests are
>> now showing long and perfectly content-free lists of attribute names in
>> reverse-listed FROM clauses. This bothers me because it implies that
>> those names are being stored in the querytree that's dumped out to
>> pg_rewrite, which will be a further crimp in people's ability to write
>> complex rules. I think we really don't want to store those nodes if we
>> don't have to. Why are we building Attr lists when there's no actual
>> column aliasing being done?

> Hmm. Because there are multiple places in the parser which needs to get
> at a column name. When handling column aliases, I was having to look up
> the actual column names anyway to verify that there were the correct
> number of aliases specified (actually, I decided to allow any number of
> aliases <= the number of actual columns, filling in with the underlying
> column names if an alias was not specified) and so while I had the info
> I cached it into the RTE structure for later use.

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.

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

regards, tom lane