On 08/01/2014 04:57 PM, Chris Travers wrote:
> Hi all;
>
> I had a pleasant surprise today when demonstrating a previous misfeature
> in PostgreSQL behaved unexpectedly. In further investigation, there is
> a really interesting syntax which is very helpful for some things I had
> not known about.
>
> Consider the following:
>
> CREATE TABLE keyvaltest (
> key text primary key,
> value text not null
> );
> INSERT INTO keyvaltest VALUES ('foo', 'bar'), ('fooprime', 'barprime');
> SELECT value(k) from keyvaltest k;
>
> The latter performs exactly like
>
> SELECT k.value from keyvaltest k;
Interesting. I wasn't aware of that.
> So the column/function equivalent is there. This is probably not the
> best for production SQL code just because it is non-standard, but it is
> great for theoretical examples because it shows the functional
> dependency between tuple and tuple member.
>
> It gets better:
>
> CREATE OR REPLACE FUNCTION value(test) returns int language sql as $$
> select 3; $$;
> ERROR: "value" is already an attribute of type test
>
> So this further suggests that value(test) is effectively an implicit
> function of test (because it is a trivial functional dependency).
>
> So with all this in mind, is there any reason why we can't or shouldn't
> allow:
>
> CREATE testfunction(test) returns int language sql as $$ select 1; $$;
> SELECT testfunction FROM test;
>
> That would allow first-class calculated columns.
>
> I assume the work is mostly at the parser/grammatical level. Is there
> any reason why supporting that would be a bad idea?
This is already supported since forever.
SELECT test.testfunction FROM test;
This link might be of interest to you:
http://momjian.us/main/blogs/pgblog/2013.html#April_10_2013
--
Vik
