Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
От | Simon Riggs |
---|---|
Тема | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. |
Дата | |
Msg-id | 1216283205.19656.490.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. ("Dave Page" <dpage@pgadmin.org>) |
Ответы |
Re: pgsql: Allow TRUNCATE foo, foo to succeed,
per report from Nikhils.
|
Список | pgsql-committers |
On Thu, 2008-07-17 at 09:00 +0100, Dave Page wrote: > On Thu, Jul 17, 2008 at 8:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > > > On Thu, 2008-07-17 at 11:16 +0530, Nikhils wrote: > > > > > >> I presented a simple psql version here. I was actually processing > >> multiple relations in my C library in which truncate was invoked on > >> all the involved relations. I was passing a list of these rels to > >> ExecuteTruncate which barfed when the same rel was mentioned twice in > >> that list. Its really an implementation issue as Tom mentioned. > > > > So you think we should change Postgres rather than your program? > > Many people think that on list, and are ignored. > > > > Why no bug report, proposal or patch? Why during a commit fest? > > Huh? There was a bug report, with suggested fix on June 5th from > Nikhil - http://archives.postgresql.org/pgsql-hackers/2008-06/msg00231.php > > No-one responded, and over a month later Bruce fixed the bug, pointing > out that TRUNCATE is now consistent with LOCK. > > The fact that Bruce fixed it during a commit fest is irrelevant. Bug > fixes don't stop for commit fests OK, my mistake. Comments withdrawn, with apologies. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-committers по дате отправления: