ommit;
exec sql disconnect;
return 0;
}
-8<8<8<8<8<8<8<---
>From - Thu Feb 12 21:09:07 2009 X-Mozilla-Status:
X-Mozilla-Status2: X-Mozilla-Keys: FCC:
imap://dav...@davidnewall.com/INBOX/Se
Heikki Linnakangas wrote:
> ecpg implicitly runs everything inside transactions. You don't need to
> run START TRANSACTION, that's implicit. Therefore the "set
> search_path" command is in fact run in the same transaction as the
> failing insert, as also hinted by the warning "there is already a
>
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
GIVEN
CREATE TABLE data (i integer);
AND
SELECT count(*), min(i), max(i) FROM data;
count | min | max
---+-+-
1340 | 3 | 20
(1 row)
(Actual data attached as data.dmp)
NOW CONSIDER
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
CREATE TABLE t1 (i INTEGER, j INTEGER);
INSERT INTO t1 VALUES (1, NULL);
CREATE TABLE t2 AS SELECT * FROM t1;
SELECT * FROM t1 JOIN t2 USING (i, j);
i | j
---+---
(0 rows)
I believe the one row, which is
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
CREATE TABLE t(i integer UNIQUE);
INSERT INTO t VALUES (null);
INSERT INTO t VALUES (null);
SELECT coalesce(i,-999) FROM t;
coalesce
--
-999
-999
(2 rows)
---(
On Sat, 2004-07-17 at 13:34, Tom Lane wrote:
> I suspect the real issue is that the implied join order is not the same.
With respect, the real issue is that using the view takes 100 times
longer than not using it.
> The view-based query is really
>
> a LEFT JOIN (b LEFT JOIN c LEFT JOIN d
On Sat, 2004-07-17 at 14:30, Tom Lane wrote:
> David Newall <[EMAIL PROTECTED]> writes:
> > select * from a join b optimises differently to select * from a join
> > (select * from b) as b
>
> The above claim is provably false. Now, if you throw in some more
> tabl
Hi all,
Trivial program to demonstrate problem:
main() {
ECPGdebug(1,stderr);
exec sql connect to postgres;
exec sql set autocommit to off;
exec sql start transaction;
exec sql savepoint s;
exec sql rollback to s;
exec sql commit;
return 0;
}
Output:
[28397]: E
On 14/10/10 12:14, Itagaki Takahiro wrote:
Which solution is better? Or, another idea?
This does seem to be an new bug in previously working code. While any
solution that fixes the problem is good, it might pay to look the code
that worked before. As reported, it worked for ecpg (Postgr
ress
Date: Thu, 14 Oct 2010 10:44:50 +0900
From: Itagaki Takahiro
To: David Newall, PostgreSQL Hackers
CC: pgsql-bugs@postgresql.org
On Mon, Oct 11, 2010 at 7:42 AM, David Newall
wrote:
Trivial program to demonstrate problem:
main() {
ECPGdebug(1,stderr);
exec sql
10 matches
Mail list logo
