Re: Change RangeVarGetRelidExtended() to take flags argument? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Change RangeVarGetRelidExtended() to take flags argument?
Date
Msg-id 20180306010659.xhzq2cwl6lx6n4jo@alap3.anarazel.de
Whole thread Raw
In response to Re: Change RangeVarGetRelidExtended() to take flags argument?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Change RangeVarGetRelidExtended() to take flags argument?
List pgsql-hackers
On 2018-03-05 19:57:44 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > One wrinkle in that plan is that it'd not be trivial to discern whether
> > a lock couldn't be acquired or whether the object vanished.  I don't
> > really have good idea how to tackle that yet.
> 
> Do we really care which case applies?

I think there might be cases where we do. As expand_vacuum_rel()
wouldn't use missing_ok = true, it'd not be an issue for this specific
callsite though.


> But having to mess with the semantics of RangeVarGetRelidExtended seems
> like a good reason not to go down this path...

Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of
similar code. It'd not be too hard to move RangeVarGetRelidExtended()
code into RangeVarGetRelidInternal() and add
RangeVarGetRelidTryLock(). Not sure if that's any better.  Or just add
RangeVarGetRelidExtended2() :)

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PATCH: Configurable file mode mask
Next
From: Michael Paquier
Date:
Subject: Re: Change RangeVarGetRelidExtended() to take flags argument?