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
On Mon, Apr 13, 2009 at 12:59 PM, mito 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 mailing list (pgsql-hack
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 wrote:
It need to simulate unique constraint on field s_users.ne
On Mon, Apr 13, 2009 at 12:12 PM, mito 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,
> login
On Mon, Apr 13, 2009 at 11:12 AM, mito 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 Casanova
Soporte y c
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
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 f
On Mon, Dec 22, 2008 at 9:07 PM, 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 desig
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 a
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
> > sor
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.
W
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 lis
12 matches
Mail list logo
