This used to work in the PostgreSQL 8.4 ecpg preprocessor:
EXEC SQL EXECUTE mystmt USING 1.23;
but in 9.0 it throws an error:
floattest.pgc:39: ERROR: variable "1" is not declared
Attached is the full test case, drop it in
src/interfaces/ecpg/test/preproc and compile.
I bisected the cause t
On 01.11.2010 15:31, Heikki Linnakangas wrote:
This used to work in the PostgreSQL 8.4 ecpg preprocessor:
EXEC SQL EXECUTE mystmt USING 1.23;
but in 9.0 it throws an error:
floattest.pgc:39: ERROR: variable "1" is not declared
Attached is the full test case, drop it in
src/interfaces/ecpg/tes
The following bug has been logged online:
Bug reference: 5738
Logged by: spche
Email address: sp...@163.com
PostgreSQL version: 9.01
Operating system: Winxp
Description:btree index search bug
Details:
create table a (a int);
create index a_a on a(a);
insert into a
"spche" writes:
> Description:btree index search bug
I see no bug here. The cursor is opened at a time when there is one
row with a=3, so it can find only that one row because of its snapshot.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
Checkout from HEAD this morning, no modifications. Did make
distclean and fresh build to ensure no problems caused by mixed
build. 32 bit kubuntu on single drive dual core workstation. Fresh
initdb. Default configuration.
postgres=# create database bug;
CREATE DATABASE
postgres=# \c bug
You ar
The following bug has been logged online:
Bug reference: 5739
Logged by: Kim Garren
Email address: deda...@bjoernvold.com
PostgreSQL version: 9.0.1-2
Operating system: Arch Linux
Description:postgresql will not start
Details:
Received update to postgresql 9.0.1-2 ye
"Kim Garren" wrote:
> Received update to postgresql 9.0.1-2 yesterday
How? From where? What were you running before?
> Once booted, I try to start it manually, with the following
> result:
>
> # /etc/rc.d/postgresql start
> :: Starting PostgreSQL
> [BUSY] server starting
>
> [DONE]
Wha
"Kevin Grittner" writes:
> create index t_sname on t (sname(t));
Huh, interesting. The reason the DROP misbehaves is that the index
doesn't have any dependency at all on table "t". Which appears to
be exposing the folly of this bit in find_expr_references_walker:
/*
* A whole-
I wrote:
> "Kevin Grittner" writes:
>> create index t_sname on t (sname(t));
> Huh, interesting. The reason the DROP misbehaves is that the index
> doesn't have any dependency at all on table "t". Which appears to
> be exposing the folly of this bit in find_expr_references_walker:
> /*
