Re: Improper use about DatumGetInt32
От | Peter Eisentraut |
---|---|
Тема | Re: Improper use about DatumGetInt32 |
Дата | |
Msg-id | e6330583-4276-8742-1f8a-9f5464f97f8a@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Improper use about DatumGetInt32 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Improper use about DatumGetInt32
|
Список | 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 по дате отправления: