Re: LOCK for non-tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LOCK for non-tables
Date: 2011-01-15 12:07:21
Message-ID: AANLkTiknsDO=Gw3Ntgs8vTBHx4hVj+ZHE0YXzfCEH8nh@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
>> On Jan15, 2011, at 02:03 , Tom Lane wrote:
>> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> >> Me, too.  But I don't agree with your particular choice of small
>> >> syntax adjustment.  Maybe we should just let the issue drop for now.
>> >> Nobody's actually complained about this that I can recall; it's just a
>> >> comment that's been sitting there in pg_dump for ages, and I was
>> >> inspired to think of it again because of the SQL/MED work.  I'm not
>> >> sufficiently in love with this idea to walk through fire for it.
>> >
>> > Agreed.  Once there's some pressing need for it, it'll be easier to make
>> > the case that some amount of incompatibility is acceptable.
>>
>> Assuming that day will come eventually, should we deprecate the LOCK <table>
>> shortcut now to ease the transition later? If people want that, I could go
>> through the docs and add some appropriate warnings.
>
> Sounds good to me.

+1.

> I think we should have a section in the release notes on Deprecated
> Features, noting that certain things will be removed later and should be
> changed now and not relied upon in the future. A pending
> incompatibilities list.

Agreed. Of course, the problem is sometimes we don't do what we say
we're going to do, but it's worth a try.

> I would urge people to come up with a much wider list of "things we
> don't like" so we can more easily avoid discussions like this in the
> future. Forward planning helps make change easier.

Optional keywords!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-15 12:12:10 Re: kill -KILL: What happens?
Previous Message Robert Haas 2011-01-15 12:05:57 Re: Spread checkpoint sync