On Wed, 4 May 2005 21:37:40 -0700, Josh Berkus
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 schema,
say pg_views8
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
"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 _pg_sv_sy
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 useles
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
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 fund
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 restri
> 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 sc
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 t
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.
Postgr
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 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
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
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
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
> qu
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 wou
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 supp
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 catalo
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
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 peopl
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 tha
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 maintai
"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 p
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 give
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 me
-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-
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
7.3/7.4
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
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
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 pgFo
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
> p
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 y
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
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
>>> docu
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 no
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 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 typmod
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_sk
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
"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
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
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 gett
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 suppo
; > -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] View
> -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.
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: [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)
&
> -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-0
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 i
On 2005-05-05, Josh Berkus 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 example, there is an
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
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 p
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 wa
-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
> ha
On Thu, May 05, 2005 at 08:15:27PM -, Andrew - Supernews wrote:
> On 2005-05-05, Josh Berkus 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
On 2005-05-05, Josh Berkus 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 guess, I don't.
in
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
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
On Thu, May 05, 2005 at 14:26:56 +0400,
Oleg Bartunov 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 characters. I us
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
>
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 thin
> -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 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
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
re
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 a
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
Wednesday, May 04, 2005 10: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* standar
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
reada
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 inf
"Dave Page" 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 path on newer servers
Josh Berkus 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: Why no
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_na
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, sc
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 phpPgAdmi
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
-
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 maj
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?
Josh Berkus 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 just
because we'd
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 we'
79 matches
Mail list logo