> On Feb 28, 2020, at 3:05 PM, Tom Lane <[email protected]> wrote: > > Alvaro Herrera <[email protected]> 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 whether you want a rowcount and/or lastoid are orthogonal issues. We already have problems with there being different commandtags for different versions of morally the same commands. Take for example "SELECT FOR KEY SHARE" vs. "SELECT FOR NO KEY UPDATE" vs. "SELECT FOR SHARE" vs. "SELECT FOR UPDATE". — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Mark Dilger
- Re: Portal->commandTag as an enum John Naylor
- Re: Portal->commandTag as an enum John Naylor
- Re: Portal->commandTag as an enum John Naylor
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Tom Lane
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Mark Dilger
- Re: Portal->commandTag as an enum Tom Lane
- Re: Portal->commandTag as an enum Mark Dilger
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Mark Dilger
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Mark Dilger
- Re: Portal->commandTag as an enum Alvaro Herrera
- Re: Portal->commandTag as an enum Mark Dilger
