On 8/29/11 5:50 PM, Tom Lane wrote:
> "Thorvald Natvig" writes:
>> We get a lot of "FATAL: canceling authentication due to timeout" in the
>> log, with accompanying closed connections to clients.
> Well, the only known cause of that (other than genuine timeout
> conditions) is in fact fixed in 9.
"Thorvald Natvig" writes:
> We get a lot of "FATAL: canceling authentication due to timeout" in the
> log, with accompanying closed connections to clients.
Well, the only known cause of that (other than genuine timeout
conditions) is in fact fixed in 9.1rc1. You have not provided any
informatio
"Steven Williams" writes:
> Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig
This file is not distributed by us. You probably need to contact the
SUSE packager of postgresql.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
On Mon, Aug 29, 2011 at 1:19 PM, Steven Williams wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6182
> Logged by: Steven Williams
> Email address: stwilli...@novell.com
> PostgreSQL version: 8.5.3
>
I'm guessing you mean 8.4.3?
> Operating system: S
The following bug has been logged online:
Bug reference: 6183
Logged by: Thorvald Natvig
Email address: thorv...@medallia.com
PostgreSQL version: 9.1rc1
Operating system: RHEL6
Description:FATAL: canceling authentication due to timeout
Details:
We get a lot of "FAT
The following bug has been logged online:
Bug reference: 6182
Logged by: Steven Williams
Email address: stwilli...@novell.com
PostgreSQL version: 8.5.3
Operating system: SuSE Linux 11
Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig
Details:
curren
On Mon, Aug 29, 2011 at 9:00 AM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> yeah, that's the correct way, but why does this work?
>> select val from random() as val;
>
> If you look at the PostgreSQL reference docs for the SELECT
> statement, a from_item can be a SELECT statement in paren
Alexey Klyukin writes:
> On Aug 29, 2011, at 5:47 PM, Tom Lane wrote:
>> There is a dump/reload bug though :-( ... if you were to do
>>
>> create view vv as select val from CAST(random() as integer) as val;
>>
>> you will find that the system prints it out with the :: syntax,
>> which won't wor
"Itagaki Takahiro" writes:
> For query concat_ws('/', NULL, 'X'),
> PostgreSQL 9.1 returns '/X', but MySQL returns 'X'.
> I think postgres should return 'X' because of compatibility.
> Another reason is that both of the two queries below return 'X'.
> - concat_ws('/', 'X', NULL)
> - array_to_str
On Aug 29, 2011, at 5:47 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Merlin Moncure wrote:
>>> yeah, that's the correct way, but why does this work?
>>> select val from random() as val;
>
>> If you look at the PostgreSQL reference docs for the SELECT
>> statement, a from_item can be a SE
"Kevin Grittner" writes:
> Merlin Moncure wrote:
>> yeah, that's the correct way, but why does this work?
>> select val from random() as val;
> If you look at the PostgreSQL reference docs for the SELECT
> statement, a from_item can be a SELECT statement in parentheses or a
> function call (amo
"Kevin Grittner" wrote:
> test=# select val from (select 'a' = 'a') as val;
> val
> -
> (t)
> (1 row)
Also note the difference between a record and a scalar here. I
forgot to write it to return val as a scalar, which seems to be what
you're after. It should have been:
test=# select v
Alexey Klyukin wrote:
> On Aug 29, 2011, at 5:02 PM, Kevin Grittner wrote:
>
>> Alexey Klyukin wrote:
>>
>>> Function calls can appear in the FROM clause. (This is
>>> especially useful for functions that return result sets, but any
>>> function can be used.) This acts as though its output were
On Aug 29, 2011, at 5:02 PM, Kevin Grittner wrote:
> Alexey Klyukin wrote:
>
>> Function calls can appear in the FROM clause. (This is especially
>> useful for functions that return result sets, but any function can
>> be used.) This acts as though its output were created as a
>> temporary tabl
Alexey Klyukin wrote:
> Function calls can appear in the FROM clause. (This is especially
> useful for functions that return result sets, but any function can
> be used.) This acts as though its output were created as a
> temporary table for the duration of this single SELECT command.
It doesn
Merlin Moncure wrote:
> yeah, that's the correct way, but why does this work?
> select val from random() as val;
If you look at the PostgreSQL reference docs for the SELECT
statement, a from_item can be a SELECT statement in parentheses or a
function call (among other things). It cannot be an
On Mon, Aug 29, 2011 at 7:49 AM, Kevin Grittner
wrote:
> Alexey Klyukin wrote:
>
>> The following statement produces an error message in PostgreSQL 8.4
>> - 9.2 (head):
>>
>> postgres=# select val from random()::integer as val;
>
>> The same statement rewritten with CAST AS works as expected:
>>
On Aug 29, 2011, at 3:49 PM, Kevin Grittner wrote:
> Alexey Klyukin wrote:
>
>> The following statement produces an error message in PostgreSQL 8.4
>> - 9.2 (head):
>>
>> postgres=# select val from random()::integer as val;
>
>> The same statement rewritten with CAST AS works as expected:
>>
Alexey Klyukin wrote:
> The following statement produces an error message in PostgreSQL 8.4
> - 9.2 (head):
>
> postgres=# select val from random()::integer as val;
> The same statement rewritten with CAST AS works as expected:
>
> postgres=# select val from CAST(random() as integer) as val;
The following bug has been logged online:
Bug reference: 6181
Logged by: Itagaki Takahiro
Email address: itagaki.takah...@gmail.com
PostgreSQL version: 9.1 RC1 (x86)
Operating system: Windows 7 (64bit)
Description:concat_ws() incompatibility with MySQL
Details:
For
Hello,
The following statement produces an error message in PostgreSQL 8.4 - 9.2
(head):
postgres=# select val from random()::integer as val;
ERROR: syntax error at or near "::"
LINE 1: select val from random()::integer as val;
The same statement rewritten with CAST AS works as expected:
21 matches
Mail list logo
