Re: [GENERAL] dblink: rollback transaction
| От | Joe Conway |
|---|---|
| Тема | Re: [GENERAL] dblink: rollback transaction |
| Дата | |
| Msg-id | 403AECE1.7020405@joeconway.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] dblink: rollback transaction (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [GENERAL] dblink: rollback transaction
|
| Список | pgsql-patches |
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >>One question that I'd like some feedback on is the following: should the >>same change be applied to other functions that might throw an ERROR >>based on the remote side of the connection? For example, currently if >>dblink() is used in an attempt to access a non-existent remote table, an >>ERROR is thrown locally in response, killing any currently open >>transaction. Thoughts? > What seems like a good idea after a few moments' thought is to leave the > behavior of the various dblink_foo() functions the same as now (ie, > throw error on remote error) and add new API functions named something > like dblink_foo_noerror() that don't throw error but return a > recognizable failure code instead. My argument for this approach is > that there is no situation in which the programmer shouldn't have to > think when he writes a given call whether it will elog or return an > error indicator, because if he wants an error indicator then he is going > to have to check for it. I like the idea in general, but maybe instead there should be a new overloaded version of the existing function names that accepts an additional bool argument. Without the argument, behavior would be as it is now; with it, you could specify the old or new behavior. Joe
В списке pgsql-patches по дате отправления: