Re: create if not exists (CINE)
| От | Asko Oja |
|---|---|
| Тема | Re: create if not exists (CINE) |
| Дата | |
| Msg-id | ecd779860905052222q22fc8cb0h53c4626a4886d392@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: create if not exists (CINE) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: create if not exists (CINE)
|
| Список | pgsql-hackers |
It was just yesterday when i wondering why we don't have this feature (i was trying to use it and it wasn't there :).
The group of people who think it's unsafe should not use the feature.
Clearly this feature would be useful when managing large amounts of servers
and would simplify our release process.
The group of people who think it's unsafe should not use the feature.
Clearly this feature would be useful when managing large amounts of servers
and would simplify our release process.
On Wed, May 6, 2009 at 5:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 5, 2009 at 9:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:>> The argument was not about whether that is the "plain meaning" of theIn the thread that went into this in most detail
>> phrase; it was about whether that is a safe and useful behavior for a
>> command to have. There is a pretty substantial group of people who
>> think that it would be quite unsafe, which is why we failed to arrive
>> at a consensus that this is a good thing to implement.
> Who are these people other than you,
http://archives.postgresql.org//pgsql-hackers/2005-10/msg00632.php
it seemed that wanting CINE was a minority opinion, and in any case
a number of pretty serious issues were raised.Yes, I did. I'm not any more convinced than I was before. In
> and did you read the rest of my email?
particular, the example you give is handled reasonably well without
*any* new features, if one merely ignores "object already exists"
errors.
It sounds pretty amazing. Ignoring errors as a suggested way to use PostgreSQL.
We run our release scripts inside transactions (with exception of concurrent index creation). So if something unexpected happens we are left still in working state.
PostgreSQL ability to do DDL changes inside transaction was one of biggest surprises/improvements when switching from Oracle. Now you try to bring us down back to the level of Oracle :)
We run our release scripts inside transactions (with exception of concurrent index creation). So if something unexpected happens we are left still in working state.
PostgreSQL ability to do DDL changes inside transaction was one of biggest surprises/improvements when switching from Oracle. Now you try to bring us down back to the level of Oracle :)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: