Re: Portal->commandTag as an enum

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> I put the CommandTag enum in src/common because there wasn’t any reason
> not to do so. It seems plausible that frontend test frameworks might want
> access to this enum.

Au contraire, that's an absolutely fundamental mistake. There is
zero chance of this enum holding still across PG versions, so if
we expose it to frontend code, we're going to have big problems
with cross-version compatibility. See our historical problems with
assuming the enum for character set encodings was the same between
frontend and backend ... and that set is orders of magnitude more
stable than this one.

As I recall, the hardest problem with de-string-ifying this is the fact
that for certain tags we include a rowcount in the string. I'd like to
see that undone --- we have to keep it like that on-the-wire to avoid a
protocol break, but it'd be best if noplace inside the backend did it that
way, and we converted at the last moment before sending a CommandComplete
to the client. Your references to "completion tags" make it sound like
you've only half done the conversion (though I've not read the patch
in enough detail to verify).

BTW, the size of the patch is rather depressing, especially if it's
only half done. Unlike Andres, I'm not even a little bit convinced
that this is worth the amount of code churn it'll cause. Have you
done any code-size or speed comparisons?

regards, tom lane