| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Subject: | Re: NOT EXIST for PREPARE |
| Date: | 2016-03-24 00:02:43 |
| Message-ID: | CAMsr+YHZ2xxoLqK5awhU+NFnkrA4wZjTehE0+-KjUyOH0qY3ww@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 24 March 2016 at 02:01, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> > If you plan to have "prepare if not exists" at startup only, why don't
> > you just wrap it with
> > exception handler then?
>
> That's impolite to our users. Virtually all other commands have been
> decorated with IF [NOT] exists to avoid having to guard with exception
> handler -- why not this one? Also, if the handler is on the client
> side, it tends to be racey.
>
Yeah. Also, the log spam from that is ugly and it's really best avoided.
I find that to be a very frustrating issue with client-side upsert retry
loop approaches. Less of a concern now that 9.5 has a true upsert, but
that's not the only area where the client is expected to try it and handle
the error if it fails.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-03-24 00:10:55 | Re: Speed up Clog Access by increasing CLOG buffers |
| Previous Message | Craig Ringer | 2016-03-23 23:59:03 | Re: README for src/backend/replication/logical |