FW: Views, views, views! (long)

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

Browse pgsql-hackers by date

  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