Re: Truncation of object names

Поиск
Список
Период
Сортировка
От ncm@zembu.com (Nathan Myers)
Тема Re: Truncation of object names
Дата
Msg-id 20010413131238.P3797@store.zembu.com
обсуждение исходный текст
Ответ на Re: Truncation of object names  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Truncation of object names  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Apr 13, 2001 at 02:54:47PM -0400, Tom Lane wrote:
> ncm@zembu.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.

Yes, but...  The second and third commands weren't supposed to be 
related to the first at all, never mind dependent on it.  They were 
made dependent by PG crushing the names together.

We are thinking about working around the name length limitation 
(encountered in migrating from other dbs) by allowing "foo.bar.baz" 
name syntax, as a sort of rudimentary namespace mechanism.  It ain't
schemas, but it's better than "foo__bar__baz".

Nathan Myers
ncm@zembu.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Truncation of object names
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Truncation of object names