From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Truncation of object names |
Date: | 2001-04-13 18:54:47 |
Message-ID: | 5280.987188087@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ncm(at)zembu(dot)com (Nathan Myers) writes:
> Sorry, false alarm. When I got the test case, it turned out to
> be the more familiar problem:
> create table foo_..._bar1 (id1 ...);
> [notice, "foo_..._bar1" truncated to "foo_..._bar"]
> create table foo_..._bar (id2 ...);
> [error, foo_..._bar already exists]
> create index foo_..._bar_ix on foo_..._bar(id2);
> [notice, "foo_..._bar_ix" truncated to "foo_..._bar"]
> [error, foo_..._bar already exists]
> [error, attribute "id2" not found]
> It would be more helpful for the first "create" to fail so we don't
> end up cluttered with objects that shouldn't exist, and which interfere
> with operations on objects which should.
Seems to me that if you want a bunch of CREATEs to be mutually
dependent, then you wrap them all in a BEGIN/END block.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-04-13 20:12:38 | Re: Truncation of object names |
Previous Message | Bruce Momjian | 2001-04-13 18:28:54 | Re: timeout on lock feature |