From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Thomas Lockhart <Thomas(dot)G(dot)Lockhart(at)jpl(dot)nasa(dot)gov>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Almost there on column aliases |
Date: | 2000-02-17 15:57:37 |
Message-ID: | 15745.950803057@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> I've just looked it up in the Date book: table aliases are optional in
> general, but column aliases require a table alias. The bnf looks like
> table [ [ AS ] range-variable [ ( column-commalist ) ] ]
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).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-17 16:08:13 | Re: [HACKERS] Date/time types: big change |
Previous Message | Tom Lane | 2000-02-17 15:49:19 | Re: [HACKERS] Definitional issue for INET types |