Re: LOCK for non-tables

<p>On Jan 15, 2011 12:30 PM, "Simon Riggs" <<a href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>
wrote:<br/> ><br /> > On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:<br /> > > On Jan15, 2011, at
02:03, Tom Lane wrote:<br /> > > > Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>writes:<br /> > > >> Me, too.  But I don't
agreewith your particular choice of small<br /> > > >> syntax adjustment.  Maybe we should just let the
issuedrop for now.<br /> > > >> Nobody's actually complained about this that I can recall; it's just a<br
/>> > >> comment that's been sitting there in pg_dump for ages, and I was<br /> > > >> inspired
tothink of it again because of the SQL/MED work.  I'm not<br /> > > >> sufficiently in love with this idea
towalk through fire for it.<br /> > > ><br /> > > > Agreed.  Once there's some pressing need for it,
it'llbe easier to make<br /> > > > the case that some amount of incompatibility is acceptable.<br /> >
><br/> > > Assuming that day will come eventually, should we deprecate the LOCK <table><br /> > >
shortcutnow to ease the transition later? If people want that, I could go<br /> > > through the docs and add some
appropriatewarnings.<br /> ><br /> > Sounds good to me.<br /> ><br /> ><br /> > I think we should have a
sectionin the release notes on Deprecated<br /> > Features, noting that certain things will be removed later and
shouldbe<br /> > changed now and not relied upon in the future. A pending<br /> > incompatibilities list.<p>+1. 
Thiswould be very useful. Its hard enough for us "on the inside" to keep track of things that we deprecated... <br
/><p>>I would urge people to come up with a much wider list of "things we<br /> > don't like" so we can more
easilyavoid discussions like this in the<br /> > future. Forward planning helps make change easier.<p>There is a
sectionon the TODO for that already, i think. Seems reasonable since this is more for developers than users. <p>/Magnus
<br/>