Josh Berkus wrote:
Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from a maintenance standpoint
it probably belongs on the same level.
Yeah, except PL/R has
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
pl-j and pl/java are working together to create a shared interface so
that
they can co-exist. This is the part that we wish to have added to the
main source
tree. It will just be the C portion of the code that does rely on the
backend.
Dave
Tom Lane wrote:
"Joshua D. Drake" [EMAIL
On 5/4/05, Russell Smith [EMAIL PROTECTED] wrote:
On Wed, 4 May 2005 04:40 am, Tom Copeland wrote:
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:
Of course, Mitch is running the second largest GForge site on the planet
(as far as I know) second only to
Hello.
Why pgplsql setof ... function cannot be used in field list of select?
It is possible to use C functions, plperl functions and sql functions,
but pgplsql returns:
ERROR: set-valued function called in context that cannot accept a set
CONTEXT: PL/pgSQL function my_gen_ser line 6 at return
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
Hi Dann,
I am also very happy you are interested in our work. I am working inside
the DB engine and have coauthored the work you are interested in; David
will happily share code with you. The latest and greatest on my side has
to do with componentization of database systems; we are using staging
Joe Conway [EMAIL PROTECTED] writes:
I've considered relicensing PL/R with a BSD license, but I haven't been
able to decide whether I really can do that given libR's GPL status, and
I'm afraid it might tick off the R core developers if I do.
The direction I see this going in wouldn't require
On Wednesday 04 May 2005 03:05, Oleg Bartunov wrote:
On Tue, 3 May 2005, Dann Corbit wrote:
http://www.cs.cmu.edu/~harchol/Papers/actual-icde-submission.pdf
thanks, interesting analysis. I've seen many papers where PostgreSQL
was used as a research database and wondering why we have no code
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 04, 2005 11:17 PM
To: Oleg Bartunov
Cc: Pgsql Hackers
Subject: Re: [HACKERS] 'infinity' in GiST index
[...]
Seems like it's not really GiST's fault but a definitional problem
for the timestamp
On Thu, 5 May 2005, Dave Cramer wrote:
pl-j and pl/java are working together to create a shared interface so
that they can co-exist. This is the part that we wish to have added to
the main source tree. It will just be the C portion of the code that
does rely on the backend.
Note that what Tom
Marc G. Fournier [EMAIL PROTECTED] writes:
Note that what Tom is proposing is actually yanking *all* PLs from the
core source tree, but having them all within the core CVS ... I believe
his motivation is that he only has one CVSROOT to set to get at all the
files, but that they are seperate
What we are proposing is just including the C code which will have no
external
dependancies.
We understand that building the java pl's requires many tools which are
not normally
available to people building the source.
Dave
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Note
On Thu, 5 May 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Note that what Tom is proposing is actually yanking *all* PLs from the
core source tree, but having them all within the core CVS ... I believe
his motivation is that he only has one CVSROOT to set to get at all the
Joe,
I've considered relicensing PL/R with a BSD license, but I haven't been
able to decide whether I really can do that given libR's GPL status, and
I'm afraid it might tick off the R core developers if I do.
Seems like you could ask them.
--
Josh Berkus
Aglio Database Solutions
San
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in sync that closely.
Can you have the same tags across different
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
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out, would
include all sub-modules, and that I can tag/branch appropriately ... if
Tom,
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like ) build system.Mind you, I'd really like such a build system, but
Peter Eisentraut wrote:
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in sync that closely.
Can you have
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out, would
include all sub-modules,
Josh Berkus josh@agliodbs.com writes:
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like ) build system.Mind you, I'd
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
Josh Berkus wrote:
Seems like you could ask them.
Done that. They give about the same reaction as we do when someone
suggests Postgres should be GPL'd
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Why not tack on the missing functionality to the INFORMATION_SCHEMA views?
A couple of new tables and foreign keys should do it, n'est ce pas?
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Josh Berkus
Sent: Wednesday, May 04, 2005
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
On Thu, 5 May 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out,
On 2005-05-05, Dave Held [EMAIL PROTECTED] wrote:
That's because you're talking about transfinite arithmetic, and
subtraction is not defined therein. AKA the arithmetic of
infinite cardinals. I've actually seen a few different
formulations, some of which say that adding a finite number to
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like )
On Thu, 5 May 2005, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in
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
Tom,
Uh, that's not exactly what is being proposed. It would be a separate
tarball that you could untar wherever you felt like, because it would
not depend on the core source tree at all --- only on the files
installed by a previous build of the core.
Still sounds good. Do you think that
Josh Berkus josh@agliodbs.com writes:
Still sounds good. Do you think that this system could be extended to other
add-ons in the future which are currently more complex builds? And allow us
to out some of the wierder things in /contrib?
The system already exists --- it's pgxs. We already
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
Tom,
I have no problem with pushing out any part of contrib that doesn't seem
tightly tied to the core server. I'm not entirely sure where to draw
the line, but for instance I'd probably want to keep dblink where it is,
since functions-returning-records are still in considerable flux.
Yes, I
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
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Still sounds good. Do you think that this system could be extended to other
add-ons in the future which are currently more complex builds? And allow us
to out some of the wierder things in /contrib?
The system already
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Tom Lane wrote:
I have no problem with pushing out any part of contrib that doesn't seem
tightly tied to the core server.
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP,
-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
Marc G. Fournier wrote:
Do we want to consider adding in a mirror of the JDBC/ODBC stuff in
the same way? Based on the direction we are taking, I'm all for it ..
the idea being that when beta starts, the JDBC folk (or ODBC, or ?)
would submit a mega patch to be applied to the tree and tag'd
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other stuff as time permits?
Agreed.
'k, if there are no disagreements ... I can't see there being
David F. Skoll [EMAIL PROTECTED] writes:
Supposing someone stupidly did this:
UPDATE pg_database SET datallowconn = false;
and then closed all the connections to the server.
Is there any way to recover short of nuking everything and
restoring from a backup dump? :-(
BTW, am I right in
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
On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:
'k, if there are no disagreements ... I can't see there being much we need
to do to get started ... I don't need a fully working and buildable
package to do the initial module load in CVS, so I think its pretty safe
to say
Marc G. Fournier wrote:
This is not to say that we might not want to adjust our
distribution setup so that it's easier for people to find 'em ---
that is, we could put JDBC/ODBC tarballs on the main ftp servers.
But I don't see the need for any coupling inside CVS.
Hrmmm, that would be
On Thu, 5 May 2005, Alvaro Herrera wrote:
On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:
'k, if there are no disagreements ... I can't see there being much we need
to do to get started ... I don't need a fully working and buildable
package to do the initial module load in CVS,
Tom Lane wrote:
Although I dislike last-minute fixes, I am strongly tempted to put in
the ignore-datallowconn-if-standalone change in all the releases we
are about to make.
That sounds very reasonable.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Thu, 5 May 2005, Peter Eisentraut wrote:
Marc G. Fournier wrote:
This is not to say that we might not want to adjust our
distribution setup so that it's easier for people to find 'em ---
that is, we could put JDBC/ODBC tarballs on the main ftp servers.
But I don't see the need for any coupling
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 20:21
To: Peter Eisentraut
Cc: Marc G. Fournier; Tom Lane; Josh Berkus;
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company
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
On Thu, 5 May 2005, Dave Held wrote:
but I doubt GiST will be happy if we make the datatype behave
that way...
I guess it depends on why you want to take the difference. If
you want to take some measure of distance, it might be useful
to say that all infinite values of the same sign are at 0
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 Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other stuff as time permits?
Agreed.
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 Thu, 5 May 2005, Robert Treat wrote:
On Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other
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
Marc,
all released at the same time, and tag'd the same way, and available under
the same ftp directory ...
Hmmm. As licensing permits, I think we should also offer a kitchen sink
download for those who want it. Which a lot of people will.
I believe that GreenPlum has a serious CVS hacker
On Thu, 5 May 2005, Josh Berkus wrote:
Marc,
all released at the same time, and tag'd the same way, and available under
the same ftp directory ...
Hmmm. As licensing permits, I think we should also offer a kitchen sink
download for those who want it. Which a lot of people will.
'k, how do you
On Wed, 4 May 2005, Tom Lane wrote:
I figured out part of the problem: I had made nodeBitmapIndexscan
re-open the index on each call, thinking that that would save amrescan
calls. But an amrescan is a whole lot cheaper than index open/close,
so that was a bad tradeoff.
This seems to
Oleg Bartunov oleg@sai.msu.su writes:
On Thu, 5 May 2005, Dave Held wrote:
I guess it depends on why you want to take the difference. If
you want to take some measure of distance, it might be useful
to say that all infinite values of the same sign are at 0 distance
from each other, in which
Marc,
I've seen some projects where configure *calls* configure in sub
directories ... but that becomes a build issue if someone wants to try and
tackle that?
Yes, that's what I was proposing that I pitch to the folks at Greenplum that
they help with. Might be hard, though, because they're
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Although I dislike last-minute fixes, I am strongly tempted to put in
the ignore-datallowconn-if-standalone change in all the releases we
are about to make.
That sounds very reasonable.
Done.
regards, tom
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 21:08
To: Robert Treat
Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
in
Sergey E. Koposov [EMAIL PROTECTED] writes:
And I coadded the flat profiles of first two (index scan) queries and
compared it with the flat profile of bitmap scan:
Thanks, I had been thinking of doing that same calculation but hadn't
got round to it yet. It looks like the bitmap case is
On Thu, 5 May 2005, Josh Berkus wrote:
Marc,
I've seen some projects where configure *calls* configure in sub
directories ... but that becomes a build issue if someone wants to try and
tackle that?
Yes, that's what I was proposing that I pitch to the folks at Greenplum that
they help with. Might
Andrew Dunstan wrote:
After some further digging, I think we have 3 problems.
1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
On Thu, 5 May 2005, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 21:08
To: Robert Treat
Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased
dbsize.tar.gz
btree_gist.tar.gz
etc
The end result wouldn't have enough in the *core* module to warrant a
split-dist anymore, since all of what would be left would be what is
required for a build ...
I know some of this is symantic but I think it would be better to
Marc G. Fournier wrote:
But we need at least one of them ready for a standalone build first ...
PL/Java might be ready. Depends on your definition of standalone build
of course. Can you elaborate?
Regards,
Thomas Hallgren
---(end of broadcast)---
On Thu, 5 May 2005, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
And I coadded the flat profiles of first two (index scan) queries and
compared it with the flat profile of bitmap scan:
Thanks, I had been thinking of doing that same calculation but hadn't
got round to it
On Thu, 5 May 2005, Joshua D. Drake wrote:
dbsize.tar.gz
btree_gist.tar.gz
etc
The end result wouldn't have enough in the *core* module to warrant a
split-dist anymore, since all of what would be left would be what is
required for a build ...
I know some of this is
Commenting more broadly on the whole thread, I think that
more tarballs
is a bad thing. I already get emails (both to webmaster and
privately)
from people not understanding what to download - more files
will only
make that worse.
Going this route will eliminate alot of the confusion,
On Thu, 5 May 2005, Thomas Hallgren wrote:
Marc G. Fournier wrote:
But we need at least one of them ready for a standalone build first ...
PL/Java might be ready. Depends on your definition of standalone build of
course. Can you elaborate?
could I download a tar file to my machine that already
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
I'm checking to see whether I can post. Nothing to see here.
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
---(end of broadcast)---
TIP 6: Have you searched our
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
Folks,
I'd like to find 2 major code contributors to PostgreSQL to be interviewed
(via e-mail) for a Brazillian online magazine.
Please e-mail me privately.
Thanks!
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
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
On Thu, 5 May 2005, Magnus Hagander wrote:
Actually, if the number of split files (whatever their names) increase
even further, may I suggest they are moved into a subdir of their own,
keeping just the main distribution and the README about the splits in
the main dir?
the main distribution will
-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
INFORMATION_SCHEMA is what should be exposed to the end-users of
PostgreSQL.
Pg_schema (for lack of a better name for internal metadata) can be
useful as well for all sorts of special purposes. Probably,
INFORMATION_SCHEMA (as designed by the SQL Standards committee) does not
need to worry about
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
On Thu, May 05, 2005 at 05:24:43PM -0700, Dann Corbit wrote:
INFORMATION_SCHEMA is what should be exposed to the end-users of
PostgreSQL.
Pg_schema (for lack of a better name for internal metadata) can be
useful as well for all sorts of special purposes. Probably,
INFORMATION_SCHEMA (as
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
Or, rather, I'm rebuilding 7.2.8 since the tar file looked wrong the first
build ... but the other three are done, and 7.2.x *should* be by the time
y'all see this ...
Let me know if anyone sees any problems with them ...
Marc G. Fournier Hub.Org Networking Services
Any objections to my creating an 'old' directory and moving the old
versions into it, so that only the latest release on each 'branch' is
visible in /pub/source?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
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? :)
1 - 100 of 113 matches
Mail list logo
