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: | Whole Thread | Raw Message | 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
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.. |