Re: [HACKERS] Almost there on column aliases

> OK, but that doesn't really solve my concern about rule bloat, because
> if you write "FROM table alias", you'll still get a list of column names
> appended to that by the system.
> Here is a possible answer that I think would address both our concerns:
> keep track of how many column aliases the user actually wrote (without
> counting the Attr-list entries added by the system for its internal
> convenience), and dump only the user-supplied aliases in rule strings.
> This'd be easy enough to do with an extra field in Attr nodes.
> It'd not only preserve compactness in the cases we previously handled,
> but it'd make the reverse-listed display of rules more like the original
> query in cases where the user did write some aliases (but not a full
> set).

I put the Attr node into the rte because column aliases need to travel
with the table alias. But I'm not sure how the table alias is actually
used after being transformed back and forth for rules. And I'm not
sure how we would use the column aliases beyond the parser in the
future.

How about if I have the rte->ref Attr node hold *only* the column
aliases specified by the user (which addresses your concern), and then
make a "hidden" Attr node (or list of nodes; see below) which is build
and used in the parser but which is never read or written by the
dump/transformation stuff used for rules. So I'll define a new Attr *
field, say "p_ref" which is used internally but ignored after I'm done
with it. I'm not *certain* this will work: I still have issues
regarding outer join syntax which I'm pretty sure are not addressed by
either the status quo or this new suggestion, but at least with a
"hidden field" I'd have some flexibility to muck around with how it is
defined and used.

Also, the "layered aliases" you can get with outer joins are not
handled yet, and I'm pretty sure that more work needs to be done on
the structures to get it to fly at all. e.g.

SELECT n, m FROM (t1 ta (a, b) OUTER JOIN t2 tb (a, c)) AS tj (n,
m);

cannot currently be transformed properly for rules given the info
available in the existing structures. This is true because there is no
equivalent query which allows you to specify anything like t1, ta, t2,
or tb in the target list, and there is no way currently to carry along
the "tj (n, m)" info.

Comments on any or all?

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California