On Wed, 4 May 2005 21:37:40 -0700, Josh Berkus josh@agliodbs.com
wrote:
As stated above, these system views, once incorporated into a pg distribution,
are likely to be with us *forever*.
I don't think that this is doable. :-(
You might want to put the system views into a version specific
Am Montag, 9. Mai 2005 00:41 schrieb Andrew - Supernews:
c) In most places, system objects are segregated from
user objects, e.g. pg_user_indexes
I think that is a bad idea as it goes against the fundamental design of
PostgreSQL.
In what way? Please elaborate.
PostgreSQL does not
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
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
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
On Tue, May 10, 2005 at 04:55:40PM +0200, Peter Eisentraut wrote:
Am Montag, 9. Mai 2005 00:41 schrieb Andrew - Supernews:
c) In most places, system objects are segregated from
user objects, e.g. pg_user_indexes
I think that is a bad idea as it goes against the fundamental design of
On 2005-05-10, Peter Eisentraut [EMAIL PROTECTED] wrote:
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
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
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 10, 2005 at 04:55:40PM +0200, Peter Eisentraut wrote:
PostgreSQL does not really distinguish between system and user things.
How will you do that?
It's currently done using this function:
create or replace function
Tom,
I think the real problem here is that it's hard to be all things to all
people. If you suppress display of certain objects, that may be nice
suppression of clutter for one user, yet render the view useless from
the perspective of another user --- or even the same user on a different
On Friday the 6th of May 2005, Mr. Treat opined:
I also don't think it is any harder to learn to query the
system tables than it would be to learn to query these new
views (with a few caevets that I will come back to) and it
might actually be better.
Admin tools are in a sense already a gui
Robert,
As Jim points out, their current long term goal is to be a replacement for
the current system views (hence *new* system views), and the current
project was created to facilitate development. What I am thinking is that
the project take on a different goal, mainly that it be an add on
On Fri, May 06, 2005 at 05:44:43PM -0400, Robert Treat wrote:
Sorry, but I'm still in the admin tools wont use these camp since I don't
believe these views can solve an admin tools need to support multiple
versioning within its code. I also don't think it is any harder to learn to
query
On 2005-05-08, Jim C. Nasby [EMAIL PROTECTED] wrote:
I suggest taking a gander at the '_compat' files at
http://lnk.nu/cvs.pgfoundry.org/251/. Basically, features that are new
in 8.0 (ie: tablespaces) have an abstraction layer. The code under that
layer is version specific, but the code above
On 2005-05-05, Peter Eisentraut [EMAIL PROTECTED] wrote:
I would suggest that you align your terminology with the information
schema as much as possible, so it would be type_schema and not
type_schema_name, and ordinal_position instead of
column_position. Otherwise we'll have a lot of
On Fri, May 06, 2005 at 02:43:19AM -, Andrew - Supernews wrote:
On 2005-05-06, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Hmmm ... we argued about this. I was in favor of hiding the OIDs
because OIDs are not consistent after a database reload and names are.
I can see your point
On Thu, May 05, 2005 at 06:55:38PM +0200, Andreas Pflug wrote:
Josh Berkus wrote:
Frankly, this is sounding a lot like Who needs OpenOffice.org? Use vi!
Frankly, this is sounding a lot like Who needs
pgadmin/phppgadmin/pgaccess/younameit? use SELECT * FROM pg_somewot in
psql instead.
On Thu, May 05, 2005 at 11:29:34PM -0400, Robert Treat wrote:
I was starting to think this... like this should be a project on foundry
called enhanced system views that would be fairly database version
independant and people could install into any databases they needed them in.
The
On Thu, May 05, 2005 at 05:38:16PM -0700, Dann Corbit wrote:
See Andrew's post. There is a whole lot of stuff not covered by I_S in a
way
that is useful to PGSQL users. Also this would require making
information_schema part of the default user path.
It is supposed to be part of the
On 5/6/05, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
As long as they are in a separate schema (like information_schema,
but hopefully not as long). pg_views? pg_info? information_skema? :)
But if you think that nobody needs these views, it's because you
haven't had much contact with end
Christopher Kings-Lynne wrote:
The unimaginable craziness of currently trying to support multiple
versions of postgresql is pretty bad,
Hu? So you suggest version specific admin tools? *scratch head*
Just for curiosity:
pgAdmin CVS currently has 80 version checked pieces of code to support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
And what about users who's interface to PostgreSQL is psql?
Backslash commands.
-BEGIN PGP SIGNATURE-
iD8DBQFCeqzEvJuQZxSWSsgRAgkPAKC1V0Sm3Umi1eGFnoj1P5Qt26V32wCeMjLh
+3LX4eUjgKdy+SOKHSRzRxQ=
=mSNP
-END PGP SIGNATURE-
On Thursday 05 May 2005 23:45, Joshua D. Drake wrote:
I was starting to think this... like this should be a project on foundry
called enhanced system views that would be fairly database version
independant and people could install into any databases they needed them
in.
You mean like:
On Fri, May 06, 2005 at 11:34:49AM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
And what about users who's interface to PostgreSQL is psql?
Backslash commands.
There's a ton of cases the backslash commands don't cover, which others
have given
Jim C. Nasby [EMAIL PROTECTED] writes:
Aside from that, it's currently rather silly that every admin tool has
to code up a very complex set of queries to get info from the system
catalog. It makes much more sense to put that complexity into a set of
system views that are maintained as part of
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Aside from that, it's currently rather silly that every admin tool has
to code up a very complex set of queries to get info from the system
catalog. It makes much more sense to put that complexity into a set of
system views that are maintained
On Fri, May 06, 2005 at 12:21:55PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Aside from that, it's currently rather silly that every admin tool has
to code up a very complex set of queries to get info from the system
catalog. It makes much more sense to put that
On Fri, May 06, 2005 at 09:08:10AM -0400, Robert Treat wrote:
On Thursday 05 May 2005 23:45, Joshua D. Drake wrote:
I was starting to think this... like this should be a project on foundry
called enhanced system views that would be fairly database version
independant and people could
On Fri, May 06, 2005 at 01:20:09AM -0500, Jim C. Nasby wrote:
On Fri, May 06, 2005 at 02:43:19AM -, Andrew - Supernews wrote:
On 2005-05-06, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Hmmm ... we argued about this. I was in favor of hiding the OIDs
because OIDs are not
Actually bad and good are appropriate. The structure
of the system catalogs dates back to the grad student's
theses and is not really good. But it is stable and
does the job. It really is not user friendly, however.
I reassert that I have seen only one decent schema drawing
of the system
On 2005-05-06, Jim C. Nasby [EMAIL PROTECTED] wrote:
But yes, the intention is to continue to support backwards compatability
as much as possible. Currently I believe that compatability stops at
versions that don't support schemas, though that could change.
I have made no attempt to support
On Friday 06 May 2005 13:43, Jim C. Nasby wrote:
On Fri, May 06, 2005 at 09:08:10AM -0400, Robert Treat wrote:
On Thursday 05 May 2005 23:45, Joshua D. Drake wrote:
I was starting to think this... like this should be a project on
foundry called enhanced system views that would be fairly
Hi Josh,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: 05 May 2005 05:38
To: PostgreSQL-development
Subject: [HACKERS] Views, views, views! (long)
This
has kept the pgAdmin and phpPgAdmin teams busy since 7.2, and
means
Josh,
it's very difficult to read your messages (I'm using Pine), because
of some symbols (~Z on my xterm) which broke formatting.
Is't known problem of pine (4.62) or your mailer ?
Regards,
Oleg
_
Oleg Bartunov,
Josh Berkus wrote:
a) all view and column names are as explicit and as readable
as possible (e.g. type_schema_name, not typnsname)
I would suggest that you align your terminology with the information
schema as much as possible, so it would be type_schema and not
type_schema_name, and
Josh Berkus josh@agliodbs.com writes:
Tom,
To put it more bluntly: exactly what are you accomplishing here that
isn't already accomplished, in a *truly* standard fashion, by the
INFORMATION_SCHEMA? Why do we need yet another nonstandard view on
the underlying reality?
To quote myself:
Q:
Dave Page dpage@vale-housing.co.uk writes:
3) One example of a catalog change that has caused a number of bug
reports for us is the removal of pg_database.datpath. Whilst your
views could have prevented the error itself, we would still have had
to modify pgAdmin to prevent it displaying the
Tom, Peter,
That said, I don't particularly care for this proposal. If you want a
human-readable version of the system catalogs, I suggest you work on
extensions of the information schema, not a completely new interface.
So, both of your would prefer that we break the SQL spec with the
This is the kind of thing that support engineers love. Instead of having to
email a bunch of complex SQL statements to a customer that is having trouble,
they can verbally walk through a system catalog type query.
My proprietary database has a very simple system catalog that very human
:02 PM
To: Tom Lane
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Views, views, views! (long)
Tom,
To put it more bluntly: exactly what are you accomplishing here that
isn't already accomplished, in a *truly* standard fashion, by the
INFORMATION_SCHEMA? Why do we need yet another
Josh Berkus wrote:
Frankly, this is sounding a lot like Who needs OpenOffice.org? Use vi!
Frankly, this is sounding a lot like Who needs
pgadmin/phppgadmin/pgaccess/younameit? use SELECT * FROM pg_somewot in
psql instead.
As Dave already pointed out, serious admin tools will avoid views. We
Andreas,
As Dave already pointed out, serious admin tools will avoid views. We
have to deal with version specific issues anyway.
Actually, I don't think that's what Dave said. He simply said that modifying
pgAdmin to keep up with pg_catalog changes hasn't actually been a problem.
And, as an
Josh Berkus wrote:
And, as an increasing number of 3rd-party tools support PostgreSQL (like
Embarcadero) they need a simple comprehensible API for system objects -- more
objects than are included in the information_schema.
There are only two choices: Creating a minimal subset tool, which will
Andreas,
There are only two choices: Creating a minimal subset tool, which will
rely on INFORMATION_SCHEMA (or a schema API as in ODBC) as standardized
by SQL specs, or making it specifically for every DBMS, whether using
some fancy views or not.
Thing is, INFORMATION_SCHEMA doesn't hold a
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: Thursday, May 05, 2005 10:49 AM
To: Andreas Pflug
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Views, views, views! (long)
Andreas,
There are only two
Josh Berkus wrote:
Either the information schema adheres to
the spec, or it only covers 25% of PostgreSQL objects. There isn't
a 3rd alternative. I'm fine with merging this with the
information_schema (some of these views are derived from the same
code) but it's either/or.
I can think of
Peter,
I can think of a couple of ways offhand about how the information schema
could be extended without breaking the SQL standard. You could just
add columns where needed. Or you could add tables that are joined to
the standard tables and contain the extra information. Or you could
On Thu, May 05, 2005 at 14:26:56 +0400,
Oleg Bartunov oleg@sai.msu.su wrote:
Josh,
it's very difficult to read your messages (I'm using Pine), because
of some symbols (~Z on my xterm) which broke formatting.
Is't known problem of pine (4.62) or your mailer ?
There were a lot of \240
Guys,
it's very difficult to read your messages (I'm using Pine), because
of some symbols (~Z on my xterm) which broke formatting.
Is't known problem of pine (4.62) or your mailer ?
There were a lot of \240 characters. I use mutt.
Yeah, sorry, it's a KMail problem. I'm not sure how to
On 2005-05-05, Peter Eisentraut [EMAIL PROTECTED] wrote:
Josh Berkus wrote:
Either the information schema adheres to
the spec, or it only covers 25% of PostgreSQL objects. There isn't
a 3rd alternative. I'm fine with merging this with the
information_schema (some of these views are
On 2005-05-05, Josh Berkus josh@agliodbs.com wrote:
This makes sense; I do wish that someone had mentioned it when I originally
raised the subject of new system views. It would have saved us some work.
I'd have raised it myself if I thought there was any mileage in it. As
you can probably
On Thu, May 05, 2005 at 08:15:27PM -, Andrew - Supernews wrote:
On 2005-05-05, Josh Berkus josh@agliodbs.com wrote:
This makes sense; I do wish that someone had mentioned it when I
originally raised the subject of new system views. It would have
saved us some work.
I'd have raised
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The purpose of the new system views...
As long as they are in a separate schema (like information_schema,
but hopefully not as long). pg_views? pg_info? information_skema? :)
But if you think that nobody needs these views, it's because you
Greg,
Well, who really *does* need these? After all, end users should be
using an interface of some sort. (DBD::Pg, phpPgAdmin, psql, etc). It's
the job of the people writing those interfaces to know the system
catalogs well and present them to the users in a pretty fashion. If
people want
On 2005-05-05, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
The purpose of the new system views...
As long as they are in a separate schema (like information_schema,
but hopefully not as long). pg_views? pg_info? information_skema? :)
The proof-of-concept implementation puts them in
On N, 2005-05-05 at 22:43 +, Greg Sabino Mullane wrote:
The purpose of the new system views...
As long as they are in a separate schema (like information_schema,
but hopefully not as long). pg_views? pg_info? information_skema? :)
But if you think that nobody needs these views, it's
On 2005-05-05, Josh Berkus josh@agliodbs.com wrote:
And, as Lance points out, these system views would help as a diagnostic view
for support engineers. Actually, I'll second that; I've had cause to
recommend the CVS system views more than a dozen times to pgsql newbies on
IRC. For
There are several things to address in the flurry of messages.
The first thing that the qa/support team did at Illustra was to
write a series of views on the system catalog. It was the most
pressing thing to do. Every single db engineer probably has one
or two or seven views to look at objects
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Andrew - Supernews
Sent: Thursday, May 05, 2005 4:55 PM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Views, views, views! (long)
On 2005-05-05, Josh Berkus josh
it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of elein
Sent: Thursday, May 05, 2005 4:55 PM
To: PostgreSQL-development
Cc: Josh Berkus; Peter Eisentraut
Subject: Re: [HACKERS] Views, views, views! (long)
There are several things
Dann,
1. There is not a whole lot of stuff that cannot be directly stored in
the INFORMATION_SCHEMA location without modifying it.
See Andrew's post. There is a whole lot of stuff not covered by I_S in a way
that is useful to PGSQL users. Also this would require making
information_schema
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 05, 2005 5:35 PM
To: Dann Corbit
Cc: elein; PostgreSQL-development; Peter Eisentraut
Subject: Re: [HACKERS] Views, views, views! (long)
Dann,
1. There is not a whole lot of stuff that cannot
, 2005 4:55 PM
To: PostgreSQL-development
Cc: Josh Berkus; Peter Eisentraut
Subject: Re: [HACKERS] Views, views, views! (long)
There are several things to address in the flurry of messages.
The first thing that the qa/support team did at Illustra was to
write a series of views
As Dave already pointed out, serious admin tools will avoid views. We
have to deal with version specific issues anyway.
I don't see why phpPgAdmin would avoid using the views, unless some
serious randomness happened that we had to support. The unimaginable
craziness of currently trying to
Hmmm ... we argued about this. I was in favor of hiding the OIDs because OIDs
are not consistent after a database reload and names are. I can see your
point though; what do other people think?
Well phpPgAdmin is unable to use the pg_tables view, for instance,
because we have no way of
On 2005-05-06, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Hmmm ... we argued about this. I was in favor of hiding the OIDs
because OIDs are not consistent after a database reload and names are.
I can see your point though; what do other people think?
Well phpPgAdmin is unable to use
Dann Corbit [EMAIL PROTECTED] writes:
2. Almost all of the information that cannot fit will be useful to
other database systems as well, and should be suggested to the ANSI/ISO
committee. Since INFORMATION_SCHEMA is a very new idea (only two
adopters that I know of so far) I expect it will
2. Almost all of the information that cannot fit will be useful to
other database systems as well, and should be suggested to the ANSI/ISO
committee. Since INFORMATION_SCHEMA is a very new idea (only two
adopters that I know of so far) I expect it will need to grow and
PostgreSQL could be one of
On Thursday 05 May 2005 19:37, Hannu Krosing wrote:
On N, 2005-05-05 at 22:43 +, Greg Sabino Mullane wrote:
The purpose of the new system views...
As long as they are in a separate schema (like information_schema,
but hopefully not as long). pg_views? pg_info? information_skema? :)
On Thursday 05 May 2005 19:17, Andrew - Supernews wrote:
On 2005-05-05, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
furthermore, writing the views has often required
delving into details of the backend implementation that are not well
documented. (See a recent discussion here on typmods for
I was starting to think this... like this should be a project on foundry
called enhanced system views that would be fairly database version
independant and people could install into any databases they needed them in.
You mean like:
http://pgfoundry.org/projects/newsysviews/
On 2005-05-06, Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 05 May 2005 19:17, Andrew - Supernews wrote:
On 2005-05-05, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
furthermore, writing the views has often required
delving into details of the backend implementation that are not well
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2005-05-06, Robert Treat [EMAIL PROTECTED] wrote:
On Thursday 05 May 2005 19:17, Andrew - Supernews wrote:
furthermore, writing the views has often required
delving into details of the backend implementation that are not well
documented. (See a
Tom, Andrew, Robert,
More to the point: how can you build a good interface on top of a
bad one? Whatever fundamental shortcomings exist in the latter cannot
be hidden by the former.
I think bad and good are pretty irrelevant myself. The system tables are
very good at what they do: support
PG hackers,
AndrewSN, Jim Nasby, Elein and I have been working for the last couple of
months on a new set of system views for PostgreSQL. (primarily Andrew, who
did the lion's share of the work and came up with many clever SQL
workarounds) We'd like to include them in the 8.1 release, so
Josh Berkus josh@agliodbs.com writes:
As stated above, these system views, once incorporated into a pg
distribution, are likely to be with us *forever*.
I dislike to burst your bubble, but this claim is ridiculous on its
face.
We don't whack the system catalogs around from release to release
Tom,
To put it more bluntly: exactly what are you accomplishing here that
isn't already accomplished, in a *truly* standard fashion, by the
INFORMATION_SCHEMA? Why do we need yet another nonstandard view on
the underlying reality?
To quote myself:
Q: Why not just use information_schema?
A:
Josh Berkus wrote:
PG hackers,
[snip]
What We Need From Hackers --
(other than patch approval, that is) As stated above, these system
views, once incorporated into a pg distribution, are likely to be
with us *forever*. As such, we really can't afford to do
Tim,
A nice thing to add would be a more human-comprehensible view of the
pg_locks table. I keep meaning to write a view for it myself, but
haven't ever gotten a round tuit.
Jim Nasby is working on that; see his other posts.
--
Josh Berkus
Aglio Database Solutions
San Francisco
79 matches
Mail list logo
