Lists: | pgsql-hackers |
---|
From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | alter operator class |
Date: | 2007-03-19 17:43:23 |
Message-ID: | 45FECBBB.7010804@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
'alter operator class' command isn't "dumpable":
postgres=# ALTER OPERATOR CLASS name_pattern_ops USING btree RENAME TO namep_ops;
postgres=# create table n (a name);
postgres=# create index ni on n (a namep_ops);
% pg_dump postgres | psql wow
....
ERROR: operator class "namep_ops" does not exist for access method "btree"
That's because command doesn't track such changes in pg_depend or somewhere
else. For now that kind of changes doesn't make a significant sense - nobody
will change names/properties of system objects, but I'm afraid that will be
often for fulltext configurations. How can we avoid such situations?
Forbid changes on built-in objects?
'alter operator class .. owner to ...' doesn't dump too.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: alter operator class |
Date: | 2007-03-19 18:00:07 |
Message-ID: | 14621.1174327207@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> 'alter operator class' command isn't "dumpable":
> postgres=# ALTER OPERATOR CLASS name_pattern_ops USING btree RENAME TO namep_ops;
Sure it's dumpable. The point here is that name_pattern_ops is a
built-in object and so pg_dump doesn't think it should dump it.
Changing its name doesn't make it not built in.
> That's because command doesn't track such changes in pg_depend or somewhere
> else. For now that kind of changes doesn't make a significant sense - nobody
> will change names/properties of system objects, but I'm afraid that will be
> often for fulltext configurations. How can we avoid such situations?
I think you're going to need to draw a distinction between built-in and
not-built-in configurations. The canonical way to do this is to put
them into schemas and say the ones in pg_catalog are built in. And yes,
you need to ensure that there's not a good reason for people to change
the built-in ones.
regards, tom lane