Hi,
is there any way how to count affected rows by on update rule and use it
as part of condtions.
Example:
CREATE OR REPLACE RULE _UPDATE AS ON UPDATE TO users DO INSTEAD (
UPDATE s_users SET
id = new.id,
login = new.login,
WHERE id IN (SELECT id FROM s_users ) AND 2
On Mon, Apr 13, 2009 at 11:12 AM, mito milos.ors...@gmail.com wrote:
It need to simulate unique constraint on field s_users.new_id, so it should
deny to update multiple rows with same value.
Any suggestions are welcome.
why not simply create a UNIQUE constraint?
--
Atentamente,
Jaime
On Mon, Apr 13, 2009 at 12:12 PM, mito milos.ors...@gmail.com wrote:
Hi,
is there any way how to count affected rows by on update rule and use it as
part of condtions.
Example:
CREATE OR REPLACE RULE _UPDATE AS ON UPDATE TO users DO INSTEAD (
UPDATE s_users SET
id = new.id,
I am using rules as layer to save every version of row in shadow table,
so i cant use unique constraint on column, because of many versions may
have same value.
mito
Jaime Casanova wrote:
On Mon, Apr 13, 2009 at 11:12 AM, mito milos.ors...@gmail.com wrote:
It need to simulate unique
On Mon, Apr 13, 2009 at 12:59 PM, mito milos.ors...@gmail.com wrote:
I am using rules as layer to save every version of row in shadow table, so i
cant use unique constraint on column, because of many versions may have same
value.
Use a partial index.
...Robert
--
Sent via pgsql-hackers
This will deny insert of value that allready exists. Which is ok. But
the second scenerio in which unique constraint refuse operation is, when
u try to update more rows to same value in column with unique constraint.
So i need to use count of affected rows, to deny operation if there are
more
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
Would
On Mon, 2008-12-22 at 15:07 -0500, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a
On 2008-12-22, at 21:07, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw
On Mon, Dec 22, 2008 at 9:07 PM, Bruce Momjian br...@momjian.us wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a
On 2008-12-22, at 22:35, Dawid Kuroczko wrote:
atlantis= CREATE OR REPLACE FUNCTION foo_trigger() RETURNS trigger AS
$$ BEGIN UPDATE bar SET t=NEW.t WHERE i=NEW.i; RETURN NULL; END; $$
LANGUAGE plpgsql;
atlantis= CREATE TRIGGER foo_update BEFORE UPDATE ON foo FOR EACH ROW
EXECUTE PROCEDURE
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
--
Sent via pgsql-hackers mailing
12 matches
Mail list logo
