Mark Dilger <mark.dil...@enterprisedb.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