On Mon, Jan 01, 2007 at 05:53:35PM -0500, Tom Lane wrote:
The SQL2003 spec adds optional NULLS FIRST and NULLS LAST modifiers
for ORDER BY clauses. Teodor proposed an implementation here:
http://archives.postgresql.org/pgsql-patches/2006-12/msg00019.php
which I didn't care for at all:
On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
FWIW, I'm running into this trying to create a 'raw' domain that would
automagically convert hex strings into actual binary data for storage in
a bytea.
I think
I'd like to see this implemented with more general collation support in
mind.
In general, each index column can be ordered by one collation. A query
matching the index collation can use the index directly, a query asking
for another collation needs to convert. The trivial way to convert from
Am Sonntag, 24. Dezember 2006 02:44 schrieb Tom Lane:
* Isn't mapping XMLSERIALIZE to a cast completely wrong? Aside from
the issue already noted in the code that it won't reverse-list
correctly, this loses the DOCUMENT-vs-CONTENT flag, which I suppose
must be important.
It is important, but
Am Mittwoch, 27. Dezember 2006 02:56 schrieb Euler Taveira de Oliveira:
This simple patch lets someone specifies the xlog directory at initdb
time. It uses symlinks to do it, and create and/or set permissions at
the directory as appropriate.
We already had this functionality in initdb a few
Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits.
How about a configuration option related to connection throughput, which is
typically measured in bits?
--
Peter Eisentraut
Am Donnerstag, 28. Dezember 2006 19:52 schrieb Tom Lane:
Not only is it overzealous, but the proposal to have one reflects a
failure to learn from history. GUC variables that change
transaction-boundary semantics are a bad idea, period: see autocommit.
But this option would not, in fact,
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
I think you can make the case that this should be an error, or at least
that's how it got on the TODO list. I can always remove it if people
don't want the item completed.
The reason this was added is that modular applications
Jeremy Drake said:
http://momjian.us/mhonarc/patches_hold/msg00162.html
There is no patch or anything associated with it, just the
suggestion that it be put in when 8.3 devel starts up.
Right -- this is on my TODO list for 8.3. I'm traveling at the
moment, but I can send a patch for this in a
Martijn van Oosterhout kleptog@svana.org writes:
Issues which you havn't addressed are:
- Pathkeys: How is the forward/reverse/nulls first/last going to be
encoded in the pathkey?
I'm envisioning a struct with operator OID and null-ordering flag.
If we implement the explicit REVERSE variant
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'd like to see this implemented with more general collation support in
mind.
I'm really not prepared to buy into that, simply because it puts ICU or
some equivalent large chunk of new code into the critical path to finish
what I'm doing. The fact
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
I think you can make the case that this should be an error, or at least
that's how it got on the TODO list. I can always remove it if people
don't want the item completed.
The reason
Jim C. Nasby wrote:
On Mon, Jan 01, 2007 at 06:30:40PM -0600, Andrew Dunstan wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
FWIW, I'm running into this trying to create a 'raw' domain that would
automagically convert hex strings into actual binary data for
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'd like to see this implemented with more general collation support in
mind.
I'm really not prepared to buy into that, simply because it puts ICU or
some equivalent large chunk of new code into the critical path to finish
what I'm
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 27. Dezember 2006 02:56 schrieb Euler Taveira de Oliveira:
This simple patch lets someone specifies the xlog directory at initdb
time. It uses symlinks to do it, and create and/or set permissions at
the directory as appropriate.
We
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits.
How about a configuration option related to connection throughput, which is
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
I think you can make the case that this should be an error, or at least
that's how it got on the TODO list. I can always remove it if people
don't want the item completed.
news.postgresql.org wrote:
While we are on the topic, I have implemented a poor mans nested
transaction feature into my database access layer. essentially
subsequent calls to begin a transaction after the initial begin simply
increase an internal counter and set a savepoint. as you commit
Alvaro Herrera wrote:
news.postgresql.org wrote:
While we are on the topic, I have implemented a poor mans nested
transaction feature into my database access layer. essentially
subsequent calls to begin a transaction after the initial begin simply
increase an internal counter and set a
On Tue, 2007-01-02 at 11:53 +0100, Peter Eisentraut wrote:
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
I think you can make the case that this should be an error, or at least
that's how it got on the TODO list. I can always remove it if people
don't want the item
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Err, I think you misunderstood what I said. My implementation uses
SAVEPOINTs already. The point is having some API where you do not have
to care of you are already in a transaction or not.
It's not that hard, is it?
if
On Sat, 2006-12-30 at 13:35 -0600, Jim C. Nasby wrote:
My current implementation relies on the scans to stay close together
once they start close together. If one falls seriously behind, it will
fall outside of the main cache trail and cause the performance to
degrade due to disk seeking
On 1/2/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
E.g., no GUC parameter. Just change the behavior or don't.
Please refer the conversation beginning at:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00249.php
That is where this TODO item came from. In the conversation, it was
Stephen Frost wrote:
* David Boreham ([EMAIL PROTECTED]) wrote:
Fascinating thread for the holidays. I found it interesting that nobody
has mentioned
NSS (former Netscape SSL library). It has its own bag of problems of
course, but
for me is potentially more attractive than GNU TLS. e.g. it
* David Boreham ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Not sure what license that's under,
From http://www.mozilla.org/projects/security/pki/nss/:
'NSS is available under the Mozilla Public License, the GNU General
Public License, and the GNU Lesser General Public License.'
Works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Oh! Duh, that's your issue right there, I'll bet. The problem is that
relcache-open tries to read the pg_class row under SnapshotNow rules,
and if there is another xact concurrently modifying the row, it is
entirely possible
David Boreham wrote:
Stephen Frost wrote:
* David Boreham ([EMAIL PROTECTED]) wrote:
Fascinating thread for the holidays. I found it interesting that
nobody has mentioned
NSS (former Netscape SSL library). It has its own bag of problems of
course, but
for me is potentially more attractive
I have been able to crash the database consistently on a Fedora Core 5
machine running postgresql 8.2.0.
The attached files are an example database (crash.shema) and the query
that is used (crash.sql) as well as the log output from turning on all the
debugging (crash.log).
I have a couple
Stephen Frost wrote:
* David Boreham ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Not sure what license that's under,
From http://www.mozilla.org/projects/security/pki/nss/:
'NSS is available under the Mozilla Public License, the GNU General
Public License, and the GNU
Andrew Dunstan [EMAIL PROTECTED] writes:
Also, do we really want to import the NSPR into Postgres? I suspect not.
Of course, the only thing that people are tripping over license-wise is
libpq. But I think we would want to keep that as lean and mean as
possible, too.
Yeah, requiring NSPR to
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 27. Dezember 2006 02:56 schrieb Euler Taveira de Oliveira:
This simple patch lets someone specifies the xlog directory at initdb
time. It uses symlinks to do it, and create and/or set permissions at
the directory as
Tom Lane wrote:
Lukas Kahwe Smith [EMAIL PROTECTED] writes:
Err, I think you misunderstood what I said. My implementation uses
SAVEPOINTs already. The point is having some API where you do not have
to care of you are already in a transaction or not.
It's not that hard, is it?
if
Andrew Dunstan wrote:
I suspect most postgres developers and companies would like to keep
things as BSDish as possible.
Right, hence OpenSSL would be the obvious best choice.
In respect of licencing however, NSS is no 'worse' than GNU TLS
because it may be distributed under the GPL and LGPL.
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Tom Lane wrote:
Oh! Duh, that's your issue right there, I'll bet. The problem is that
relcache-open tries to read the pg_class row under SnapshotNow rules,
and if there is another xact concurrently modifying the row, it is
entirely possible for
D. Hageman dhageman@dracken.com writes:
I have been able to crash the database consistently on a Fedora Core 5
machine running postgresql 8.2.0.
Yeah, LIMIT ALL is known broken in 8.2.0 :-(. It's been fixed for
awhile, will be in 8.2.1.
regards, tom lane
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
I suspect most postgres developers and companies would like to keep
things as BSDish as possible. Dealing with a multitude of licenses might
be fun for some, but many of us find it a pain in the neck.
It'd be great if PostgreSQL could use an SSL
* David Boreham ([EMAIL PROTECTED]) wrote:
Andrew Dunstan wrote:
I suspect most postgres developers and companies would like to keep
things as BSDish as possible.
Right, hence OpenSSL would be the obvious best choice.
In respect of licencing however, NSS is no 'worse' than GNU TLS
Stephen Frost wrote:
Also, do we really want to import the NSPR into Postgres? I suspect not.
Of course, the only thing that people are tripping over license-wise is
libpq. But I think we would want to keep that as lean and mean as
possible, too.
erm, I'm not really sure what you're
On Jan 2, 2007, at 7:18 AM, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 27. Dezember 2006 02:56 schrieb Euler Taveira de
Oliveira:
This simple patch lets someone specifies the xlog directory at
initdb
time. It uses symlinks to do it, and create and/or set
* David Boreham ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
erm, I'm not really sure what you're saying here but perhaps I can
clarify: I wasn't suggesting to add any serious amount of source code
to PostgreSQL - NSS would be used just as OpenSSL is today, and as
GNUTLS support was
Stephen Frost wrote:
-- Start of PGP signed section.
* David Boreham ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
erm, I'm not really sure what you're saying here but perhaps I can
clarify: I wasn't suggesting to add any serious amount of source code
to PostgreSQL - NSS would be used
On Tue, Jan 02, 2007 at 01:29:35PM -0500, Stephen Frost wrote:
Would a patch to implement dual-support for OpenSSL and NSS be
acceptable? Would just replacing OpenSSL support with NSS support be
When I was looking into this I looked at NSS, and eventually decided on
GnuTLS. Why? Because I read
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Ah, this does sound rather ugly and not something we'd want. The
particular library doesn't make a whole heck of alot of difference to me
provided it has the general functionality necessary and a compatible
license (where
Bruce Momjian wrote:
Keep in mind in most cases OpenSSL is already part of the operating
system, unless you are using Win32.
My understanding is that the Debian people are saying the exception for
libraries shipped with the OS does NOT apply to *other* libraries or
programs that are
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
Bruce Momjian wrote:
Keep in mind in most cases OpenSSL is already part of the operating
system, unless you are using Win32.
My understanding is that the Debian people are saying the exception for
libraries shipped with the OS does NOT apply to
Casey Duncan [EMAIL PROTECTED] writes:
I guess the downside there is that it won't work on platforms that
don't support symlinks, whereas the postmaster switch would. Not that
I condone using such platforms ;^)
Well, we already bit that bullet with respect to tablespaces, and
haven't
Tom Lane wrote:
Casey Duncan [EMAIL PROTECTED] writes:
I guess the downside there is that it won't work on platforms that
don't support symlinks, whereas the postmaster switch would. Not that
I condone using such platforms ;^)
Well, we already bit that bullet with respect to
It seems to be about time to put out 8.2.1, since the flow of new bug
reports has ebbed. We're also overdue for updates of the back branches
--- for instance, we recently realized that the current 8.0.x and 8.1.x
releases don't know about the Canadian DST changes coming into effect in
March, and
Martijn van Oosterhout wrote:
- Thread safety (GnuTLS is thread-safe by design, no locks needed)
- Proper layering (creating your own I/O function is trivial)
- Seperate namespace
- Non-blocking support from the get-go
were taken care of. Since people are citing maintainability as a
concern, I
My program (indirectly) calls the following function twice,
tuple = SearchSysCache(STATRELATT, ObjectIdGetDatum(relid),
Int16GetDatum(colnum), 0, 0);
The first time it assigns NULL to tuple, while the second time it
assigns a valid pointer. Why is it like that? BTW, my program only
optimize
uwcssa [EMAIL PROTECTED] writes:
My program (indirectly) calls the following function twice,
tuple = SearchSysCache(STATRELATT, ObjectIdGetDatum(relid),
Int16GetDatum(colnum), 0, 0);
The first time it assigns NULL to tuple, while the second time it
assigns a valid pointer. Why is it like
On 12/30/06, Mark Cave-Ayland [EMAIL PROTECTED] wrote:
In short, if people don't mind waiting for my free cycles to come along
then I will continue to chip away at it; otherwise if it's considered an
essential for 8.3 with an April deadline then I will happily hand over
to Jonah.
I'd say it's
Bill Moran [EMAIL PROTECTED] writes:
In response to Alvaro Herrera [EMAIL PROTECTED]:
Please change things to save the stat() syscall when the feature is not
in use.
Do you have a suggestion on how to do that and still have the PG_TRACE1()
work? That was specifically requested by Simon
On Tue, Jan 02, 2007 at 09:48:22AM -0800, Jeff Davis wrote:
On Sat, 2006-12-30 at 13:35 -0600, Jim C. Nasby wrote:
My current implementation relies on the scans to stay close together
once they start close together. If one falls seriously behind, it will
fall outside of the main cache
* Shouldn't the xml type support binary I/O? Right now it is the only
standard datatype that doesn't. I have no idea whether there is an
appropriate representation besides text, but if not we could define the
binary representation to be the same as text.
There is an effort to develop a binary
Seems that the contrib regression tests, namely the cash and oid tests of
the btree_gist contrib module, are failing after the recent commit to
widen the money type to 64 bits. Example:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-01-03%2005:30:01
Also, on a slightly
On Tue, 2 Jan 2007, Jeremy Drake wrote:
Seems that the contrib regression tests, namely the cash and oid tests of
the btree_gist contrib module, are failing after the recent commit to
widen the money type to 64 bits. Example:
Jeremy Drake [EMAIL PROTECTED] writes:
Seems that the contrib regression tests, namely the cash and oid tests of
the btree_gist contrib module, are failing after the recent commit to
widen the money type to 64 bits.
Between D'Arcy and Bruce, there is not *any* buildfarm member passing
tonight,
58 matches
Mail list logo
