On Fri, May 06, 2005 at 02:59:04PM +1000, Neil Conway wrote:
> Is there a good reason that pl/pgsql is not installed in databases by
> default?
The only reason I've seen was "if we start with including plpgsql, where
do we draw the line?" Personally, I think it should be installed by
default.
--
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
Josh Berkus wrote:
The only one I can think of is "security", which is pretty weak -- we've never
had a plpgsql security issue that I know of.
Well, no -- for instance,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0245
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0247
But I agr
Neil,
> Is there a good reason that pl/pgsql is not installed in databases by
> default?
The only one I can think of is "security", which is pretty weak -- we've never
had a plpgsql security issue that I know of.
--
Josh Berkus
Aglio Database Solutions
San Francisco
--
Christopher Kings-Lynne wrote:
Problem is people restoring dumps that have the plpgsql create language,
etc. commands in them.
It should be possible to ignore those commands, and possibly issue a
warning. It's a bit ugly, but at least we can detect this situation
pretty unambiguously.
-Neil
---
Is there a good reason that pl/pgsql is not installed in databases by
default?
I think it should be. pl/pgsql is widely used, and having it installed
by default would be one less hurdle for newbies to overcome when
learning PostgreSQL. It would also make it easier to distribute
applications th
> PgFoundry has been brought up quite a bit lately. How we want
> it to succeed, how we want it to be the hub of PostgreSQL development.
> So my question is... Why isn't it?
Speaking only for myself, I volunteered to have my project moved over
first as a test case. This was agreed, the original p
Is there a good reason that pl/pgsql is not installed in databases by
default?
I think it should be. pl/pgsql is widely used, and having it installed
by default would be one less hurdle for newbies to overcome when
learning PostgreSQL. It would also make it easier to distribute
applications th
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Let me know if anyone sees any problems with them ...
Tarballs match what I have here ... except it looks like you are
regenerating the 7.3 HISTORY and INSTALL files using slightly different
tools than what was committed into CVS. I'm not sure it's
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/
---
Hello,
PgFoundry has been brought up quite a bit lately. How we want
it to succeed, how we want it to be the hub of PostgreSQL development.
So my question is... Why isn't it?
Why is PostgreSQL not hosted at pgFoundry?
It seems that it has everything we would need?
To keep this on track, consider my
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
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
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
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
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 (
> -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
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
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
> -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:
>
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
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
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 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
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
-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 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
>> 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, 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
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
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)---
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
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
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, 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
"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
> -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
>
>
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
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
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
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
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 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 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, 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 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?
>
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
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, 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
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
> -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
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, 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
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/
--
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, 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
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, 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
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
"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
> -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" <[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
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
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
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
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
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
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
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
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
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 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:
"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
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
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:
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
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 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
"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
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
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
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, 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
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
1 - 100 of 117 matches
Mail list logo
