Re: bug: copy progress reporting of backends which run multiple COPYs

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: bug: copy progress reporting of backends which run multiple COPYs
Дата
Msg-id CAEze2Whp9GVuU1rXS9fAx7TeLxyU=nLda_eJkQ7Y5SUc+R59_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: bug: copy progress reporting of backends which run multiple COPYs  (Ted Yu <yuzhihong@gmail.com>)
Список pgsql-hackers
On Sat, 21 Jan 2023 at 02:04, Ted Yu <yuzhihong@gmail.com> wrote:
>
>
>
> On Fri, Jan 20, 2023 at 4:51 PM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>>
>> Attached a patch that solves this specific issue in a
>> binary-compatible way. I'm not super happy about relying on behavior
>> of callers of BeginCopyFrom (assuming that users that run copy
>> concurrently will not provide a ParseState* to BeginCopyFrom), but it
>> is what it is.
>
> Is it possible to check range_table / rteperminfos so that we don't introduce the bool field ?

I think yes, but I'm not sure we can depend on rteperminfos to be set,
and the same for p_rtable. I also don't think it's a good idea for
code clarity: there is no good reason why the (un)availability of
either range_table or rteperminfos would allow progress reporting - it
would require additional extensive documentation around both the usage
sites and the field itself. Adding a well-named field provides a much
better experience in my opinion.

If someone were opposed to adding that field in backbranches I'm fine
with using one of these instead, assuming additional clear
documentation is added as well.

- Matthias



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: libpqrcv_connect() leaks PGconn
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: bug: copy progress reporting of backends which run multiple COPYs