Hello, At Thu, 17 Jul 2014 15:54:31 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <10710.1405626...@sss.pgh.pa.us> > Peter Geoghegan <p...@heroku.com> writes: > > On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera > > <alvhe...@2ndquadrant.com> wrote: > >> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED > >> symbols. It's not like we could do anything different than > >> BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it > >> might make more sense to have specialized symbols, but as it is it seems > >> pointless.
I agree with you. From the eyes not specialized for each AM, of me, the translation-only symbols didn't make me so happy. > > It's a pattern common to the index AMs. I think it's kind of pointless > > myself, but as long as we're doing it we might as well be consistent. > > I think that to the extent that these symbols are used in APIs above the > direct buffer-access layer, they are useful --- for example using > BT_READ/BT_WRITE in _bt_search calls seems like a useful increment of > readability. GIN seems to have less of that than some of the other AMs, > but I do see GIN_SHARE being used that way in some calls. > > BTW, there's one direct usage of BUFFER_LOCK_EXCLUSIVE in the GIST code > as well, which should probably be replaced with GIST_EXCLUSIVE if we're > trying to be consistent. Though I brought up this topic, this kind of consistency seems not needed so much. If so, it seems better to be left as it is. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
