-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tom,
> "Martin Edlman" writes:
>> I encountered this problem during migration of the database from PgSQL 8.4
>> (where it works) to PgSQL 9.0.1.
>
> For me, this example fails on both 8.4 and 9.0. It works o
The following bug has been logged online:
Bug reference: 5770
Logged by: Martin Edlman
Email address: edl...@fortech.cz
PostgreSQL version: 9.0.1
Operating system: Scientific Linux 5.5 (RHEL)
Description:Foreign key violation after insert
Details:
Hello,
I have
The following bug has been logged online:
Bug reference: 5495
Logged by: Martin Edlman
Email address: edl...@fortech.cz
PostgreSQL version: 8.4.4
Operating system: Scientific Linux 5.5 (RHEL)
Description:RI/FK on self and inherited table
Details:
I have a table
ect result '2008-11-01'. But
xfunc() then fails and the trigger operation is rolled back and I see
the '2009-09-01' record again...
Sorry guys for bothering you and taking your time.
Regards,
- --
Martin Edlman
Fortech, spol. s r.o,
Ropkova 51, 57001 Litomyšl
Public GPG key: htt
The following bug has been logged online:
Bug reference: 5043
Logged by: Martin Edlman
Email address: edl...@fortech.cz
PostgreSQL version: 8.2.0
Operating system: Linux (RHEL 4.4)
Description:Stored procedure returning different results for same
arguments
Details
ol/mail/postgres
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
INPUTRC=/etc/inputrc PWD=/var/lib/pgsql LANG=cs_CZ.UTF-8 SHLVL=1
HOME=/var/lib/pgsql LOGNAME=postgres PGDATA=/var/lib/pgsql/data
Is it a bug in PostgreSQL or am I missing something?
--
Regards,
Martin Edlma
x27;ve correctly identified the problem.
> However, it seems possible that part of the issue is misbehavior if
> the various LC_xxx settings aren't all alike --- could you dig further
> and try to isolate it?
I set ALL LC_xxx variables to cs_CZ in postgres.conf but it didn't help.
Only
ues, other than expectable differences from C locale in sort
> ordering.
>
> regards, tom lane
>
--
Martin Edlman
Fortech s.r.o, Litomysl
Public PGP key: http://edas.visaci.cz/#keys
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Mon, 3 Nov 2003, Tom Lane wrote:
> Martin Edlman <[EMAIL PROTECTED]> writes:
> > [ unstable index behavior ]
>
> I'm wondering about hardware problems --- how sure are you that you
> don't have flaky RAM or a bad disk drive?
I'll check this, the RAID co
l);
CREATE UNIQUE INDEX qmail_account_email_idx ON qmail_account (username,domain);
CREATE TABLE qmail_dot (
id SERIAL,
username varchar(50),
domain varchar(100) not null REFERENCES zone (name) ON UPDATE
CASCADE,
extension varchar(64),
dotqmail tex
rying to reindex the index
> on zone(name).
I reindexed it several times. I didn't help.
Regards, Martin
- --
Martin Edlman
Fortech s.r.o, Litomysl
Public PGP key: http://edas.visaci.cz/#keys
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/WDSUoFlEKJy9loQRAsl/AJ4gYQ
27;', NEW.domain;
SELECT INTO rec3 NEW.home || ''/'' ||
btrim(NEW.domain,'' '')::varchar || ''/'' ||
NEW.username AS home;
NEW.home := rec3.home;
END IF;
key btree (id),
qmail_account_email_idx unique btree (username, "domain"),
qmail_account_contractid_idx btree (contractid),
qmail_account_username_idx btree (username)
Foreign Key constraints: $2 FOREIGN KEY ("domain") REFERENCES "zone"(name)
13 matches
Mail list logo
