Re: Portal->commandTag as an enum
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
John Naylor <john.naylor@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-02T17:17:29Z
Lists: pgsql-hackers
> On Mar 2, 2020, at 9:08 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > On 2020-Mar-02, Alvaro Herrera wrote: > >> Here's the patch I propose for commit. I also rewrote the commit >> message. > > BTW I wonder if we should really change the definition of > EventTriggerData. ISTM that it would be sensible to keep it the same > for now ... I think it is more natural to change event trigger code to reason natively about CommandTags rather than continuing to reason about strings. The conversion back-and-forth between the enum and the string representation serves no useful purpose that I can see. But I understand if you are just trying to have the patch change fewer parts of the code, and if you feel more comfortable about reverting that part of the patch, as the committer, I think that's your prerogative. Did you want to do that yourself, or have me do it and resubmit? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Update comment
- b234b567ed74 13.0 landed
-
Represent command completion tags as structs
- 2f9661311b83 13.0 landed