From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Jon Nelson" <jnelson+pgsql(at)jamponi(dot)net>, <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: [PERFORM] typoed column name, but postgres didn't grump |
Date: | 2010-11-02 21:34:25 |
Message-ID: | 4CD03D9102000025000371C6@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-performance |
Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
> If I saw this behavior ( a.b also meaning b(a) ) in another SQL
> engine, I would consider it a thoroughly unintuitive wart
I think the main reason it has been kept is the converse -- if you
define a function "b" which takes record "a" as its only parameter,
you have effectively created a "generated column" on any relation
using record type "a". Kind of. It won't show up in the display of
the relation's structure or in a SELECT *, and you can't use it in
an unqualified reference; but you can use a.b to reference it, which
can be convenient.
It seems to me that this would be most useful in combination with
the inheritance model of PostgreSQL (when used for modeling object
hierarchies rather than partitioning).
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-11-02 22:09:37 | Re: BUG #5740: contrib/spi/moddatetime.c doesn't work with timezones. |
Previous Message | Korry Douglas | 2010-11-02 21:20:49 | Re: ecpg preprocessor regression in 9.0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2010-11-02 22:17:00 | Re: [PERFORM] typoed column name, but postgres didn't grump |
Previous Message | Mladen Gogala | 2010-11-02 21:32:28 | Array interface |