Re: Problems with unique restrictions

From: "Shoaib Mir" <shoaibmir(at)gmail(dot)com>
To: "Marcel Gsteiger" <Marcel(dot)Gsteiger(at)milprog(dot)ch>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-general(at)postgresql(dot)org
Subject: Re: Problems with unique restrictions
Date: 2007-01-14 12:14:05
Message-ID: bf54be870701140414o62b85920t3442d5b33a62ad04@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

You can give EnterpriseDB PL Debugger a try, details for its usage can be
found at --> http://www.enterprisedb.com/documentation/debugger.html

--------------
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 1/14/07, Marcel Gsteiger <Marcel(dot)Gsteiger(at)milprog(dot)ch> wrote:
>
> thanks for responding. Meanwhile I found out that ist was my own fault. A
> newly installed insert trigger fired unexpectedly and caused the error. Now
> I'm redesigning my functions to make them smaller so that errors can be
> found easier. Sometimes I wish there was something like a debugger for
> PL/PGSQL with breakpoints, single step, variable watching...
> Anyway, PostgreSQL is the best backend I ever have worked with.
>
> Regards
> --Marcel
> >>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 13.01.2007 >>>
> "Marcel Gsteiger" <Marcel(dot)Gsteiger(at)milprog(dot)ch> writes:
> > Now since I upgraded to 8.2 I have problems inserting data into tables
> that have unique indexes. Ugly enough, I get the message 'duplicate key
> violates unique constraint' when inserting the very first record into a
> table. This happens everytime when the new tuple references another tuple
> that has been inserted just before this one in the same transaction.
>
> > Putting a "SET CONSTRAINTS ALL DEFERRED" in my procedure does not help.
>
> > To me it looks that something with referential integrity checking goes
> wrong, but in this case the error message would be misleading.
>
> RI would not have anything to do with a duplicate-key error.
>
> Do you have any SERIAL-type columns in these tables? My first thought
> is of a sequence that hasn't been updated to be above the existing ID
> values. It's fairly easy to get into such a state if you do anything
> but a plain vanilla dump-all-and-reload-all update process ...
>
> regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message korryd 2007-01-14 14:29:49 Re: Antw: Re: Problems with unique restrictions
Previous Message Marcel Gsteiger 2007-01-14 12:04:14 Antw: Re: Problems with unique restrictions