Обсуждение: statement level triggers in PostgreSQL , anybody??

Hi,
     I am a bit troubled with the row-level triggers which PostgreSQL
uses when using update table cpmmand.
     For instance, if the primary key column has values 1,2,3,... and
i want to update the whole column as column = colunm + 1 , then there
is an error. This obviously works on databases such as mssql which has
row level triggers.
     Any suggestions so that i do not have to modify the query and
still make it work in the postgresql database ??

This has nothing to do with triggers, it has to do with not being able
to defer UNIQUE constraints. The classic solution is:

update SET column = -column;
update SET column = -column+1;

The problem is that you're trying to update the primary key, which is a
bad idea is most situations.

On Thu, May 27, 2004 at 06:28:08AM -0700, rama wrote:
> Hi,
>      I am a bit troubled with the row-level triggers which PostgreSQL
> uses when using update table cpmmand.
>      For instance, if the primary key column has values 1,2,3,... and
> i want to update the whole column as column = colunm + 1 , then there
> is an error. This obviously works on databases such as mssql which has
> row level triggers.
>      Any suggestions so that i do not have to modify the query and
> still make it work in the postgresql database ??
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

> This has nothing to do with triggers, it has to do with not being able
> to defer UNIQUE constraints. The classic solution is:
>
> update SET column = -column;
> update SET column = -column+1;

Thanks for the reply.

Is changing query the only way to do this in postgres?

I would expect some more. IMHO, Postgres should first update all the
values and then check for duplicacy (and not check for duplicacy while
the query is still executing) - kind of saying that it should fire
statement level trigger instead of row level trigger. Most other
databases (Oracle/DB2 etc) behave this way.

The problem is that changing the query may not *always* work. E.g. If
the values in the primary key in the tables are consecutive, not in
any order, and contains negative numbers as well, it will be hard to
come up with a query that would do the needful. Say the table is (col1
is the primary key).

 col1 | col2
------+------
   -2 |  100
   -1 |  100
    0 |  100
    1 |  100
    2 |  100

On this, queries "update temp set col1=col1+1" as well as "update temp
set col1=col1-1" would fail with duplicate key error. Moreover, if the
query is autogenerated, where manual intervention is not possible, it
would be even harder.

So, a robust (and clean) way would be to have postgres support such
statements which would be to say that postgres check for duplicacy at
the end of the statement execution and not in between.

Now, what I want to know is, is there any way to make postgres show
such behaviour using some user level trigger (or any other mechanism)
or this is something which would require changing the postgres code
itself (we are willing to do that as well, but may not be worth the
effort if is somehow possible in the current framework).

Thanks.

It's true, PostgreSQL can only check a unique contraint at the time the
row is inserted and can't defer it to the end of the statement due to
the way they are implemented (using the indexes). Sure, there has been
talk about it but I don't think anyone has done it yet.

The thing is that for the vast majority of applications the primary key
is an opaque handle with no intrinsic meaning so it never needs to be
updated hence the issue never comes up. So I'm afraid that the demand
just isn't that high.

If you want to post a patch though, it'd probably be accepted.

Hope this helps,

On Thu, Jun 03, 2004 at 06:13:17AM -0700, Vikas Rana wrote:
> > This has nothing to do with triggers, it has to do with not being able
> > to defer UNIQUE constraints. The classic solution is:
> >
> > update SET column = -column;
> > update SET column = -column+1;
>
> Thanks for the reply.
>
> Is changing query the only way to do this in postgres?
>
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.