Re: Views, views, views: Summary of Arguments

> Am Freitag, 6. Mai 2005 12:20 schrieb Andreas Pflug:
> > > and the information_schema is next to useless for these things
since
> > > it doesn't have PostgreSQL specific things in it.
> >
> > 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.

Not useless at all, I couldn't' agree with you more. In fact, there is a
good security argument to be made here as well. In the current state of
things, a user with no rights at all can see the entire database schema
including all the source code to the stored procedures. There are means
to circumvent this but they are very coarse and can cause unexpected
problems.

I think the information_schema approach to system metadata is ultimately
the correct one...but I also agree with Josh in that the various client
tools such as pgadmin and perhaps even pg_dump should be transitioned to
using views. After that the true system columns will no longer need
public access and everything becomes very elegant. To me, this is a
much finer grained security model and nobody complains about extra
security features.

Merlin

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?

More in next e-mail.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Folks,

We've meandered a bit on this, so I wanted to summarize the arguments
presented on the new system views to date so that we might have some hope of
consensus before feature freeze.

As I see it, there are 3 main arguments about having the new system views at
all. These obviously need to be settled before we go any further on security
models, column names, etc. Please add if I've missed anyone's arguments,
I'm trying to summarize across 2 weeks of discussion and am obviously not
impartial.

Argument (1): Are the views useful to users?
Pro: Several people, particularly the proposers, contend that they are. They
cite as evidence the popularity of related articles on General Bits,
commercial precedent, and the prevalence of user-created system views.
Mostly, the usefulness is aimed at new users.
Con: A few people say that they are not useful, and that the system tables are
easily understood.

Argument (2): Do they provide sufficiently distinct functionality from the
information_schema?
Pro: The proposers contend that the information_schema, by SQL spec, is
unable to show all PostgreSQL objects in sufficient detail. That the
permissions and uniqueness models are wrong for PostgreSQL, and these things
are not easily fixed by extension without breaking the SQL spec. That we
don't want to confuse the information_schema with PostgreSQL-specific
extensions.
Con: Several people, most notably Peter, contend that much of the new system
views are duplicative of information_schema, and that efforts should be made
to extend infomation_schema instead of providing a parallel interface. That
we should make serious efforts to support a standard rather than developing a
proprietary interface. A few people claimed that there was nothing that
information_schema didn't have, or that users didn't need that information
anyway.

Argument (3): Would the new system views be useful to interface designers?
Pro: Christopher Kings-Lynne said yes for phpPgAdmin. Josh argued that we
need to look at interface designers who are designing for 3rd-party
multi-database products who are not supporting PostgreSQL yet and will be
unlikely to learn the system tables.
Con: Dave Page said no for pgAdmin. Several people pointed out issues with
the idea of maintaining backwards compatibility through abstraction. Others
cited argument (2) in favor of information_schema, above.

... thus, as I see it, the *primary* question is in fact argument (2). That
is, is information_schema sufficient, and if not, can it be extended without
breaking SQL standards? Argument (1) did not seem to have a lot of evidence
on the "con" side, and the strongest argument against (3) is that we should
use information_schema.

Andrew, can you do a more cohesive set of points on the 2nd half of that
question? That is, how much SQL spec would we have to break (other than
extension) to cover all of the stuff that pg_sysviews currently covers?

--
Josh Berkus
Aglio Database Solutions
San Francisco

>
> ... thus, as I see it, the *primary* question is in fact argument (2). That
> is, is information_schema sufficient, and if not, can it be extended without
> breaking SQL standards? Argument (1) did not seem to have a lot of evidence
> on the "con" side, and the strongest argument against (3) is that we should
> use information_schema.

(2) The information_schema is good but not sufficient. It either needs
more info as suggested by this thread or we need an extended version for
Pg specifically.

(1) I can't see anyone in their right mind on the user space / support
of users side arguing against the need for more information about
PostgreSQL and the way it interacts.

(3) If we can use the information_schema let's do so. However it should
not be a stopping block.

Sincerely,

Joshua D. Drake
Command Prompt. Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Tue, May 10, 2005 at 10:21:06AM -0700, Josh Berkus wrote:
> Folks,
>
> We've meandered a bit on this, so I wanted to summarize the
> arguments presented on the new system views to date so that we might
> have some hope of consensus before feature freeze.
>
> As I see it, there are 3 main arguments about having the new system
> views at all. These obviously need to be settled before we go any
> further on security models, column names, etc. Please add if I've
> missed anyone's arguments, I'm trying to summarize across 2 weeks of
> discussion and am obviously not impartial.
>
> Argument (1): Are the views useful to users?

I've used some of them already at work :)

> Pro: Several people, particularly the proposers, contend that they
> are. They cite as evidence the popularity of related articles on
> General Bits, commercial precedent, and the prevalence of
> user-created system views. Mostly, the usefulness is aimed at new
> users.
> Con: A few people say that they are not useful, and that the system
> tables are easily understood.

Anybody who contends that the system tables are easily understood is
more than welcome to use this understanding, and will not be impeded
by the existence of things they don't choose to use. The
aforementioned understanding--quite rare, but that's almost beside the
point--is not an argument for keeping tools out of the hands of people
for whom the internals of the PostgreSQL implementation are not
intuitively obvious.

> Argument (2): Do they provide sufficiently distinct functionality
> from the information_schema?
> Pro: The proposers contend that the information_schema, by SQL
> spec, is unable to show all PostgreSQL objects in sufficient detail.
> That the permissions and uniqueness models are wrong for PostgreSQL,
> and these things are not easily fixed by extension without breaking
> the SQL spec. That we don't want to confuse the information_schema
> with PostgreSQL-specific extensions.
> Con: Several people, most notably Peter, contend that much of the
> new system views are duplicative of information_schema, and that
> efforts should be made to extend infomation_schema instead of
> providing a parallel interface. That we should make serious efforts
> to support a standard rather than developing a proprietary
> interface. A few people claimed that there was nothing that
> information_schema didn't have, or that users didn't need that
> information anyway.

> Argument (3): Would the new system views be useful to interface designers?
> Pro: Christopher Kings-Lynne said yes for phpPgAdmin. Josh argued that we
> need to look at interface designers who are designing for 3rd-party
> multi-database products who are not supporting PostgreSQL yet and will be
> unlikely to learn the system tables.
> Con: Dave Page said no for pgAdmin. Several people pointed out issues with
> the idea of maintaining backwards compatibility through abstraction. Others
> cited argument (2) in favor of information_schema, above.

> ... thus, as I see it, the *primary* question is in fact argument
> (2). That is, is information_schema sufficient,

Not by a long, long way.

> and if not, can it be extended without breaking SQL standards?

The information schema, by its nature, cannot contain information
about things like indexes because that would be implementation-
specific information, and the information schema is, by design,
implementation-neutral.

Just my $.02 :)

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> interface designers who are designing for 3rd-party multi-database
> products who are not supporting PostgreSQL yet and will be
> unlikely to learn the system tables

There's a scary thought.

So they are willing to learn the new system views, but not the system
tables? The above seems an argument for I_S, or at least an expanded I_S.

So... the reason we don't want to expand (not alter) I_S is that it is a
"standard" that very few RDBMS actually bother to implement, is already
out of date, and is incomplete? Seems we bend the rules in other ways when
needed (e.g. lowercase relation names), we could certainly add additional
tables and columns here, while maintaining the "standard" set for applications
looking for them.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200505100635
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCgI6UvJuQZxSWSsgRAsp3AJ9aY8qeVzpKTcq5yXkhmtkJvuFRWACfXPST
TNNRK32VwbaHimNhB9hjWb8=
=Saja
-----END PGP SIGNATURE-----

On May 11, 2005, at 7:38, Greg Sabino Mullane wrote:

> So they are willing to learn the new system views, but not the system
> tables? The above seems an argument for I_S, or at least an expanded
> I_S.
>
> So... the reason we don't want to expand (not alter) I_S is that it is
> a
> "standard" that very few RDBMS actually bother to implement, is already
> out of date, and is incomplete? Seems we bend the rules in other ways
> when
> needed (e.g. lowercase relation names), we could certainly add
> additional
> tables and columns here, while maintaining the "standard" set for
> applications
> looking for them.
>

One of the reasons I've been impressed with PostgreSQL and its
developers is that I've seen respect for the SQL specifications *except
in cases where it would seriously break backwards compatibility*. In
implementing new features, if the SQL spec has something to say about
it, it's been my observation that good efforts have been made to
comply, though sometimes other syntax or PostgreSQL extensions are
made.

This is not to say the SQL spec is perfect. (At heart I lean toward the
Date/Darwin relational model, but that's just me :) However, to take
something that *is* specified by SQL (and if I understand correctly,
was *implemented in PostgreSQL specifically for SQL compliance*, it
would be a shame to break that. I think PostgreSQL's spec compliance is
a nice bragging point as well -- we do the spec, and more :)

Additional views that depend where possible on the INFORMATION_SCHEMA
could actually be a good thing, as the INFORMATION_SCHEMA follows the
spec, it'd be less likely to change between versions and make
maintenance easier. That said, I haven't looked at the work the new
systems views people have done. I recognize their motivation, as the
times I've needed to look at the current system tables, it's always
been with the docs open right beside me, flipping between pages to see
everything I need to join to get the information I want. I for one am
happy and grateful that a group of people have taken it upon themselves
to provide an easier way to view Postgres system information, and think
that the additional views in some form would make a great addition to
PostgreSQL.

Michael Glaesemann
grzm myrealbox com

I guess I'm having difficulty understanding why the system catalogs
themselves and provision of support for information_schema are not
sufficient for what exists in core.

At one point, there was a stored procedure database for Pl/PgSQL. It
seems like a system view service like that could easily be created and
maintained independently of what is actually considered the core
PostgreSQL distribution.

If one of the primary issues is a lack of clarity in the documentation
of the system catalogs, then that is certainly something that ought to
be addressed. But if another of the primary issues is a need for easier
access to the information contained in the system catalogs/information
schema, then that can be addressed by a public repository that can
certainly be moderated and maintained. Think VPAN (Views of PostgreSQL
Archive Network)...

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On May 10, 2005, at 12:21 PM, Josh Berkus wrote:

> Folks,
>
> We've meandered a bit on this, so I wanted to summarize the arguments
> presented on the new system views to date so that we might have some
> hope of
> consensus before feature freeze.
>
> As I see it, there are 3 main arguments about having the new system
> views at
> all. These obviously need to be settled before we go any further on
> security
> models, column names, etc. Please add if I've missed anyone's
> arguments,
> I'm trying to summarize across 2 weeks of discussion and am obviously
> not
> impartial.
>
> Argument (1): Are the views useful to users?
> Pro: Several people, particularly the proposers, contend that they
> are. They
> cite as evidence the popularity of related articles on General Bits,
> commercial precedent, and the prevalence of user-created system views.
> Mostly, the usefulness is aimed at new users.
> Con: A few people say that they are not useful, and that the system
> tables are
> easily understood.
>
> Argument (2): Do they provide sufficiently distinct functionality from
> the
> information_schema?
> Pro: The proposers contend that the information_schema, by SQL spec,
> is
> unable to show all PostgreSQL objects in sufficient detail. That the
> permissions and uniqueness models are wrong for PostgreSQL, and these
> things
> are not easily fixed by extension without breaking the SQL spec. That
> we
> don't want to confuse the information_schema with PostgreSQL-specific
> extensions.
> Con: Several people, most notably Peter, contend that much of the new
> system
> views are duplicative of information_schema, and that efforts should
> be made
> to extend infomation_schema instead of providing a parallel interface.
> That
> we should make serious efforts to support a standard rather than
> developing a
> proprietary interface. A few people claimed that there was nothing
> that
> information_schema didn't have, or that users didn't need that
> information
> anyway.
>
> Argument (3): Would the new system views be useful to interface
> designers?
> Pro: Christopher Kings-Lynne said yes for phpPgAdmin. Josh argued
> that we
> need to look at interface designers who are designing for 3rd-party
> multi-database products who are not supporting PostgreSQL yet and will
> be
> unlikely to learn the system tables.
> Con: Dave Page said no for pgAdmin. Several people pointed out
> issues with
> the idea of maintaining backwards compatibility through abstraction.
> Others
> cited argument (2) in favor of information_schema, above.
>
> ... thus, as I see it, the *primary* question is in fact argument (2).
> That
> is, is information_schema sufficient, and if not, can it be extended
> without
> breaking SQL standards? Argument (1) did not seem to have a lot of
> evidence
> on the "con" side, and the strongest argument against (3) is that we
> should
> use information_schema.
>
> Andrew, can you do a more cohesive set of points on the 2nd half of
> that
> question? That is, how much SQL spec would we have to break (other
> than
> extension) to cover all of the stuff that pg_sysviews currently covers?
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

Thomas, All,

> I guess I'm having difficulty understanding why the system catalogs
> themselves and provision of support for information_schema are not
> sufficient for what exists in core.

Because you can't answer the question: "What tables does user phil have update
permissions on?" or "How many overloaded versions of function
df_new_company() do I have?", and similar, without doing advanced queries on
the system tables. Queries which are prone to mistakes: earlier on this
thread a *pgsql hacker* posted a sample system catalog query which contained
a mistake. Asking our general users to navigate the complexity of the system
catalogs is just not good application practice.

I don't really think a "VPAN" is any kind of solution for this purpose (though
I'd like it for other things). The purpose of these views is to make
PostgreSQL more user-friendly, and telling people: "Oh just go to
http://name/of/obscure/site, lookup these 10 views, log in as superuser and
load them and you're golden" is not much of an improvement in
user-friendliness.

To reiterate my point previously: these system views are NOT aimed at the
people on *this* list; they are for the people on the -NOVICE and -GENERAL
lists and IRC and the people who don't yet use PostgreSQL. Please stop
thinking exclusively in terms of whether they would be useful to you,
personally.

--
Josh Berkus
Aglio Database Solutions
San Francisco

>
> To reiterate my point previously: these system views are NOT aimed at the
> people on *this* list; they are for the people on the -NOVICE and -GENERAL
> lists and IRC and the people who don't yet use PostgreSQL. Please stop
> thinking exclusively in terms of whether they would be useful to you,
> personally.

I think the above paragraph is very important. When doing development it
is very easy to think only in terms of what would be useful to you. I
have experienced this quite bit when working on the new book as well. It
is very difficult for me to write a chapter on installing PostgreSQL for
Windows, because for me it is completely useless and fairly, "If you
can't figure it out, you shouldn't be using PostgreSQL" in the first place.

However that is not the case with most of our users. Most of our users
have no clue what is in the pg_ tables or even how to get access to them.

A set of documented views would be very useful in this sense. It would
be a lot easier for someone to say:

select size from large_ojects_metainfo where loid = 12545;

Then the other methods to get the large_object size.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

I'm not thinking exclusively in terms of whether they would be useful
to me, personally. In fact, I'm certain that they would be useful to
me, personally.

What I question is whether they need to be a part of the internal
development of PostgreSQL. To me, CPAN is an integral part of being
able to do Perl development effectively.

Whether or not a VPAN setup could come to seem as natural and easy
for new users to use, I don't know. Regardless, these new views are
going to need to be documented similarly so that new users are aware
of them.

And it still isn't clear (to me) how the debate over how to shape
them as included by default will resolve, so punting to an externally
maintained repository is just a suggestion as an alternative.

I think it's important to consider the perspective of both developers
and users, and the internal views clearly creates issues for the
developers.

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On May 11, 2005, at 11:35 AM, Josh Berkus wrote:

> Thomas, All,
>
>
>> I guess I'm having difficulty understanding why the system catalogs
>> themselves and provision of support for information_schema are not
>> sufficient for what exists in core.
>>
>
> Because you can't answer the question: "What tables does user phil
> have update
> permissions on?" or "How many overloaded versions of function
> df_new_company() do I have?", and similar, without doing advanced
> queries on
> the system tables. Queries which are prone to mistakes: earlier
> on this
> thread a *pgsql hacker* posted a sample system catalog query which
> contained
> a mistake. Asking our general users to navigate the complexity of
> the system
> catalogs is just not good application practice.
>
> I don't really think a "VPAN" is any kind of solution for this
> purpose (though
> I'd like it for other things). The purpose of these views is to make
> PostgreSQL more user-friendly, and telling people: "Oh just go to
> http://name/of/obscure/site, lookup these 10 views, log in as
> superuser and
> load them and you're golden" is not much of an improvement in
> user-friendliness.
>
> To reiterate my point previously: these system views are NOT aimed
> at the
> people on *this* list; they are for the people on the -NOVICE and -
> GENERAL
> lists and IRC and the people who don't yet use PostgreSQL. Please
> stop
> thinking exclusively in terms of whether they would be useful to you,
> personally.
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>

"Thomas F. O'Connell" <tfo(at)sitening(dot)com> writes:
> I think it's important to consider the perspective of both developers
> and users, and the internal views clearly creates issues for the
> developers.

FWIW, I don't see the issue as "internal vs external" at all. What's
bothering me is whether these views can be considered sufficiently
more stable and better designed than the physical system catalogs
to justify recommending that application designers should rely on
the views instead of the catalogs. That point doesn't seem to me
to have been proven. The recent arguments in favor seem to boil down to
"novices will find these easier to use", which is very possibly true,
but novices don't have the same needs as programs.

regards, tom lane

> FWIW, I don't see the issue as "internal vs external" at all. What's
> bothering me is whether these views can be considered sufficiently
> more stable and better designed than the physical system catalogs
> to justify recommending that application designers should rely on
> the views instead of the catalogs. That point doesn't seem to me
> to have been proven. The recent arguments in favor seem to boil down to
> "novices will find these easier to use", which is very possibly true,
> but novices don't have the same needs as programs.

As lead phpPgAdmin developer, I'm officially in favour of them. The
main reason being all the extra fruit they have that shows database
size, etc.

That means we can display this meta information in phpPgAdmin and not
worry about having to re-implement it all.

Chris

On Thu, May 12, 2005 at 01:23:17AM -0400, Tom Lane wrote:
> "Thomas F. O'Connell" <tfo(at)sitening(dot)com> writes:
> > I think it's important to consider the perspective of both developers
> > and users, and the internal views clearly creates issues for the
> > developers.
>
> FWIW, I don't see the issue as "internal vs external" at all. What's
> bothering me is whether these views can be considered sufficiently
> more stable and better designed than the physical system catalogs
> to justify recommending that application designers should rely on
> the views instead of the catalogs. That point doesn't seem to me
> to have been proven. The recent arguments in favor seem to boil down to
> "novices will find these easier to use", which is very possibly true,
> but novices don't have the same needs as programs.
>

Would you rather help hone a set of PostgreSQL views or answer
and correct every single dba and tool developer who needs to have the
system catalog entity-relationship diagram (exists?) explained in detail
in order to access system catalogs accurately. You obviously have no
trouble throwing together system catalog queries, but this is not
true of the general user base. It should also be acknowledged that
the system catalogs are adequate, useful and obtuse.

Also, if you do not trust the newsysview team to develop good views
(with input for hackers), how can you possibly expect every dba and tool
maker to access the system catalog in a consistent and accurate manner.

If everyone is rolling their own queries into the system catalog, there
is a lot of room for error and inconsistency between tools. I believe tool
developers will confirm this.

It would be better to spend time to work on really good system views and
allow people build on them, starting from a higher level than the
system catalogs.

elein
=============================================================
elein(at)varlena(dot)com Varlena, LLC www.varlena.com
(510)655-2584(o) (510)543-6079(c)
PostgreSQL Consulting, Support & Training

PostgreSQL General Bits http://www.varlena.com/GeneralBits/
==============================================================
I have always depended on the [QA] of strangers.

elein(at)varlena(dot)com (elein) writes:
> Also, if you do not trust the newsysview team to develop good views
> (with input for hackers), how can you possibly expect every dba and tool
> maker to access the system catalog in a consistent and accurate manner.

I never said that they couldn't develop useful views. I do question
the assumption that they can be all things to all people. I think the
claims being made in this thread are highly overblown. In particular
I doubt that views that expose everything anyone might want to know
are going to be amazingly much simpler than the underlying catalogs.

So far the goals that have been presented include being complete, being
simple, and being stabler than the underlying catalogs. I think you
can have *one* of those; probably not two and definitely not all three.
So tell us the truth about what your priorities are and which goals will
lose when there's a conflict.

I see a whole lot of NIH (Not Invented Here) syndrome --- the developers
of these views love 'em, sure, because they fit the way those developers
think. But that doesn't prove everyone else will love 'em.

regards, tom lane

Tom,

> I never said that they couldn't develop useful views. I do question
> the assumption that they can be all things to all people. I think the
> claims being made in this thread are highly overblown. In particular
> I doubt that views that expose everything anyone might want to know
> are going to be amazingly much simpler than the underlying catalogs.

Well, we're actually trying to answer 2 seperate questions on this thread:
1) would some kind of new system views in theory be valuable and accepted, and
2) what needs to change in these particular system views.

We need to answer question (1) first because there's no point on doing a lot
of work to modify our proposal if it's just going to be rejected.

> So far the goals that have been presented include being complete, being
> simple, and being stabler than the underlying catalogs. I think you
> can have *one* of those; probably not two and definitely not all three.
> So tell us the truth about what your priorities are and which goals will
> lose when there's a conflict.

My personal goal is to have views which are complete and simpler than the
system catalogs to the extent that it doesn't interfere with being complete.
For super-simple, incomplete views we have the information_schema and the old
system views. I think you've sucessfully punched several holes in the "more
stable" argument, so that's really the lowest priority.

> I see a whole lot of NIH (Not Invented Here) syndrome --- the developers
> of these views love 'em, sure, because they fit the way those developers
> think. But that doesn't prove everyone else will love 'em.

Sure, but so far the arguments have not revolved around the specific views
proposed, but rather the whole concept of new system views at all. In fact,
I think Peter was the only person to give us any useful feedback on the
actual design ...

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, May 12, 2005 at 03:30:59PM -0400, Tom Lane wrote:
> elein(at)varlena(dot)com (elein) writes:
> > Also, if you do not trust the newsysview team to develop good views
> > (with input for hackers), how can you possibly expect every dba and tool
> > maker to access the system catalog in a consistent and accurate manner.
>
> I never said that they couldn't develop useful views. I do question
> the assumption that they can be all things to all people. I think the
> claims being made in this thread are highly overblown. In particular
> I doubt that views that expose everything anyone might want to know
> are going to be amazingly much simpler than the underlying catalogs.
>
> So far the goals that have been presented include being complete, being
> simple, and being stabler than the underlying catalogs. I think you
> can have *one* of those; probably not two and definitely not all three.
> So tell us the truth about what your priorities are and which goals will
> lose when there's a conflict.

In real life, as opposed to goals, the views will be mostly complete
but will provide a simpler foundation for people to build on.

Simplicity is an objective measurement. Simpler than the existing
system catalogs is a clear objective. My own push and emphasis
for this views is to simplify support and useabilty--to answer questions
people (and tools) ask most often. Others lean toward completeness
as more important.

And lastly, the views will only be as stable as the system catalogs.
If anyone says differently they are wrong.

>
> I see a whole lot of NIH (Not Invented Here) syndrome --- the developers
> of these views love 'em, sure, because they fit the way those developers
> think. But that doesn't prove everyone else will love 'em.
>

Usability must be the emphasis. That is why I push toward having
the views answer questions that users need to ask.

--elein

=============================================================
elein(at)varlena(dot)com Varlena, LLC www.varlena.com
(510)655-2584(o) (510)543-6079(c)
PostgreSQL Consulting, Support & Training

PostgreSQL General Bits http://www.varlena.com/GeneralBits/
==============================================================
I have always depended on the [QA] of strangers.

Josh Berkus wrote:

>1) would some kind of new system views in theory be valuable and accepted
>
>

I still don't have any strong views, but I do want the target audience
specified - I have seen conflicting messages on that. Power users? Admin
Tool builders? Client library builders? These groups don't all have the
same needs.

cheers

andrew

On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > FWIW, I don't see the issue as "internal vs external" at all. What's
> > bothering me is whether these views can be considered sufficiently
> > more stable and better designed than the physical system catalogs
> > to justify recommending that application designers should rely on
> > the views instead of the catalogs. That point doesn't seem to me
> > to have been proven. The recent arguments in favor seem to boil down to
> > "novices will find these easier to use", which is very possibly true,
> > but novices don't have the same needs as programs.
>
> As lead phpPgAdmin developer, I'm officially in favour of them. The
> main reason being all the extra fruit they have that shows database
> size, etc.
>

As non-lead phpPgAdmin developer, I'd be against using them in phppgadmin.
(note this doesnt mean I am against them in pgsql itself)

> That means we can display this meta information in phpPgAdmin and not
> worry about having to re-implement it all.
>

You have to query something... doesn't bother me to go to the source.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Andrew,

> I still don't have any strong views, but I do want the target audience
> specified - I have seen conflicting messages on that. Power users? Admin
> Tool builders? Client library builders? These groups don't all have the
> same needs.

DBAs, tool builders (primarily existing-tool-integrators), and PostgreSQL
beginners. Power users could presumably find and install them from
pgFoundry.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
> On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > > FWIW, I don't see the issue as "internal vs external" at all.
> > > What's bothering me is whether these views can be considered
> > > sufficiently more stable and better designed than the physical
> > > system catalogs to justify recommending that application
> > > designers should rely on the views instead of the catalogs.
> > > That point doesn't seem to me to have been proven. The recent
> > > arguments in favor seem to boil down to "novices will find these
> > > easier to use", which is very possibly true, but novices don't
> > > have the same needs as programs.
> >
> > As lead phpPgAdmin developer, I'm officially in favour of them.
> > The main reason being all the extra fruit they have that shows
> > database size, etc.
> >
>
> As non-lead phpPgAdmin developer, I'd be against using them in
> phppgadmin. (note this doesnt mean I am against them in pgsql
> itself)

On what grounds?

> > That means we can display this meta information in phpPgAdmin and
> > not worry about having to re-implement it all.
> >
>
> You have to query something... doesn't bother me to go to the
> source.

A PostgreSQL developer has shown in this very thread that it is
extremely easy to screw up a query against those catalogs. Maybe
you're better than he is, but that's not a reason to keep something
simpler out.

Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

>>As lead phpPgAdmin developer, I'm officially in favour of them. The
>>main reason being all the extra fruit they have that shows database
>>size, etc.
>
> As non-lead phpPgAdmin developer, I'd be against using them in phppgadmin.
> (note this doesnt mean I am against them in pgsql itself)

Hehe, talk about your democratic institutions :)

Chris

Christopher Kings-Lynne wrote:

>>> As lead phpPgAdmin developer, I'm officially in favour of them. The
>>> main reason being all the extra fruit they have that shows database
>>> size, etc.
>>
>>
>> As non-lead phpPgAdmin developer, I'd be against using them in
>> phppgadmin. (note this doesnt mean I am against them in pgsql itself)
>
>
> Hehe, talk about your democratic institutions :)
>
>

But you have more votes, right?

cheers

andrew

On Thursday 12 May 2005 19:59, David Fetter wrote:
> On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
> > On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
> > > > FWIW, I don't see the issue as "internal vs external" at all.
> > > > What's bothering me is whether these views can be considered
> > > > sufficiently more stable and better designed than the physical
> > > > system catalogs to justify recommending that application
> > > > designers should rely on the views instead of the catalogs.
> > > > That point doesn't seem to me to have been proven. The recent
> > > > arguments in favor seem to boil down to "novices will find these
> > > > easier to use", which is very possibly true, but novices don't
> > > > have the same needs as programs.
> > >
> > > As lead phpPgAdmin developer, I'm officially in favour of them.
> > > The main reason being all the extra fruit they have that shows
> > > database size, etc.
> >
> > As non-lead phpPgAdmin developer, I'd be against using them in
> > phppgadmin. (note this doesnt mean I am against them in pgsql
> > itself)
>
> On what grounds?
>

See upthread response from the various pgadmin guys as to why they wouldn't
use them.

> > > That means we can display this meta information in phpPgAdmin and
> > > not worry about having to re-implement it all.
> >
> > You have to query something... doesn't bother me to go to the
> > source.
>
> A PostgreSQL developer has shown in this very thread that it is
> extremely easy to screw up a query against those catalogs. Maybe
> you're better than he is, but that's not a reason to keep something
> simpler out.
>

Out of phppgadmin or out of pgsql itself? The internals of phppgadmin dont
have to be simple (sure its a bonus when they are, but its not the primary
goal). Of course thats completly orthagonal to whether these views should be
in pgsql itself. Unless you think they should be in there for admin tools.
Personally I think at least a couple of these should be in there for the ease
of use factor (relacl is just evil), but the other reasons of unchanging
interface and defining all objects seem wrong headed to me and make me
skeptical of the whole thing.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Thu, May 12, 2005 at 16:59:07 -0700,
David Fetter <david(at)fetter(dot)org> wrote:
>
> A PostgreSQL developer has shown in this very thread that it is
> extremely easy to screw up a query against those catalogs. Maybe
> you're better than he is, but that's not a reason to keep something
> simpler out.

You could still study the views to see the correct way to do things,
but then not actually use them in the tool. I think this is actually
a good reason for developing the views, even if they end up as an
add on project.

On Thu, May 12, 2005 at 04:03:39PM -0400, Andrew Dunstan wrote:
> I still don't have any strong views, but I do want the target audience
> specified - I have seen conflicting messages on that. Power users? Admin
> Tool builders? Client library builders? These groups don't all have the
> same needs.

While their needs may not be identical, I don't think that means you
can't provide views that serve all of their needs, unless there are
requirements that are in direct opposition to on another. I can't think
of any requirements in your examples that would fall under this
catagory.

Another use case I wanted to mention is using system views to assist in
remote troubleshooting. If you need to know something about someone's
database, it will be much easier to ask them to run a query against the
system views as opposed to the catalog.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"