Re: improve PQexec documentation

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: improve PQexec documentation
Дата
Msg-id alpine.DEB.2.21.1904121734510.2780@lancre
обсуждение исходный текст
Ответ на Re: improve PQexec documentation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: improve PQexec documentation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Hello Alvaro,

>> I'm looking at psql's use of PQexec for implementing some feature.
>>
>> When running with multiple SQL commands, the doc is not very helpful.
>>
>> From the source code I gathered that PQexec returns the first COPY results
>> if any, and if not the last non-empty results, unless all is empty in which
>> case an empty result is returned.
>
> I'm not sure we necessarily want to document this behavior.  If it was
> super helpful for some reason, or if we thought we would never change
> it, then it would make sense to document it in minute detail.  But
> otherwise I think documenting it sets a promise that we would (try to)
> never change it in the future, which I don't necessarily agree with --
> particularly since it's somewhat awkward to use.
>
> I'm inclined to reject this patch.

Hmmm. I obviously agree that PQexec is beyond awkward.

Now I'm not sure how anyone is expected to guess the actual function 
working from the available documentation, and without this knowledge I 
cannot see how to write meaningful code for the multiple query case.

Basically it seems to have been designed for simple queries, and then 
accomodated somehow for the multiple case but with a strange non 
systematic approach.

I think it would have been much simpler and straightforward to always 
return the first result and let the client do whatever it wants 
afterwards. However, as it has existed for quite some time, I'm unsure how 
likely it is to change as it would break existing code, so documenting its 
behavior seems logical. I'd be all in favor of changing the behavior, but 
I'm pessimistic that it could pass. Keeping the current status (not really 
documented & awkward behavior) seems rather strange.

-- 
Fabien.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: hyrax vs. RelationBuildPartitionDesc
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Adding Unix domain socket path and port to pg_stat_get_wal_senders()