Since column is boolean, you need a boolean result:
insert into table (column) values (nullif(true,true));
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt A.
> Sent: Monday, August 22, 2005 3:22 AM
> To: pgsql-bugs@postgresql.org; pgsql-patch
On 2005-08-26 16:17, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Steve Wormley" <[EMAIL PROTECTED]> writes:
>> Did a dump and restore of my DB to 8.1beta1 (running concurrently with
>> 8.0.3) and performance on the same query is about 50% slower with the beta.
>> Ran query twice on each instance in
"Steve Wormley" <[EMAIL PROTECTED]> writes:
> Did a dump and restore of my DB to 8.1beta1 (running concurrently with
> 8.0.3) and performance on the same query is about 50% slower with the beta.
> Ran query twice on each instance in sequence to make sure all data was in OS
> cache.
Did you vacuum
I just installed postgres from the postgresql-8.0.3.zip file, and I'm
running
XPpro. The installation seemed to go ok but when I try to login as postgres
it tells me...
psql -Upostgres -W
(I enter my password)
psql server closed the connection unexpectedly
this probably means the server termin
Kevin Grittner wrote:
> I'm afraid I'm not familiar with a good way to capture the stream of
> communications with the database server. If you could point me in the right
> direction, I'll give it my best shot.
tcpdump will do the trick (something like 'tcpdump -n -w
some.output.file -s 1514 -
The following bug has been logged online:
Bug reference: 1851
Logged by: Steve Wormley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1beta1
Operating system: RedHat Linux, Kernel: 2.6.12.2
Description:Performance reduction from 8.0.3
Details:
Did a dump and
The following bug has been logged online:
Bug reference: 1850
Logged by: Danilo Barbosa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: LINUX
Description:parameter WITH HOLD (of function DECLARE CURSOR) not
acepted inside CREATE FUNCTION.
De
Unfortunately, the original test environment has been blown away in favor of
testing the 8.1 beta release. I can confirm that the problem exists on a build
of the 8.1 beta. If it would be helpful I could set it up again on 8.0.3 to
confirm. I THINK it was actually the tip of the 8.0 stable br
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> What happens if the timestamp of the commit is an exact match for the
> timestamp of the next transaction start? What is the resolution of
> the time sampling?
It's not done via timestamps: rather, each transaction takes a census
of the transaction X
I am absolutely sure that the database transaction is always terminated by
invoking commit or rollback, and waiting for the method to come back, before
the middle tier returns control to the client.
A couple other potentially relevant facts are that these connections are doing
all this work in
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> The problem is this: a single thread is submitting database updates through
> a middle tier which has a pool of connections. There are no guarantees of
> which connection will be used for any request. Each request is commited as
> its own databas
I have an odd one here. I was unable to find it with a search of the mailing
lists. I've spent a few hours trying to create a simple test case, but so far
these simple cases aren't showing the problem. I want to make sure this isn't
a know problem before investing more time trying to come up
The following bug has been logged online:
Bug reference: 1849
Logged by: Bernard Henry Voynet
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Windows XP
Description:Is PgOleDb still alive ?
Details:
Since this project has no new release
Matthew Manuel wrote:
Hello, I found a strange error which occurs when I run a query from
PHP4, where if there is a column which has strings arbitrarily defined
text for all rows of a sub-select, and you attempt to sort by that
column, it cannot determine the type for that column in order to do
14 matches
Mail list logo
