On Wed, 27 Jun 2001, Karel Zak wrote:
> On Wed, Jun 27, 2001 at 08:42:07AM -0400, Alex Pilosov wrote:
> > On Wed, 27 Jun 2001, Karel Zak wrote:
>
> > This is a little bit better, but, results in following syntax:
> > GRANT SELECT ON FOO(int4). I'm not sure if this really makes sense. Its
> > not a select permission, its an execute permission on a function, and
>
> And if we will have select permission for columns?
Function returns a tuple. To me, it really makes no sense "this user can
see this attribute of a tuple, but not the other one".
> > >
> > > The permissions system was an example only. If you add "foo()-tables"
> > > as something what needs special usage and care you probably found more
> > > problems. For example, what show command '\d' in the psql client, how
> > > relation show pg_access ..etc?
> > \df
>
> And list of attributes of foo()?
Foo returns type x. \dt x.
>
> > Its a function, not a relation. You can do a lot of things to a relation
> > (such as define rules, triggers, constraints), which do not make any sense
>
> Say with me: it isn't a function, its a function that returning records
> and we will use it in same possition as standard table only. The other
> usage donsn't exist for this.
>
> I want wring out from foo()-tables most what is possible (like
> permissions, rules, views). IMHO it's correct requirement :-)
permissions -- see above
rules -- how? 'create rule blah on select from foo(int4) do instead select
from baz()'? Sorry, that's just too strange for me :)
views -- why not. Create view bar as select * from foo() [1]
Actually, now that I think about it, your idea is essentially creation of
a view automatically when the function returning setof record is created.
I don't think its a good idea. If you really want to pretend its a
table/view, then create such a view [1].
-alex
