I wrote: > Looking at parse.pl, I guess it's probably triggered by some > unconventional use of ERRCODE_FEATURE_NOT_SUPPORTED in your > gram.y changes.
Oh, no, it's parse.pl that is at fault. It's doing this: if (/ERRCODE_FEATURE_NOT_SUPPORTED/) { $feature_not_supported = 1; next line; } ... later ... if ($feature_not_supported == 1) { # we found an unsupported feature, but we have to # filter out ExecuteStmt: CREATE OptTemp TABLE ... # because the warning there is only valid in some situations if ($flds->[0] ne 'create' || $flds->[2] ne 'table') { add_to_buffer('rules', 'mmerror(PARSE_ERROR, ET_WARNING, "unsupported feature will be passed to server");' ); } $feature_not_supported = 0; } In English, if a production in gram.y contains the string ERRCODE_FEATURE_NOT_SUPPORTED anywhere, then the ecpg parser will be made to spit out this warning when it reduces that same production. This works great for cases like | UNENCRYPTED PASSWORD Sconst { ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("UNENCRYPTED PASSWORD is no longer supported"), errhint("Remove UNENCRYPTED to store the password in encrypted form instead."), parser_errposition(@1))); } but not well at all if the error is conditional, as it is in the json_table production. The cowboy hack for CREATE OptTemp TABLE was evidently meant to suppress what must have been the only conditional FEATURE_NOT_SUPPORTED rule at the time, but it doesn't look like that matches anything at all anymore. If you look through the generated preproc.y file you'll find quite a few of these that are being reported inappropriately; I'm surprised that it hasn't come up before. We need to either nuke that ecpg warning entirely, or find a more robust way of detecting whether the gram.y complaint is conditional. I'll put a brown paper bag on my head before suggesting that maybe we could pay attention to how far the errcode is indented. Perhaps a slightly nicer way is to assume it's conditional if any earlier line in the rule starts with "if". regards, tom lane