Re: dblink performance regression

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: dblink performance regression
Дата
Msg-id 52A66A55.5010300@nasby.net
обсуждение исходный текст
Ответ на Re: dblink performance regression  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
On 12/7/13 7:50 PM, Joe Conway wrote:
> On 12/07/2013 05:41 PM, Fabrízio de Royes Mello wrote:
>> >
>> >On Sat, Dec 7, 2013 at 11:20 PM, Michael Paquier
>> ><michael.paquier@gmail.com  <mailto:michael.paquier@gmail.com>>
>> >wrote:
>>>> >>>
>>>> >>>IMHO is more elegant create a procedure to encapsulate the code
>>>> >>>to avoid redundancy.
>>> >>Yep, perhaps something like PQsetClientEncodingIfDifferent or
>>> >>similar would make sense.
>> >
>> >Well I think at this first moment we can just create a procedure
>> >inside the dblink contrib and not touch in libpq.
> Maybe a libpq function could be done for 9.4, but not for back branches.

Stupid question... why don't we just pass encoding in with the other connection parameters? That eliminates any
ambiguity.The only issue would be if the user also passed that in via connstr... though now that I think about it, we
currentlysilently ignore that parameter, which IMHO is bad. We should either respect if the user passes that in (ie:
notdo anything at all), or we should throw an error.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: ANALYZE sampling is too good