Neil Conway <[EMAIL PROTECTED]> writes:
> client 1:
> CREATE TABLE a (b int);
> BEGIN;
> DROP TABLE a;
> -- wait
> client 2:
> SELECT * FROM a;
> client 1:
> COMMIT;
> Now, client 2 will receive "RelationClearRelation: relation 25172
> deleted while still in use", rather than "Relation "a" does not
> exist", as you might expect.
But relation "a" *does* exist at the start of client 2's operation.
While I'm not here to defend the exact phrasing of this error message,
it does seem to me that it's appropriate to give a different error
message than what appears when the table wasn't found at all.
An example of why the two cases shouldn't be folded together: suppose
that client 2's schema search path is "myschema, public", and that
client 1 creates/drops myschema.a while there is also a public.a.
client 2 will locate myschema.a as the meaning of "a", and one way or
another it is going to error out when myschema.a gets dropped from
underneath it --- it will not (and shouldn't IMHO) go back and repeat
the schema search to find public.a. But a user who gets a "Relation "a"
does not exist" error message in such a scenario would be justifiably
confused.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
