Re: Improper use about DatumGetInt32 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Improper use about DatumGetInt32
Date
Msg-id e6330583-4276-8742-1f8a-9f5464f97f8a@enterprisedb.com
Whole thread Raw
In response to Re: Improper use about DatumGetInt32  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improper use about DatumGetInt32
List pgsql-hackers
On 2021-01-09 02:46, Michael Paquier wrote:
> +/* LCOV_EXCL_START */
> Does it really make sense to add those markers here?  It seems to me
> that we would ignore any new coverage if regression tests based on
> older versions are added (we may really want to have such tests for
> more in-core extensions to be able to verify the portability of an
> extension, but that's not the job of this patch of course).

If we had a way to do such testing then we wouldn't need these markers. 
But AFAICT, we don't.

> -       elog(ERROR, "block 0 is a meta page");
> +       ereport(ERROR,
> +               (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +                errmsg("block 0 is a meta page")));
> [...]
> +                errmsg("block number %llu is out of range for relation \"%s\"",
> This does not follow the usual style for error reports that should not
> be written as full sentences?  Maybe something like "invalid block
> number %u referring to meta page" and "block number out of range for
> relation %s: %llu"?

There are many error messages that say "[something] is out of range".  I 
don't think banning that would serve any purpose.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: youichi aramaki
Date:
Subject: Re: Add table access method as an option to pgbench