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. +
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. +
Import Notes
Reply to msg id not found: 446B9A3F.4080700@DakotaCom.Net | Resolved by subject fallback
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:
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. +
Import Notes
Reply to msg id not found: 446B9D10.3020000@DakotaCom.Net | Resolved by subject fallback
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
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