| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER TABLE TODO items |
| Date: | 2004-05-07 01:50:24 |
| Message-ID: | 409AEB60.1010503@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I left the statistic setting as-is (do you think that's wrong?) but the
> storage spec gets reset to whatever the default for the new type is.
Seems reasonable.
> We could talk about doing something more complicated, such as "keep the
> old setting if both old and new types support toasting, else reset to
> new default". Not sure if that'd be better or not.
Yeah, I was thinking along those lines. I don't now though...
What happens with ordering of operations in the ALTER TABLE statement?
Like if I put an alter TYPE and a SET STORAGE in the same statement
(wiht commas between), in what order will things happen? Is it
deterministic? Is it documented? Are there situations where a crazy
collection of 20 commands in a single ALTER TABLE will have
unpredictable effects?
Also, should the syntax be SET TYPE, not just TYPE?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-05-07 02:02:22 | Re: ALTER TABLE TODO items |
| Previous Message | Christopher Kings-Lynne | 2004-05-07 01:46:41 | Re: psql 7.3.4 disagrees with NATURAL CROSS JOIN |