Affected # of Rows After TRIGGER/RULE Return

Поиск
Список
Период
Сортировка
От Volkan YAZICI
Тема Affected # of Rows After TRIGGER/RULE Return
Дата
Msg-id 87skwm9rn4.fsf@alamut.mobiliz.com.tr
обсуждение исходный текст
Ответы Re: Affected # of Rows After TRIGGER/RULE Return
Список pgsql-general
Hi,

I'm trying to fake DELETEs to a table using below methods:

  CREATE OR REPLACE FUNCTION mobileunit_fake_delete() RETURNS trigger AS $$
  BEGIN
      UPDATE mobileunit
         SET networkid = OLD.networkid + OLD.muid * 100000000000,
             groupid = 146688,
             plate = 'DELETED_' || OLD.plate
       WHERE muid = OLD.muid;

      RETURN NULL;
  END;
  $$ LANGUAGE plpgsql;

  CREATE TRIGGER mobileunit_fake_delete
      BEFORE DELETE ON mobileunit
      FOR EACH ROW EXECUTE PROCEDURE mobileunit_fake_delete();

or

  CREATE RULE mobileunit_fake_delete
  AS ON DELETE TO mobileunit
  DO INSTEAD
  UPDATE mobileunit
     SET networkid = CAST(OLD.networkid AS numeric(20)) + OLD.muid * 100000000000,
         groupid = 146688,
         plate = 'DELETED_' || OLD.plate
   WHERE muid = OLD.muid;

But unfortunately, both solutions make

  DELETE FROM mobileunit WHERE muid = ...

queries return 0 as # of affacted rows. And this causes JDBC
applications (specifically Hibernate) ROLLBACK query as some failure
occured. At least, shouldn't the latter one return 1 as # of affected
rows? Any ideas to fix this problem?


Regards.

P.S. Yep, I know code sucks badly. Trying to migrate a Microsoft SQL
     Server application to PostgreSQL.

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

Предыдущее
От: Vivek Khera
Дата:
Сообщение: Re: Stripping out slony after / before / during pg_restore?
Следующее
От: David Fetter
Дата:
Сообщение: Re: Making sure \timing is on