Re: [HACKERS] Re: [SQL] Column name's length
От | Philip Warner |
---|---|
Тема | Re: [HACKERS] Re: [SQL] Column name's length |
Дата | |
Msg-id | 3.0.5.32.19990603130057.00a35ba0@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [SQL] Column name's length (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: [SQL] Column name's length
|
Список | pgsql-hackers |
At 09:16 2/06/99 -0400, you wrote: > >Well, it's only good if the system will get rid of the objects when >the user drops the owning table. This is true for indexes but AFAIK >it is not yet true for sequences. So if we go with pg_ prefix now, >there will be *no* way short of superuser privilege to get rid of the >sequence object for a deleted table that had a serial field. > >Also, this will break pg_dump, which will have no good way to restore >the state of a serial sequence object. (CREATE SEQUENCE pg_xxx will >fail, no?) I know I'm probably out of my depth here, but couldn't pg_dump ignore everything with a pg_* prefix? It can (safely?) assumeany 'system' structures will be created as a result of some other user-based definition it is dumping? [If you beat me about the head, I'll shut up] Philip Warner. P.S. I also like the idea of creating the 'system' structures with readily and reliably identifiable names, since it potentiallygives the option of the user choosing to 'hide' them. As a user with about 20000 blobs to load, the output ofa \d is pretty cumbersome. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: