| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kris Kiger <kris(at)musicrebellion(dot)com> |
| Cc: | "Pgsql-Admin (E-mail)" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Functions and transactions |
| Date: | 2005-03-11 18:54:33 |
| Message-ID: | 4363.1110567273@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers pgsql-patches |
Kris Kiger <kris(at)musicrebellion(dot)com> writes:
> Interesting. That makes sense, though. So, is there a good way to lock
> a set of rows using SELECT FOR UPDATE in plpgsql? I assume using
> PERFORM would yield the same problem, because it immediately discards
> the results.
I think PERFORM would work. The fact that plpgsql ignores the results
doesn't mean you don't have lock on the rows.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dick Davies | 2005-03-11 20:08:12 | Re: [HACKERS] PostgreSQL pam ldap document |
| Previous Message | Adrian Nida | 2005-03-11 18:00:06 | Re: [HACKERS] PostgreSQL pam ldap document |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kurt Roeckx | 2005-03-11 19:28:04 | Re: Bumping libpq version number? |
| Previous Message | Evgen Potemkin | 2005-03-11 18:46:01 | Re: SQL99 Hierarchical queries |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-03-11 19:14:22 | Add fprintf macro |
| Previous Message | Bruce Momjian | 2005-03-11 17:44:19 | Re: [pgsql-hackers-win32] snprintf causes regression |