Re: Getting rows in statement-level triggers
От | Gurjeet Singh |
---|---|
Тема | Re: Getting rows in statement-level triggers |
Дата | |
Msg-id | 65937bea0810022357g5e585f70p3ca07d06af2f93c0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Getting rows in statement-level triggers (Artacus <artacus@comcast.net>) |
Список | pgsql-general |
On Fri, Oct 3, 2008 at 11:42 AM, Artacus <artacus@comcast.net> wrote:
That's an interesting find, i'd say.
xmin::bigint doesn't work because that implicit CAST doesn't exist. If needed, I'd use xmin::text::bigint; that should work.
Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
Ok, so it took a lot of googling to figure this one out, but you can do it with something like so.So the manual says there is no way for a statement-level trigger to examine the row(s) modified by the statement.
Is there any way to get the xmin or cmin of the transaction that fired the trigger? Or can I look up the last xid for a table some where?
SELECT *
FROM strand_scores
WHERE xmin::text = txid_current()::text
It appears you can't convert a xid type to int or bigint, not sure why. I guess I should leave a comment on the manual page.
That's an interesting find, i'd say.
xmin::bigint doesn't work because that implicit CAST doesn't exist. If needed, I'd use xmin::text::bigint; that should work.
Best regards,
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
В списке pgsql-general по дате отправления: