Re: pgsql: Add basic JSON_TABLE() functionality

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