Another example is the recent patch to check if there are orphaned file
system files. That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today. Anyone has the
ability to argue their point and try to sway the community, and any
member has
Bruce Momjian wrote:
(Funny, no one says I have too much power. I will have to look into how
to get some someday.) :-)
I think you have power, too. :-) You have commited many patches that some
other commiters didn't like that much and would rather not have applied
themselves. All with some
We've had a couple of cases recently where we had to advise DBAs to make
manual changes in the system catalogs --- see for instance the 7.4.2
release notes or
http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php
It'd be nicer if this sort of thing could be handled automatically
by a
Neil Conway wrote:
We don't currently depend on C99, and not all platforms have a 64-bit
datatype. In any case, I'm still unconvinced that using `int' and
`long' in backend APIs is a problem.
Using long means that you sometimes get a 32-bit value and sometimes a
64-bit value, I think we agree
I noticed that explain analyze emits a little bit funny reslut for
bitmap scans:
BitmapOr (cost=157.36..157.36 rows=18894 width=0) (actual time=9.406..9.406
rows=0 loops=1)
Why actual rows=0?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 8:
On 5/2/05, Heikki Linnakangas [EMAIL PROTECTED] wrote:
What we can do in PostgreSQL is to introduce an application-level
heartbeat. A simple Hello world message sent from server to client that
the client would ignore would do the trick.
Hmm, a quick-and-dirty implementation could be that a
On E, 2005-05-02 at 18:47 +0300, Heikki Linnakangas wrote:
On Mon, 2 May 2005, Hannu Krosing wrote:
It would be nice if I coud st up some timeut using keepalives (like ssh-
s ProtocoKeepalives) and use similar timeouts on client and server.
FWIW, I've been bitten by this problem twice
On E, 2005-05-02 at 15:59 -0500, Jim C. Nasby wrote:
Out of curiosity, what would be required to allow deletes (but not
updates)?
Deletes *are* the problem (and update is internally a delete+insert).
Allowing deletes means no more selects from indexes only as tid can't be
used for determining
On E, 2005-05-02 at 15:59 -0500, Jim C. Nasby wrote:
Out of curiosity, what would be required to allow deletes (but not
updates)?
Perhaps a CLUSTER indexname ON tablename WHERE xxx could be used for
that.
That is a CLUSTER command that leaves out the tuples which do not
satisfy xxx.
--
On E, 2005-05-02 at 23:59 +0200, Jochem van Dieten wrote:
On 5/2/05, Jim C. Nasby wrote:
I think the advantages of both the ability to append to and delete
from an archived table are largely negated with the design for table
partitioning as emerging from the work of Simon e.a. on the bizgres
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How will a separate compile stage work for actually
We've had a couple of cases recently where we had to advise
DBAs to make manual changes in the system catalogs --- see
for instance the 7.4.2 release notes or
http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php
It'd be nicer if this sort of thing could be handled
Are there any regression tests or unit tests beyond 'make check', or
possibly benchmarks which not only measure performance but also verify
that the results are correct? I have patches which I want to test
under high load from multiple concurrent clients, so 'make check'
isn't enough. Google has
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
Well, there's nothing that says you have to actually refer to locks by
name. When I proposed this what I proposed is that the userlock module
provide a dedicated means to map a lock name to a lock number, and
reserve one of the
Are there any regression tests or unit tests beyond 'make check', or
possibly benchmarks which not only measure performance but also verify
that the results are correct? I have patches which I want to test
under high load from multiple concurrent clients, so 'make check'
isn't enough. Google has
Hannu Krosing [EMAIL PROTECTED] writes:
What we can do in PostgreSQL is to introduce an application-level
heartbeat. A simple Hello world message sent from server to client that
the client would ignore would do the trick.
Actually we would need a round-trip indicator (some there-and-back
Tatsuo Ishii [EMAIL PROTECTED] writes:
Why actual rows=0?
I couldn't think of any reasonably cheap way to count the actual rows
(especially in the presence of lossy bitmaps), so I just punted.
regards, tom lane
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How will a
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 9:31 AM
To: Hannu Krosing
Cc: Heikki Linnakangas; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature
On Tue, 3 May 2005, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive
Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 7:05 PM
To: [EMAIL PROTECTED]
Cc: Dave Held; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company involvement
Joshua D. Drake wrote:
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.
--
Peter Eisentraut
hello there
does postgresql support distributed database
tq
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
mohammad izwan ibrahim wrote:
does postgresql support distributed database
The answer is no, but please pick the correct mailing list for such
questions in the future.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Hi, Josh,
Josh Berkus wrote:
Yes, actually. We need 3 different estimation methods:
1 for tables where we can sample a large % of pages (say, = 0.1)
1 for tables where we sample a small % of pages but are easily estimated
1 for tables which are not easily estimated by we can't afford to
On Tue, 3 May 2005, Tom Lane wrote:
I am a tad worried about the possibility that if the client does nothing
for long enough, the TCP output buffer will fill causing the backend to
block at send(). A permanently blocked backend is bad news from a
performance point of view (it degrades the sinval
Marc G. Fournier wrote:
On Tue, 3 May 2005, Tom Lane wrote:
I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.
That is what I'm hoping for ... if it can be shipped as a seperate
tarball, my arguments
Peter Eisentraut wrote:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
I posted this compromise and no one replied so I thought everyone was OK
with it. It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.
How will a separate compile stage
I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...
We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...
I tried disabling public EXECUTE access on the built-in conversion
functions, as we recommended yesterday, and found that it has one
small problem: the conversion regression test fails. The test is
expecting that unprivileged users can create conversions, but since
CREATE CONVERSION requires you
I don't mind if its *also* ship'd in the main distribution as well, I
just want that 'quick to download since I already have the
libraries/headers installed' package ...
Any other PL's not currently in your CVS that you might consider to
bring in while you're at it?
/me heres the sound of the
On Tue, 3 May 2005, Thomas Hallgren wrote:
Marc G. Fournier wrote:
On Tue, 3 May 2005, Tom Lane wrote:
I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.
That is what I'm hoping for ... if it can be shipped
On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:
Joshua D. Drake wrote:
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.
On Tue, 3 May 2005, Joshua D. Drake wrote:
I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...
We could break out all of the pls at that point? Where if you downloaded
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can
be accomplished, then my main objection to adding things to the core CVS
are eliminated ...
I guess I don't see the problem of the PostgreSQL distribution
Dave Held wrote:
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 7:05 PM
To: [EMAIL PROTECTED]
Cc: Dave Held; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
Increased
company
Heikki Linnakangas [EMAIL PROTECTED] writes:
Does statement_timeout fire on that scenario? How about the new
transaction_timeout option discussed in other threads?
Probably neither, since very likely you aren't in a transaction at all.
I'd not expect the server to send these messages except
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues.
Robert Treat [EMAIL PROTECTED] writes:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 12:39 PM
To: Heikki Linnakangas
Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar ball(s)
in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...
I guess I don't see
On Tue, 3 May 2005, Marc G. Fournier wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core
Robert Treat wrote:
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are
Mitch Pirtle wrote:
On 4/30/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
If you guys are planning on running Gforge, then you better make 'box' plural.
Well we already run it :) For pgFoundry and you are correct
* Robert Treat ([EMAIL PROTECTED]) wrote:
If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.
The problem stems from things like the php rpm spec, which has a module
dependency on
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
where multi is a MultiXactId and xid is a TransactionId.
Isn't this bogus? If I understand the code correctly, multixactids and
regular xids live in completely separate id
On Tue, 3 May 2005, Andrew Dunstan wrote:
Robert Treat wrote:
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that
On Tue, May 03, 2005 at 09:33:30PM +0300, Heikki Linnakangas wrote:
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
where multi is a MultiXactId and xid is a TransactionId.
Isn't this bogus? If I understand the
* Tom Lane ([EMAIL PROTECTED]) wrote:
Robert Treat [EMAIL PROTECTED] writes:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
I wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Isn't this bogus?
No. Note the comment immediately above, as well as the header comment
for the function.
OTOH, now that I think about it there's no reason whatever for that
bizarre call convention. Let's split the function into two:
Heikki Linnakangas [EMAIL PROTECTED] writes:
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
where multi is a MultiXactId and xid is a TransactionId.
Isn't this bogus?
No. Note the comment immediately above, as
Marc G. Fournier wrote:
Now it is true that you don't need this in for plphp. But if you want
php to have pg client support you need pg built first. And no sane
packager is going to build php twice.
Actually, if you look through FreeBSD ports, this is exactly what
happens ... when you build
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
On Tue, 3 May 2005, Andrew Dunstan wrote:
Now it is true that you don't need this in for plphp. But if you want php
to have pg client support you need pg built first. And no sane packager is
going to build php twice.
Actually, if you look
Stephen Frost wrote:
Just to point it out, Debian handles circular dependencies like these
without too much difficulty. It's really only an issue when first
building the various packages, and then you just build one without
all the support initially, build the other, then rebuild the first
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...
Optimally, you would get rid of -opt altogether, and leave it as the
On Tue, 3 May 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
Now it is true that you don't need this in for plphp. But if you want php
to have pg client support you need pg built first. And no sane packager is
going to build php twice.
Actually, if you look through FreeBSD ports, this is
On Tue, May 03, 2005 at 02:48:20PM -0400, Tom Lane wrote:
I wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Isn't this bogus?
No. Note the comment immediately above, as well as the header comment
for the function.
OTOH, now that I think about it there's no reason whatever for
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Just to point it out, Debian handles circular dependencies like these
without too much difficulty. It's really only an issue when first
building the various packages, and then you just build one without
all the support
Alvaro Herrera [EMAIL PROTECTED] writes:
No problem ... shall I write a patch, or did you do it already?
I'll take care of it --- wouldn't take much longer than applying
someone else's patch anyway ...
regards, tom lane
---(end of
That's a matter of opinion ... in our environment, it means that clients
can enable/disable PHP features on a per VM basis without having to
build a new PHP binary for each ... *shrug*
Gentoo also does this :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Marc G. Fournier wrote:
How ugly. [remaining comments unprintable]
That's a matter of opinion ... in our environment, it means that
clients can enable/disable PHP features on a per VM basis without
having to build a new PHP binary for each ... *shrug*
Different issue. You can do that on RH
Marc G. Fournier wrote:
On Tue, 3 May 2005, Marc G. Fournier wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that
can be accomplished, then my main objection to
Never mind. multi is in effect a TransactionId in that code path, and thus
the assertion makes sense. Sorry for the noise.
On Tue, 3 May 2005, Heikki Linnakangas wrote:
There's an assertion in multixact.c, MultiXactIdExpand function, line 273:
Assert(!TransactionIdEquals(multi, xid));
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball is
too big ( or have we )
Because ppl are downloading the split distributions instead of the whole
tarball ... *every* PostgreSQL related port in FreeBSD uses the
split-dists (only
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
Because ppl are downloading the split distributions instead of the
whole tarball ... *every* PostgreSQL related port in FreeBSD uses
So nobody has complained about the tarball being too big; yet we made
it harder to use just in case someone might complain ?
--dc--
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:
If you guys are planning on running Gforge, then you better make 'box' plural.
I'm running MamboForge.net, and the poor thing is getting beat into
the cold hard earth every day. We (Mambo) should really have two
servers, at least to
On Tue, 3 May 2005 13:02:46 -0500
Dave Held [EMAIL PROTECTED] wrote:
How about an optional second connection to send keepalive
pings?
It could be unencrypted and non-blocking. If
authentication is needed
on the ping port (which it doesn't seem like itwould
needto be),
it could be very simple,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The whole point of make check is to check correctness, not
performance.
I understand that.
It has concurrent loading as well.
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
DES
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 3:36 PM
To: Dave Held; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature freeze date for 8.1
[...]
Yes, this looks like good.But ;
1. Do client interfaces
Dave Held [EMAIL PROTECTED] writes:
How about an optional second connection to send keepalive pings?
It could be unencrypted and non-blocking. If authentication is
needed on the ping port (which it doesn't seem like it would need
to be), it could be very simple, like this:
* client connects
On 5/3/05, Dave Held [EMAIL PROTECTED] wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 12:39 PM
To: Heikki Linnakangas
Cc: Hannu Krosing; Neil Conway; Oliver Jowett;
[EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera;
Quoting Markus Schaber [EMAIL PROTECTED]:
Hi, Josh,
Josh Berkus wrote:
Yes, actually. We need 3 different estimation methods:
1 for tables where we can sample a large % of pages (say, = 0.1)
1 for tables where we sample a small % of pages but are easily
estimated
1 for tables
Mischa,
Okay, although given the track record of page-based sampling for
n-distinct, it's a bit like looking for your keys under the streetlight,
rather than in the alley where you dropped them :-)
Bad analogy, but funny.
The issue with page-based vs. pure random sampling is that to do, for
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 4:20 PM
To: Dave Held
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature freeze date for 8.1
Dave Held [EMAIL PROTECTED] writes:
How about an optional second connection to send
Tom Lane [EMAIL PROTECTED] writes:
Dave Held [EMAIL PROTECTED] writes:
How about an optional second connection to send keepalive pings?
It could be unencrypted and non-blocking. If authentication is
needed on the ping port (which it doesn't seem like it would need
to be), it could be very
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Dave Held
Sent: Tuesday, May 03, 2005 3:41 PM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Feature freeze date for 8.1
-Original Message-
From: Tom Lane
Dave Held wrote:
So it seems that a possible solution to that problem is to
have a separate connection for keepalive packets that doesn't
block and doesn't interfere with normal client/server
communication.
What does this do that TCP keepalives don't? (other than add extra
connection
On Tue, 3 May 2005, Dave Cramer wrote:
So nobody has complained about the tarball being too big; yet we made it
harder to use just in case someone might complain ?
Made what harder to use? You don't like the split, download the full tar
ball ... both options are available to you ... myself, I
On Tue, 3 May 2005, Joshua D. Drake wrote:
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball
is too big ( or have we )
Because ppl are downloading the split distributions instead of the whole
tarball ...
I tried disabling public EXECUTE access on the built-in conversion
functions, as we recommended yesterday, and found that it has one
small problem: the conversion regression test fails. The test is
expecting that unprivileged users can create conversions, but since
CREATE CONVERSION requires
John,
But doesn't an index only sample one column at a time, whereas with
page-based sampling, you can sample all of the columns at once.
Hmmm. Yeah, we're not currently doing that though. Another good idea ...
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Dag-Erling Smørgrav wrote:
It doesn't stress the system anywhere near enough to reveal bugs in,
say, the shared memory or semaphore code.
I agree -- I think we definitely need more tests for the concurrent
behavior of the system.
-Neil
---(end of
Dave, all:
This issue has come up before, and I opposed it then when the interfaces
were removed from the main tarball.
I really don't see the upside to reducing the size of the tarball at the
expense of ease of use. Seems to me we are
bending over backwards to make it easy for people with
Josh Berkus said:
Dave, all:
This issue has come up before, and I opposed it then when the
interfaces were removed from the main tarball.
I really don't see the upside to reducing the size of the tarball at
the expense of ease of use. Â Seems to me we are
bending over backwards to make it
On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
Well, there's nothing that says you have to actually refer to locks by
name. When I proposed this what I proposed is that the userlock module
provide a dedicated
Tatsuo Ishii [EMAIL PROTECTED] writes:
Going forward, though, I really think we need to revisit the API
for conversion functions. It seems a bit silly to have the
infrastructure to let ordinary users create conversions if they
can't create the functions needed to support them.
Why? Since
Quoting Josh Berkus josh@agliodbs.com:
Mischa,
Okay, although given the track record of page-based sampling for
n-distinct, it's a bit like looking for your keys under the
streetlight,
rather than in the alley where you dropped them :-)
Bad analogy, but funny.
Bad
Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Tue, 2005-05-03 at 18:06 -0700, Josh Berkus wrote:
1) If we start including everything that's useful, where do we stop? There
are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and
others elsewhere. And some of them probably conflict with each other. Any
On 2005-05-04, John Hansen [EMAIL PROTECTED] wrote:
Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
nonsense
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services
---(end of
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
1998 when the oid played a larger role, it is now quite rightly
deprecated and my intention is to remove it from the userlock module.
I wish you wouldn't since http://rrs.decibel.org uses
Andrew,
I was not around at the time of the libpq++/libpqxx issue. But, honestly,
fear of making a wrong decision should not be a reason not to make one.
OK, *you* choose. I'm getting a little annoyed with how many people tell me
oh, it should be easy to pick the stuff to include with
Andrew Dunstan [EMAIL PROTECTED] writes:
As for CVS - if we can't do development the way we want using it then it's
time to replace it.
CVS's capabilities (or lack of same) are completely unrelated to the
matter in hand. What we are talking about is packaging, ie what should
sensibly go out in
John Hansen [EMAIL PROTECTED] writes:
Are there any encodings we care about that require embedded zero
bytes?
UTF-8 does!
Surely not. Were you thinking of UTF-16 or UCS-2 or whatever it's
called?
regards, tom lane
---(end of
1 - 100 of 111 matches
Mail list logo
