On Thu, Jan 23, 2014 at 11:10 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 22, 2014 at 12:42 PM, Andres Freund <and...@2ndquadrant.com> > wrote: >> On 2014-01-22 12:40:34 -0500, Robert Haas wrote: >>> On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> > Andres Freund <and...@2ndquadrant.com> writes: >>> >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid >>> >> breaking external code using lwlocks? >>> > >>> > +1, in fact there's probably no reason to touch most *internal* code using >>> > that type name either. >>> >>> I thought about this but figured it was too much of a misnomer to >>> refer to a pointer as an ID. But, if we're sure we want to go that >>> route, I can go revise the patch along those lines. >> >> I personally don't care either way for internal code as long as external >> code continues to work. There's the argument of making the commit better >> readable by having less noise and less divergence in the branches and >> there's your argument of that being less clear. > > OK, well then, if no one objects violently, I'll stick my current > approach of getting rid of all core mentions of LWLockId in favor of > LWLock *, but also add typedef LWLock *LWLockId with a comment that > this is to minimize breakage of third-party code.
Hearing no objections, violent or otherwise, I've done that, made the other adjustments suggested by Andres and KaiGai, and committed this. Let's see what the buildfarm thinks... -- 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
