From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pghackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parser oddity (t.count) |
Date: | 2000-05-26 06:27:40 |
Message-ID: | 00052608293001.00143@zeus |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> to hear about, foo.bar and bar(foo) are considered near-equivalent
> notations by the parser. It looks like when it couldn't find 'count' as
> a field name, it tried and succeeded to interpret it as a function call
> instead.
>
> It works in the other direction too: field(foo) will be interpreted as
> foo.field if foo has a column named field.
>
> This equivalence can be pretty confusing if you don't know about it, but
> I'm hesitant to suggest ripping it out because of the risk of breaking
> old applications. Anyone have strong opinions one way or the other?
This feature is sacrosanct for me, if you ripp it, you take away the
feature to add calculated columns to tables.
The important part for me, is that foo.calcit calls the function calcit(foo).
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Zeugswetter | 2000-05-26 06:30:41 | Re: AW: Performance (was: The New Slashdot Setup (includes MySqlserver)) |
Previous Message | Andreas Zeugswetter | 2000-05-26 06:20:50 | Re: Any reason to use pg_dumpall on an idle database |