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
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
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
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 PROTEC
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 https://helixc
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 retur
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
"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
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 t
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 req
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
> -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 timest
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 is
"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
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 Fran
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 differ
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
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
not,
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 the
"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-m
Josh Berkus 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 really like such
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
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, w
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 nu
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus 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
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 s
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
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 tha
Josh Berkus 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 have a report
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
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.
Ye
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
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus 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
"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 lik
> -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 o
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 much
"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
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
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
> t
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
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 i
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
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
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 dist
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 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?
>
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
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 st
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
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 hacke
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 en
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
Oleg Bartunov 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 case yo
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'r
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.
regard
> -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
>
>
"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
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 b
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
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 company
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 hav
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
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 sym
>> 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 c
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 h
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
-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
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 l
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
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
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
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 broadcast)
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
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 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" w
> -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 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 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 th
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 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
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
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
"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
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 (http://www.hu
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_sk
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
1 - 100 of 117 matches
Mail list logo
