Craig Ringer writes:
> On 09/17/2011 05:10 AM, Carlo Curatolo wrote:
>> Just tried with PG 9.1...same problem...
> Yep. There appears to be no interest in fixing this bug. All the
> alternatives I proposed were rejected, and there doesn't seem to be any
> concern about the issue.
The problem i
On 09/17/2011 05:10 AM, Carlo Curatolo wrote:
Just tried with PG 9.1...same problem...
Yep. There appears to be no interest in fixing this bug. All the
alternatives I proposed were rejected, and there doesn't seem to be any
concern about the issue. I'd be willing to have a go at the issue if
t
Just tried with PG 9.1 64bits...same problem...
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-5800-corrupted-error-messages-encoding-problem-tp3313951p4812066.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
Sent via pgsql-bugs mailing l
Just tried with PG 9.1...same problem...
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-5800-corrupted-error-messages-encoding-problem-tp3313951p4812062.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
Sent via pgsql-bugs mailing list (pg
writes:
> On Sep 16, 2011, at 11:11 AM, Tom Lane wrote:
>> Hmm. It would require an extra catalog lookup per parameter to enforce
>> that. Not sure that it's worth it just to prevent "peculiar" errors.
>> Can you point to any worse consequences?
> I haven't found any more severe issues and I'll
On Sep 16, 2011, at 11:11 AM, Tom Lane wrote:
> "Caleb Welton" writes:
>> statements such as:
>> PREPARE p1(anyelement) AS SELECT quote_literal($1);
>> PREPARE p2(internal) AS SELECT int2recv($1);
>> Should not be allowed.
>
> Hmm. It would require an extra catalog lookup per parameter to en
"Caleb Welton" writes:
> statements such as:
> PREPARE p1(anyelement) AS SELECT quote_literal($1);
> PREPARE p2(internal) AS SELECT int2recv($1);
> Should not be allowed.
Hmm. It would require an extra catalog lookup per parameter to enforce
that. Not sure that it's worth it just to prevent
The following bug has been logged online:
Bug reference: 6212
Logged by: Caleb Welton
Email address: caleb.wel...@emc.com
PostgreSQL version: 9.0
Operating system: OSX
Description:PREPARE(pseudotype) should be blocked off
Details:
statements such as:
PREPARE p1(an
The following bug has been logged online:
Bug reference: 6210
Logged by: Norman Palardy
Email address: npala...@great-white-software.com
PostgreSQL version: 9
Operating system: OS X
Description:Description of PQconnectdbParams in documentation
Details:
Description o
On 16-09-2011 01:57, pratikchirania wrote:
Time is being interpreted incorrectly when I set time zone to UTC -6
(Central America).
Time shown when I query "SELECT NOW()" is 1 hour ahead of system time.
PS: Central america does not have daylight saving. That might not be the
issue.
It is not a bu
The following bug has been logged online:
Bug reference: 6208
Logged by: Richard G. Bayer
Email address: ba...@nws.cz
PostgreSQL version: 8.4.7
Operating system: Windiws XP 32-bit
Description:crash when c: occupied by removable drive
Details:
After hours of debuggin
Hi,
I am experiencing the following anomaly while using postgres database:
Time is being interpreted incorrectly when I set time zone to UTC -6
(Central America).
Time shown when I query "SELECT NOW()" is 1 hour ahead of system time.
PS: Central america does not have daylight saving. That might no
On 16.09.2011 12:59, Marc Mamin wrote:
This is not valid, but is accepted.
EXPLAIN analyze
select * from test_f_files_steps where id in
(select id from
(
select file_id,class_id from test_f_files_steps
EXCEPT
select id,class_id from test_f_files_status
)foo
)
It is
The following bug has been logged online:
Bug reference: 6209
Logged by: Marc Mamin
Email address: m...@intershop.de
PostgreSQL version: 9.1beta3
Operating system: Linux
Description:Invalid subquery is accepted within a IN() clause
Details:
Hello,
This is somehow s
14 matches
Mail list logo
