Good points. I guess my feeling is that if there can be a race condition on INSERT then the CTE version is not truly atomic, hence the LOOP.
On Tue, Jan 13, 2015 at 3:11 PM, Brian Dunavant <br...@omniti.com> wrote: > A very good point, but it does not apply as here (and in my article) > we are not using updates, only insert and select. > > > > On Tue, Jan 13, 2015 at 6:03 PM, Thomas Kellerer <spam_ea...@gmx.net> > wrote: > > Brian Dunavant wrote on 13.01.2015 22:33: > >> > >> What issue are you having? I'd imagine you have a race condition on > >> the insert into hometowns, but you'd have that same race condition in > >> your app code using a more traditional 3 query version as well. > >> > >> I often use CTEs like this to make things atomic. It allows me to > >> remove transactional code out of the app and also to increase > >> performance by reducing the back-and-forth to the db. > >> http://omniti.com/seeds/writable-ctes-improve-performance > >> > > > > Craig Ringer explained some of the pitfalls of this approach here: > > > > > http://dba.stackexchange.com/questions/78510/why-is-cte-open-to-lost-updates > > > > which is a follow up question based on this: > > http://stackoverflow.com/a/8702291/330315 > > > > Thomas > > > > > > > > > > > > -- > > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-general > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
