On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-02-12 12:37:35 -0500, Robert Haas wrote: >> On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund <and...@anarazel.de> wrote: >> > I'm not really a fan. I'd rather change existing callers to add a >> > 'flags' bitmask argument. Right now there can't really be XLogInserts() >> > in extension code, so that's pretty ok to change. >> >> Yeah, but to what benefit? You're just turning a smaller patch into a >> bigger one and requiring churning a bunch of code that wouldn't >> otherwise need to be touched. I think Michael has a good point. > > It has the advantage of not ending up with an extra interface, that > we're otherwise never going to get rid of? If not now, when would we > remove it? Sure it touches a few more lines, but that's entirely trivial > mechanical changes, so what?
I don't think that it's a bad thing to have a simple interface for simple use cases and a complex one for more complex cases. I don't feel any need to convert every use of ReadBuffer() in the source code to ReadBufferExtended(), for example. Nor do I feel like we should have changed every call to LockAcquire() instead of introducing LockAcquireExtended(). This case seems analogous, and there are a few advantages. One is that it avoids creating meaningless conflicts when back-patching. Another is that when a function gets an extra argument, that often turns out to be something that happens more than once. It's nice not to keep having to whack around every call in the tree every time the call signature changes. Also, finding the small number of callers that need non-default behavior is simplified, because you can just grep for the Extended version of the function and there won't be many hits. I don't feel that there's only one right way to do this, but I think Michael's position is both reasonable and similar to what we have done in previous cases of this sort. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
