On Wed, Jun 27, 2001 at 10:56:43AM +0200, Reinoud van Leeuwen wrote:
> >
> >> For the result from foo() you must somewhere define attributes
> >> (names).
> >> Where? In CREATE FUNCTION statement? Possible must be:
> >>
> >> select name1, name2 from foo() where name1 > 10;
> >
> > Yes, optimal would imho also be if the foo() somehow had access to the
> > where restriction, so it could only produce output, that the
> > higher level is interested in, very cool. This would be extremely
> > useful for me. Very hard to implement, or even find an appropriate
> > interface for though.
>
> You could easily implement it *in* the function foo IMHO. Since the
> function does some black magic to create the result set to begin with, you
> can change it to use parameters:
>
> select name1, name2 from foo(10, NULL, NULL) where name1 > 10;
The function execution (data reading, etc) is almost last thing in the
path-of-query. The parser, planner and others parts of PG must already
knows enough information about a "relation" foo(). I don't know how much
is intimate idea about this (Tom?), but somewhere in the pg_class /
pg_attribute must be something about foo() result. (*IMHO* of course:)
I can't imagine that foo() builts on-the-fly arbitrary attributes.
By the way, what permissions? For select (view) we can do GRANT/REVOKE,
and for select * from foo()? For standard tables it's in the
pg_class.relacl. IMHO solution is add foo() to pg_class and mark here
oid of function foo() from pg_proc, and attributes definition store
to pg_attribute -- everything as for standard table. The source for
this information must be from CREATE FUNCTION statement, like:
CREATE FUNCTION foo RETURNS( name1 int, name2 text) ....;
If the foo is in the pg_class you can do "GRANT ... ON foo";
Karel
-- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz
