From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | FW: Views, views, views! (long) |
Date: | 2005-05-10 18:28:18 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3415C27F6@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
my bad [thanks Greg]
> Peter, Merlin, Andrew,
>
> > > > And the restriction to current user owned objects reduces
usability
> > to
> > > > zero.
> > >
> > > The information schema restricts the views to the objects to which
you
> > > have
> > > some access right, which doesn't seem all that useless.
>
> There's a difference between restricting it to objects on which you
have
> rights (which our views do as well) vs. restricting it to objects you
> *own*,
> which is what the information_schema does, according to Andrew. Yes?
Good point, although I'll take either over the current behavior.
Basically, I feel very strongly that *all* interface to database
metadata should be through views unless you happen to database root. I
have personal reasons for this but I also think it's the correct
philosophy in general, even if the views are the incredibly simple:
create view pg_class_view as select * from pg_class;
As a side note I also like the idea of set returning functions because
of the extra flexibility of security invoker/definer...but I'll be a
huge cheerleader for any effort that gets user applications off of
dependency on internal system tables.
In a previous similar discussion Simon noted that the Terradata database
had different view configurations for different security requirements.
my 0.02$ (and that's about all it's worth :-) )
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-05-10 18:30:31 | Re: Views, views, views: Summary of Arguments |
Previous Message | Heikki Linnakangas | 2005-05-10 18:24:30 | Re: Please clarify |