Added to TODO:
* Increase locking when DROPing objects so dependent objects cannot
get dropped while the DROP operation is happening
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
---
Tom Lane
Uh, where are we on this?
---
Tom Lane wrote:
I wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, where are we on this?
Still in the think-about-it mode, personally ... my proposed fix is
certainly much too invasive to consider back-patching, so unless someone
comes up with a way-simpler idea, it's 8.3 material at best ...
I wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php
Ugh ... I haven't traced this through in detail, but I'm pretty sure
the problem
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
CREATE TABLE foo (id integer);
CREATE FUNCTION foofunc() RETURNS trigger AS $$
BEGIN
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Then in concurrent sessions:
A: BEGIN;
A: CREATE TRIGGER footrig
Michael Fuhr [EMAIL PROTECTED] writes:
I've found a situation that causes DROP FUNCTION to fail (tested
in 8.1.6, 8.2.1, and 8.3devel):
Ugh ... I haven't traced this through in detail, but I'm pretty sure
the problem arises from the fact that dependency.c traces through
auto/internal
