Re: Portal->commandTag as an enum

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Portal->commandTag as an enum
Date: 2020-02-21 08:53:27
Message-ID: CACPNZCvSsdvQifqDkVLRb5jC2_yd3xu1OH+kAHWKXc5m7UsPsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thinking about this some more, would it be possible to treat these
like we do parser/kwlist.h? Something like this:

commandtag_list.h:
PG_COMMANDTAG(ALTER_ACCESS_METHOD, "ALTER ACCESS METHOD", true, false,
false, false)
...

then, just:

#define PG_COMMANDTAG(taglabel, tagname, event_trigger, table_rewrite,
display_rowcount, display_oid) label,

typedef enum CommandTag
{
#include "commandtag_list.h"
}

#undef PG_COMMANDTAG

...and then:

#define PG_COMMANDTAG(taglabel, tagname, event_trigger, table_rewrite,
display_rowcount, display_oid) \
{ tagname, event_trigger, table_rewrite, display_rowcount, display_oid },

const CommandTagBehavior tag_behavior[] =
{
#include "commandtag_list.h"
}

#undef PG_COMMANDTAG

I'm hand-waving a bit, and it doesn't have the flexibility of a .dat
file, but it's a whole lot simpler.

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-02-21 09:09:38 Re: backend type in log_line_prefix?
Previous Message Kyotaro Horiguchi 2020-02-21 08:37:15 Re: [Patch] Make pg_checksums skip foreign tablespace directories