Обсуждение: ALTER SEQUENCE
Hi, It doesn't appear that there is a way to rename a sequence (ideally with a "cascade" action). Nor does there appear to be a way to change the owner of a sequence. Obviously, I can DROP and recreate... *but*, how prudent (foolish?) would it be just to change the entries in the system tables, instead?
Don Y wrote:
> Hi,
>
> It doesn't appear that there is a way to rename a sequence
> (ideally with a "cascade" action).
Uh, the ALTER SEQUENCE manual page says:
Some variants of ALTER TABLE can be used with sequences as
well; for example, to rename a sequence use ALTER TABLE
RENAME.
Does that help?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Don Y wrote: >> Hi, >> >> It doesn't appear that there is a way to rename a sequence >> (ideally with a "cascade" action). > > > Uh, the ALTER SEQUENCE manual page says: Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of this. Nor does "\h ALTER SEQUENCE" in psql yield any pointers. > Some variants of ALTER TABLE can be used with sequences as > well; for example, to rename a sequence use ALTER TABLE > RENAME. > > Does that help? Sure! It appears to allow both the rename and change of ownership. Thanks! Obviously, the documentation doesn't agree with the code :-( But, it still leaves unanswered the question of the risk involved in just changing the name/owner in the system tables...
Don Y wrote: > Bruce Momjian wrote: > > Don Y wrote: > >> Hi, > >> > >> It doesn't appear that there is a way to rename a sequence > >> (ideally with a "cascade" action). > > > > > > Uh, the ALTER SEQUENCE manual page says: > > Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of this. > Nor does "\h ALTER SEQUENCE" in psql yield any pointers. > > > Some variants of ALTER TABLE can be used with sequences as > > well; for example, to rename a sequence use ALTER TABLE > > RENAME. > > > > Does that help? > > Sure! It appears to allow both the rename and change of ownership. > Thanks! I see the documentation mention added August 1, 2005 byt Tom Lane. > Obviously, the documentation doesn't agree with the code :-( > > But, it still leaves unanswered the question of the risk involved > in just changing the name/owner in the system tables... It is best to use ALTER. The only other sure-safe way to do it is to look at the ALTER code and do the same things with the system tables. However, in most cases a system table modification works fine, but I don't recommend it for production servers. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Don Y wrote: >> Bruce Momjian wrote: >>> Don Y wrote: >>>> Hi, >>>> >>>> It doesn't appear that there is a way to rename a sequence >>>> (ideally with a "cascade" action). >>> >>> Uh, the ALTER SEQUENCE manual page says: >> Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of this. >> Nor does "\h ALTER SEQUENCE" in psql yield any pointers. >> >>> Some variants of ALTER TABLE can be used with sequences as >>> well; for example, to rename a sequence use ALTER TABLE >>> RENAME. >>> >>> Does that help? >> Sure! It appears to allow both the rename and change of ownership. >> Thanks! > > I see the documentation mention added August 1, 2005 byt Tom Lane. Date tag on the bottom of my man pages is "2005-01-17" -- so that explains *that*! :> In general, how safe is it to use "current" man pages (to sidestep these sorts of issues)? Obviously, there will be things in the newer pages that reflect changes NOT present in older versions... but, will the documentation updates (i.e. this a prime example) outweigh the confusion added by documentation for not-yet-existent features/fixes/etc.?) >> Obviously, the documentation doesn't agree with the code :-( >> >> But, it still leaves unanswered the question of the risk involved >> in just changing the name/owner in the system tables... > > It is best to use ALTER. The only other sure-safe way to do it is to > look at the ALTER code and do the same things with the system tables. > However, in most cases a system table modification works fine, but I > don't recommend it for production servers. One would *hope* that there was no redundant "information" in the tables... but, realistically, that may not be the case (efficiency hacks, etc.) For *this* problem, an obvious solution exists. And, even if it didn't, dropping the sequence, recreating it and reinitializing it wouldn't be that painful. I'm just wondering how aggressive I should be in "tinkering"... :-( Thanks! --don
Don Y wrote: > Bruce Momjian wrote: > > Don Y wrote: > >> Bruce Momjian wrote: > >>> Don Y wrote: > >>>> Hi, > >>>> > >>>> It doesn't appear that there is a way to rename a sequence > >>>> (ideally with a "cascade" action). > >>> > >>> Uh, the ALTER SEQUENCE manual page says: > >> Uh, the 8.0.3 man page for ALTER SEQUENCE makes no mention of this. > >> Nor does "\h ALTER SEQUENCE" in psql yield any pointers. > >> > >>> Some variants of ALTER TABLE can be used with sequences as > >>> well; for example, to rename a sequence use ALTER TABLE > >>> RENAME. > >>> > >>> Does that help? > >> Sure! It appears to allow both the rename and change of ownership. > >> Thanks! > > > > I see the documentation mention added August 1, 2005 byt Tom Lane. > > Date tag on the bottom of my man pages is "2005-01-17" -- so that > explains *that*! :> > > In general, how safe is it to use "current" man pages (to > sidestep these sorts of issues)? Obviously, there will be Uh, not very safe. > things in the newer pages that reflect changes NOT present > in older versions... but, will the documentation updates > (i.e. this a prime example) outweigh the confusion added > by documentation for not-yet-existent features/fixes/etc.?) Probably not. This is an edge case, and often we backpatch changes like this, though that didn't happen in this case. For example, when I find doc things to add for 8.2, I add them to 8.1 if appropriate. > >> Obviously, the documentation doesn't agree with the code :-( > >> > >> But, it still leaves unanswered the question of the risk involved > >> in just changing the name/owner in the system tables... > > > > It is best to use ALTER. The only other sure-safe way to do it is to > > look at the ALTER code and do the same things with the system tables. > > However, in most cases a system table modification works fine, but I > > don't recommend it for production servers. > > One would *hope* that there was no redundant "information" > in the tables... but, realistically, that may not be the > case (efficiency hacks, etc.) Uh, there is dependency information that might be affected by certain updates. It isn't really redundant. > For *this* problem, an obvious solution exists. And, even > if it didn't, dropping the sequence, recreating it and > reinitializing it wouldn't be that painful. I'm just > wondering how aggressive I should be in "tinkering"... :-( You really have to consult the code to find out. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, May 17, 2006 at 03:00:48PM -0700, Don Y wrote: > >I see the documentation mention added August 1, 2005 byt Tom Lane. > > Date tag on the bottom of my man pages is "2005-01-17" -- so that > explains *that*! :> This is a very minor reason why you should be running the most recent 8.0.x release and not 8.0.3. A much bigger reason is that there are data-loss bugs that have been fixed. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > On Wed, May 17, 2006 at 03:00:48PM -0700, Don Y wrote: >>> I see the documentation mention added August 1, 2005 byt Tom Lane. >> Date tag on the bottom of my man pages is "2005-01-17" -- so that >> explains *that*! :> > > This is a very minor reason why you should be running the most recent > 8.0.x release and not 8.0.3. A much bigger reason is that there are > data-loss bugs that have been fixed. <grin> You're always faced with the decision of which set of bugs/features to stick with during development. If we upgrade every time there is a new release, we spend lots of time doing upgrades instead of developing! :-( The folks watching the Postgres releases haven't yet said we need to "step forward". The only problem *I* have found has been documentation related (above) so not an inconvenience. I don't believe any other folks have experienced major lossage (here) under 8.0.3. So, it hasn't been expensive to stick with a non-current release. (hopefully it will stay that way for us for a while longer, yet...)
Don Y <pgsql@DakotaCom.Net> writes:
> Jim C. Nasby wrote:
>> This is a very minor reason why you should be running the most recent
>> 8.0.x release and not 8.0.3. A much bigger reason is that there are
>> data-loss bugs that have been fixed.
> The folks watching the Postgres releases haven't yet said
> we need to "step forward".
Are these folks actually watching, or just asleep at the wheel?
8.0.4, 8.0.5, and 8.0.6 each contain a fix for a can-bite-anyone-at-
any-time data-loss bug. Even if you are convinced you do not care
about any of the numerous other bugs those releases fix, I will have
zero sympathy for you when your 8.0.3 installation eats your data
because of one of those bugs.
> I don't believe any other folks have experienced major lossage
> (here) under 8.0.3.
Read the archives. Other people have gotten bit; are you feeling
lucky? If so why?
(Just for the record, there are new updates coming out Tuesday,
and my actual recommendation today would be to wait for 8.0.8.
But once it's out, you need to get off your duff.)
regards, tom lane
Tom Lane wrote: > Don Y <pgsql@DakotaCom.Net> writes: >> Jim C. Nasby wrote: >>> This is a very minor reason why you should be running the most recent >>> 8.0.x release and not 8.0.3. A much bigger reason is that there are >>> data-loss bugs that have been fixed. > >> The folks watching the Postgres releases haven't yet said >> we need to "step forward". > > Are these folks actually watching, or just asleep at the wheel? > > 8.0.4, 8.0.5, and 8.0.6 each contain a fix for a can-bite-anyone-at- > any-time data-loss bug. Even if you are convinced you do not care > about any of the numerous other bugs those releases fix, I will have > zero sympathy for you when your 8.0.3 installation eats your data > because of one of those bugs. > >> I don't believe any other folks have experienced major lossage >> (here) under 8.0.3. > > Read the archives. Other people have gotten bit; are you feeling > lucky? If so why? > > (Just for the record, there are new updates coming out Tuesday, > and my actual recommendation today would be to wait for 8.0.8. > But once it's out, you need to get off your duff.) We aren't populating tables. Most of our work is involved in the things *around* the database (the database is just a small piece of the puzzle). I, for example, drop all of my tables at the end of each work day -- along with most of the extensions I have loaded... things on the "outside" are just changing far more than the database itself. I'm sure once the framework *around* the database is stable and resilient enough, then the database will look like it needs attention -- and the order will come out to upgrade (to which version, I don't know... "it's not my job" :> )
On Fri, May 19, 2006 at 02:08:01AM -0400, Tom Lane wrote: > Don Y <pgsql@DakotaCom.Net> writes: > > Jim C. Nasby wrote: > >> This is a very minor reason why you should be running the most recent > >> 8.0.x release and not 8.0.3. A much bigger reason is that there are > >> data-loss bugs that have been fixed. > > > The folks watching the Postgres releases haven't yet said > > we need to "step forward". > > Are these folks actually watching, or just asleep at the wheel? > > 8.0.4, 8.0.5, and 8.0.6 each contain a fix for a can-bite-anyone-at- > any-time data-loss bug. Even if you are convinced you do not care > about any of the numerous other bugs those releases fix, I will have > zero sympathy for you when your 8.0.3 installation eats your data > because of one of those bugs. Maybe we should place greater emphasis on data-loss bugs in the release notes? Looking at the 8.0.6 notes for example, the first data loss fix is actually the second on the list, behind some less critical windows-only fix. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Thu, May 18, 2006 at 11:42:02PM -0700, Don Y wrote: > We aren't populating tables. Most of our work is involved > in the things *around* the database (the database is just a > small piece of the puzzle). I, for example, drop all of > my tables at the end of each work day -- along with most > of the extensions I have loaded... things on the "outside" > are just changing far more than the database itself. > I'm sure once the framework *around* the database is > stable and resilient enough, then the database will look > like it needs attention -- and the order will come out > to upgrade (to which version, I don't know... "it's not > my job" :> ) While I can certainly understand not keeping a bunch of development machines up-to-date, it would be nice if you at least checked the most recent version in the future before reporting things. :) BTW, there's some nice performance gains to be had it 8.1.x over 8.0.x, too. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461