| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCHES] Demo patch for DROP COLUMN |
| Date: | 2002-07-23 19:56:39 |
| Message-ID: | 1027454199.2346.4.camel@rh72.home.ee |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
On Tue, 2002-07-23 at 20:42, Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> >> But you *didn't* make sure it would never be a problem.
>
> > Wasn't I looping until I found a unique name?
>
> My point was that there could still be a conflict against a user column
> that the user tries to create *later*. So it's illusory to think that
> making the name of a dropped column less predictable will improve
> matters.
The simple (to describe, perhaps not to implement ;) way to resolve it
would be for the ADD COLUMN (or CREATE TABLE INHERITS) rename the
offending deleted column once more.
--------------
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yuva Chandolu | 2002-07-23 20:01:42 | Howmany connections postgres can handle upto? |
| Previous Message | Mike Mascari | 2002-07-23 16:55:23 | Re: [PATCHES] prepareable statements |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-07-23 21:52:39 | Re: lock listing |
| Previous Message | Dmitry Tkach | 2002-07-23 16:55:33 | JDBC timestamp does not understand [-]infinity |