Joachim Wieland <joe@mcknight.de> writes:
> On Thu, Feb 02, 2006 at 12:34:28PM -0300, Alvaro Herrera wrote:
>> That's the wrong way to go about it -- better refactor the code so that
>> a function gets a list of Oids instead of RangeVars, and truncates them.
>> ExecuteTruncate should build the list and pass it down.
> Ok. But are RangeVars deprecated in general?
No, but they're a parse-time representation. Once you've resolved a
relation down to its OID, you should stick with the OID. In this
particular case, you would for instance be exposing yourself to needless
race conditions against ALTER TABLE RENAME if you generate a RangeVar
from the OID and then pass that to somewhere to be looked up.
>> Also I think all the involved relations should be opened and locked
>> before any of them is touched (so maybe instead of passing Oids you
>> should be passing Relations).
> There is already the possibility to do "TRUNCATE t1, t2, t3". The patch just
> adds all referencing relations as if the user had specified all of them and
> then starts truncating the same way it is doing it right now. If all
> relations have to be opened and locked before truncating multiple relations,
> then this problem also exists in the current code.
I think the point here is that you need to acquire lock on a relation
before you start inspecting its dependencies. The patch might already
do that OK, I haven't looked at it yet.
Basically: it's the user's fault if he says "TRUNCATE t2" in a situation
where the referent of t2 might be changing concurrently. But once
you've identified t2, it's your fault if you don't track the
dependencies of t2 correctly, even if someone else is busy renaming them.
regards, tom lane
