Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
От | Marko Kreen |
---|---|
Тема | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |
Дата | |
Msg-id | e51f66da0902090519g37fd8a1fl27495db764e699e7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
|
Список | pgsql-hackers |
On 2/9/09, Martijn van Oosterhout <kleptog@svana.org> wrote: > On Mon, Feb 09, 2009 at 02:47:21PM +0200, Marko Kreen wrote: > > > That might be true but I know of apps that use them. Having the ability to > > > migrate those slowly by using SET WITHOUT OIDS is a Good Thing (tm). > > > > +1 for removal. > > > > Also, whether the removal happens or not, I would suggest a setting that > > makes Postgres accept, but ignore default_with_oids / WITH OIDS settings. > > Err, you mean a setting that makes Postgres throw an error on the use > of WITH OIDS. Just silently ignoring the option is a fantastic way to > break applications silently. For me, ignoring is easier... But yeah, error would be better, if it does not affect reloading the dump. > Making pg_dump not output the WITH OIDS option on tables may be an > easier option. I don't like it - it would require more work from users, but does not seem to be any way safer. You usually do the check if db works on restore time, not dump time... From clarity standpoint, options that turns both default_with_oids and WITH OIDS to errors seems the best. -- marko
В списке pgsql-hackers по дате отправления: