Brent Verner <[EMAIL PROTECTED]> writes:
> Thanks for fixing that problem. Out of curiousity, did you put that
> code in the renameatt() function for any reason, or is it just a
> style thing?
Just to avoid closing and reopening the target relation and pg_attribute
relation. Releasing and then
On 08 Oct 2001 at 14:43 (-0400), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > wooohoo!!! Of course, it would be best if someone else looked this
| > code over, because I get the feeling there is an easier way to get
| > this done.
|
| No, that's about right, except that you for
Brent Verner <[EMAIL PROTECTED]> writes:
> wooohoo!!! Of course, it would be best if someone else looked this
> code over, because I get the feeling there is an easier way to get
> this done.
No, that's about right, except that you forgot one step: you shouldn't
try to update column names of fun
It occurs to me that the real problem is not so much ALTER RENAME not
doing enough, as it is psql doing the wrong thing. The \d display for
indexes is almost entirely unhelpful, since it doesn't tell you such
critical stuff as whether the index is a functional index nor which
index opclasses are
The attached patch works for my case...
regression=# create table test (id serial, col1 varchar(64));
NOTICE: CREATE TABLE will create implicit sequence 'test_id_seq' for SERIAL column
'test.id'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_id_key' for table 'test'
CREATE
regres
