By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,393 Members | 1,405 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,393 IT Pros & Developers. It's quick & easy.

statement level triggers in PostgreSQL , anybody??

P: n/a
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 ??
Nov 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
--
Martijn van Oosterhout <kl*****@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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAu607Y5Twig3Ge+YRAhSxAKDXI5ylUydrqiQztkzocc Jxx8G3gACbB/DG
t+PnAejlvOsGXxxLdwz5Twc=
=QSvw
-----END PGP SIGNATURE-----

Nov 23 '05 #2

P: n/a
> 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.
Nov 23 '05 #3

P: n/a
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 <kl*****@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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAw44rY5Twig3Ge+YRAvhaAJsE1DpGWt/1zhdZUtlphx5BaNCZmgCeIDkL
POHV/pBCphjD4oqC1YjhHF4=
=QvH3
-----END PGP SIGNATURE-----

Nov 23 '05 #4

P: n/a
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 <kl*****@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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAw44rY5Twig3Ge+YRAvhaAJsE1DpGWt/1zhdZUtlphx5BaNCZmgCeIDkL
POHV/pBCphjD4oqC1YjhHF4=
=QvH3
-----END PGP SIGNATURE-----

Nov 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.