Re: Portal->commandTag as an enum

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Portal->commandTag as an enum
Дата
Msg-id D74DEEE9-17BC-4953-A8BE-25AA0C6D6F9D@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Portal->commandTag as an enum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Portal->commandTag as an enum  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

> On Feb 28, 2020, at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> I just realized that we could rename command_tag_display_last_oid() to
>> something like command_tag_print_a_useless_zero_for_historical_reasons()
>> and nothing would be lost.
>
> Is there a way to drop that logic altogether by making the tagname string
> be "INSERT 0" for the INSERT case?  Or would the zero bleed into other
> places where we don't want it?

In general, I don't think we want to increase the number of distinct tags.  Which command you finished running and
whetheryou want a rowcount and/or lastoid are orthogonal issues.  We already have problems with there being different
commandtagsfor different versions of morally the same commands.  Take for example "SELECT FOR KEY SHARE" vs.  "SELECT
FORNO KEY UPDATE" vs.  "SELECT FOR SHARE" vs.  "SELECT FOR UPDATE". 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Allowing ALTER TYPE to change storage strategy