Re: BUG #7920: Sequence rename leave stale value for sequence_name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: maxim(dot)boguk(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7920: Sequence rename leave stale value for sequence_name
Date: 2013-03-06 15:48:08
Message-ID: 16139.1362584888@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-03-06 09:27:55 -0500, Tom Lane wrote:
>> Removing the sequence_name column alone would also break existing code,
>> for ... um ... not much.

> The only argument I see is reduced chance of people making errors. Code
> that actually uses sequence_name is broken.

Well, only if you rename the sequence, which is something many people
would never do.

> If we had something like columns that are computed on output, we could
> use that. What we could do is invent a new pseudo-column type like
> tableoid that renders as text..

> In the end it doesn't seem worth bothering.

Yeah. If I recall the older discussions correctly, we talked about
somehow splitting a sequence's storage between transactionally-updatable
and non-transactionally-updatable parts, so that we could make altering
a sequence's parameters transactional. Preserving anything remotely
like "select * from sequence" would require a view or some such.
Whenever somebody gets around to attacking that whole problem, I'll be
for that; but in the meantime it seems like we should leave it alone
instead of making marginal changes.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2013-03-06 17:34:29 Re: BUG #7918: limitation of pagination with LIMIT and OFFSET
Previous Message kovaral 2013-03-06 14:59:53 BUG #7921: Problem while initializing db..initdb could not create directory..