"Jim Dew" <[EMAIL PROTECTED]> writes:
> Stumbled upon a (broken) query that causes the 8.1.0 thread handling the
> query to die:
> select foo from (select null) as foo
Confirmed here --- will look into it. Thanks for the report!
> Now, this query just produces an error on 8.0.3
However, there's
"Neil Parker" <[EMAIL PROTECTED]> writes:
> This problem appears to be glibc's fault, not PostgreSQL's.
Indeed, so why are you complaining to us?
> Below is a patch that fixes the problem on the affected system.
I'm fairly unenthused about a kluge that hurts performance on
standard-conforming sy
On Mon, Dec 12, 2005 at 01:38:37PM +, Micha Szelg wrote:
> Description:NULL=NULL is false
No, the result is NULL, not false. See "Comparison Operators" in
the documentation:
http://www.postgresql.org/docs/7.4/interactive/functions-comparison.html
"Do not write expression = NULL beca
The following bug has been logged online:
Bug reference: 2109
Logged by: MichaÅ SzelÄ
g
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux / debian sarge
Description:NULL=NULL is false
Details:
select case when NULL=NULL then true else
Alvaro Herrera wrote:
> Stallone wrote:
>
> Please keep replies on the list.
>
>
>>What you have done is run a SELECT which evaluates the function
>>f_multiparam() passing it two parameters, and then takes the result and
>>puts it INTO a local parameter. This is not the same. An OUT parameter
Tom Lane wrote:
> "Tony S" <[EMAIL PROTECTED]> writes:
>
>>Function defined with INOUT parameter. Value of parameter is not returned
>>to calling function.
>
>
> You are confused about the meaning and use of INOUT. It's not some kind
> of pass-by-reference parameter, it's just a shorthand for
The following bug has been logged online:
Bug reference: 2112
Logged by: Jim Dew
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0
Operating system: OpenBSD
Description:query kills db thread
Details:
Stumbled upon a (broken) query that causes the 8.1.0 thre
Thank you for your attention,
For your convenience, I send you two charts describing
the two (almost similar) encodings in order to use them
when someone works on this bug.
http://www.fileformat.info/info/charset/windows-1253/grid.htm
http://www.fileformat.info/info/charset/ISO-8859-7/grid.htm
The following bug has been logged online:
Bug reference: 2111
Logged by: Neil Parker
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Linux (Slackware 8.0, with kernel 2.2.19, glibc 2.2.3)
Description:Error parsing 'infinity' under some ver
The following bug has been logged online:
Bug reference: 2110
Logged by: Alexei
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Window XP SP2
Description:initdb set wrong default encoding
Details:
Good day!
I run initdb with --encoding=W
"Harry Rossignol" <[EMAIL PROTECTED]> writes:
> This statement via SQLexec executes in the blink of an eye
> DECLARE XNKPE BINARY CURSOR for SELECT wtsnzblob FROM "NZRECS" WHERE
> wtsevent = '05002' AND wtspaymeth = '$' AND wtspayno = '' AND ( wtstrxtm
>> '19691231 16' OR (wtstrxtm = '19691231
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Is COPY foo TO STDOUT BINARY supposed to work?
I don't think psql will do anything particularly sane with binary copy
data, if that's what you meant.
echo "COPY foo TO STDOUT BINARY;" | psql >bar
writes a 0 bytes file; not surprise
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Is COPY foo TO STDOUT BINARY supposed to work?
I don't think psql will do anything particularly sane with binary copy
data, if that's what you meant.
regards, tom lane
---(end of broadcast)---
Is COPY foo TO STDOUT BINARY supposed to work? The query will run some
time, but won't give a result.
I couldn't see any mentioning in the COPY command docs that would
prohibit use of this combination.
Tested with psql on 8.0.5 and 8.1.1.
Regards,
Andreas
---(end of
14 matches
Mail list logo
