Re: Improve the HINT message of the ALTER command for postgres_fdw - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Improve the HINT message of the ALTER command for postgres_fdw
Date
Msg-id 33141684-a9bd-aea8-e05c-2826411c70fd@oss.nttdata.com
Whole thread Raw
In response to Re: Improve the HINT message of the ALTER command for postgres_fdw  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Improve the HINT message of the ALTER command for postgres_fdw
Re: Improve the HINT message of the ALTER command for postgres_fdw
List pgsql-hackers

On 2021/10/16 19:43, Bharath Rupireddy wrote:
> I'm fine with the distinction that's made, now I'm thinking about the
> appropriate areas where ERRCODE_FDW_INVALID_OPTION_NAME can be used.
> Is it correct to use ERRCODE_FDW_INVALID_OPTION_NAME in
> postgresImportForeignSchema where we don't check buffer length and
> option name length but throw the error when we don't find what's being
> expected for IMPORT FOREIGN SCHEMA command? Isn't it the
> ERRCODE_FDW_OPTION_NAME_NOT_FOUND right choice there? I've seen some
> of the option parsing logic(with the search text "stmt->options)" in
> the code base), they are mostly using "option \"%s\" not recognized"
> without an error code or "unrecognized XXXX option \"%s\"" with
> ERRCODE_SYNTAX_ERROR. I'm not sure which is right. If not in
> postgresImportForeignSchema, where else can
> ERRCODE_FDW_INVALID_OPTION_NAME be used?

These are good questions. But TBH I don't know the answers and have not
found good articles describing more detail definitions of those error codes.
I'm tempted to improve the HINT message part at first because it has
obviously an issue. And then we can consider what error code should be
used in FDW layer if necessary.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Next
From: Michael Paquier
Date:
Subject: Re: pg_receivewal starting position