Re: Cache lookup errors with functions manipulation object addresses
От | Alvaro Herrera |
---|---|
Тема | Re: Cache lookup errors with functions manipulation object addresses |
Дата | |
Msg-id | 20180514223252.hpishgl36qxtvmgx@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Cache lookup errors with functions manipulation object addresses (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Cache lookup errors with functions manipulation object addresses
|
Список | pgsql-hackers |
On 2018-May-15, Michael Paquier wrote: > On Mon, May 14, 2018 at 04:27:48PM -0400, Alvaro Herrera wrote: > > I think we're better off adding a new function and avoid changing the > > signature of GetForeignServer et al. Or maybe rename the function and > > keep the original name as a compatibility wrapper macro. > > On the other hand, if we make the change visible because of a > compilation failures, then modules would become aware of the problem and > react? Presumably, if you invoke a FDW and its handler finds that the ForeignServer doesn't exist, what is it to do other than raise an error? I can't see that there's any possible improvement. So, I don't know -- if the reaction is to add a #ifdef for pg version that adds a second argument passed always false, then we haven't won anything. > I would not expect modules to set missing_ok to true anyway as they > expect those objects to exist, so I can live with a new function. Exactly. > What about naming those GetForeignServerExtended and > GetForeignDataWrapperExtended? WFM. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: