| From: | David Newall <postgresql(at)davidnewall(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Lost search_path after transaction fails |
| Date: | 2009-02-16 00:14:36 |
| Message-ID: | 4998AFEC.3000706@davidnewall.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Heikki Linnakangas wrote:
> ecpg implicitly runs everything inside transactions. You don't need to
> run START TRANSACTION, that's implicit. Therefore the "set
> search_path" command is in fact run in the same transaction as the
> failing insert, as also hinted by the warning "there is already a
> transaction in progress" at the START TRANSACTION command.
Thanks for your reply. Committing after setting search_path does
resolve this problem. It surprises me that a session parameter is
treated in this way.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mathias Seiler | 2009-02-16 02:18:20 | BUG #4656: Indexes not used when comparing nextval() and currval() to integers |
| Previous Message | Magnus Hagander | 2009-02-15 13:59:05 | Re: pg_listener entries deleted under heavy NOTIFY load only on Windows |