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

From Michael Paquier
Subject Re: Improper use about DatumGetInt32
Date
Msg-id X/kLBt7Dx+P78+9I@paquier.xyz
Whole thread Raw
In response to Re: Improper use about DatumGetInt32  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Improper use about DatumGetInt32  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Fri, Jan 08, 2021 at 04:54:47PM +0100, Peter Eisentraut wrote:
> Updated patch that does that.

Thanks.  Looks sane seen from here.

+/* 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).

-       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"?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW
Next
From: japin
Date:
Subject: Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW