Re: Query on exception handling in PL/pgSQL

Поиск
Список
Период
Сортировка
От Victor Ciurus
Тема Re: Query on exception handling in PL/pgSQL
Дата
Msg-id e7a72f40041127013739313c0@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query on exception handling in PL/pgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Query on exception handling in PL/pgSQL  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: Query on exception handling in PL/pgSQL  (Johan Wehtje <joweht@tpgi.com.au>)
Список pgsql-general
And how does exactly PG8.0 help us with this?

Tom, coould you be so kind and tell me/us when will PG incorporate
such a hugely claimed feature like "copy table_x from 'file_y.txt'
(using delimiters) IGNORE ON DUPLICATES"?

I do LOVE PG and I'm very pleased with its overall features level
still the lack of "ingore" on unique key constraint insert (especially
for large bulk inserts!) makes me feel quite helpless!

Or, is there another way, like in Oracle's exception handling, to
hanle this thing (COPY/INSERTs with Ignore?) I can't emagine how such
a 'simple' (no offense!) db like MySQL can hanlde INSERT IGONERS (not
to mention the 'so serious' ORACLE, INFORMIX , MSSQL and prolly DB2)
and PG not beeing able to do this!

Please enlighten me! I saw a huge deabte over this feature, dated
2001-2002, ended up on a 'promise' that such feature will be made
available staring with PG 7.1 or 7.2 (can't remeber exactly!) still no
sign of improvement on it!

Best regards,
Victor


On Fri, 26 Nov 2004 14:06:52 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> diya das <diyadas@yahoo.com> writes:
>
>
> > My pgsql function
> > does an insert to a table and I have opened a
> > transaction block before calling my function from the
> > client. When the insert operation fails due to unique
> > key violation the whole transaction aborts. Is there a
> > way I can handle this error in my pgsql funtion rather
> > that aborting and not executing the rest of the
> > operations?
>
> Not before PG 8.0.  In earlier versions you might be able to work around
> the problem by testing for existence of the target key before you
> insert; though this has obvious race-condition problems if you expect
> multiple clients to be doing it simultaneously.
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

В списке pgsql-general по дате отправления:

Предыдущее
От: Richard Welty
Дата:
Сообщение: Re: Front Ends
Следующее
От: Konstantin Danilov
Дата:
Сообщение: how many JOINs?