Re: Simple Atomic Relationship Insert

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 <brian(at)omniti(dot)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_eater(at)gmx(dot)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(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-general
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>