| 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: | Whole Thread | Raw Message | 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 |