Re: Transactional-DDL DROP/CREATE TABLE
От | Geoff Winkless |
---|---|
Тема | Re: Transactional-DDL DROP/CREATE TABLE |
Дата | |
Msg-id | CAEzk6fcqs4=k0oiAdMCQj8aW0obB4QLQQ8Gj97+Q8QfZnrJ=Kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transactional-DDL DROP/CREATE TABLE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On 6 October 2016 at 18:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm a bit confused about exactly what the context is here. AFAICS, > the fragment you quoted should work as you expect, as long as the > table always exists beforehand. Then, the DROPs serialize the > transactions' access to the table and all is well. On the other hand, > if the table *doesn't* exist beforehand, there is nothing to serialize > on and the behavior Adrian exhibited is what I'd expect. I accept that this is how things are. I'm just surprised that "DROP TABLE IF EXISTS" doesn't do the exists-test at commit time, rather than effectively being "DROP TABLE IF EXISTED-AT-SOME-RANDOM-POINT-IN-THE-PAST". At the end of the day this isn't a massive deal - I can simply add exception code around the failure, as Francisco suggested, or add oplocks around the code (as per Kevin), or (I suppose) I could do an individual transaction to CREATE TABLE IF NOT EXISTS as a separate transaction before I start; it's just something that caught me out because I didn't expect it to be a problem. Geoff
В списке pgsql-general по дате отправления: