Re: Duplicate key value error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Duplicate key value error
Date: 2009-08-01 20:01:42
Message-ID: 27436.1249156902@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Thank you for reviewing. An updated patch is attached.

I applied this with some revisions.

I didn't like the fact that error reports for functional indexes came out
with "pg_expression_n" instead of something useful. I tweaked things to
use the pg_get_indexdef code to obtain proper descriptions of the columns.
(This also resulted in deciding to make the separator ", " instead of just
",", because that's what pg_get_indexdef does.)

The API for the reporting function wasn't going to work at all for
non-btree indexes, because they don't necessarily have index tuples
that contain exactly the values to be reported. (In particular, hash
doesn't.) I refactored things a bit to pass Datum/isnull arrays instead
of an IndexTuple. This also led to moving the reporting function to
genam.c, because it no longer had anything to do with IndexTuples.

We're still not there for being able to support unique hash indexes with
this, because it's still supposing that the index's tupledescriptor tells
the input column datatypes. However that's an internal matter now for the
reporting function, instead of being baked into its API. (I actually
don't see a very easy way to get the column datatypes --- we'll need to
think about that some, when and if unique hash indexes ever happen.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-01 20:05:17 Re: PostgreSQL 8.4.1 ?
Previous Message Stephen Frost 2009-08-01 19:03:54 PostgreSQL 8.4.1 ?