Обсуждение: Minor fixes for upcoming version 13

Hello hackers,

Please consider fixing minor defects in the source code and documentation.
1. a missing dot in guc.c
"SELECT name, short_desc FROM pg_settings WHERE short_desc NOT LIKE
'%.'" finds only this one instance.
2. inrange -> in_range
the former spelling is unique
3. sigature -> signature
4. "start timeline %u not found history of timeline %u" -> "start
timeline %u not found in history of timeline %u"
it seems that a preposition is missing
5. <type>BackgroundWorker *worker</type> -> <parameter>BackgroundWorker
*worker</parameter>
incorrect Docbook tag
6. "unhandled previous state in xqs" -> "unhandled previous state at end
quote"?
"xqs" is rather cryptic for a user-visible message

I'm not sure about 6, so the attached patch covers only 1-5.

Best regards,
Alexander

Alexander Lakhin <exclusion@gmail.com> writes:
> Please consider fixing minor defects in the source code and documentation.

I agree with all of these, except the markup fixes in bgworker.sgml
still seem not right; it should be more like

  <function>RegisterBackgroundWorker(<type>BackgroundWorker</type> *<parameter>worker</parameter>)</function>

> 6. "unhandled previous state in xqs" -> "unhandled previous state at end
> quote"?
> "xqs" is rather cryptic for a user-visible message

But it's not user-visible is it?  That should surely be a can't-happen
case.

Will push in a little bit.

            regards, tom lane

Hello Tom,

09.09.2020 18:29, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> Please consider fixing minor defects in the source code and documentation.
> I agree with all of these, except the markup fixes in bgworker.sgml
> still seem not right; it should be more like
>
>   <function>RegisterBackgroundWorker(<type>BackgroundWorker</type> *<parameter>worker</parameter>)</function>
Yes, but I've tried to minimize the change and align with the adjacent
text. For example:
<para>Once running, the process can connect to a database by calling
   <function>BackgroundWorkerInitializeConnection(<parameter>char
*dbname</parameter>...
>> 6. "unhandled previous state in xqs" -> "unhandled previous state at end
>> quote"?
>> "xqs" is rather cryptic for a user-visible message
> But it's not user-visible is it?  That should surely be a can't-happen
> case.
I've encountered this while translating NLS messages in postgres.po and
ecpg.po. So I think it should at least puzzle translators.

Best regards,
Alexander

On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> Hello Tom,
>
> 09.09.2020 18:29, Tom Lane wrote:
> > But it's not user-visible is it?  That should surely be a can't-happen
> > case.
> I've encountered this while translating NLS messages in postgres.po and
> ecpg.po. So I think it should at least puzzle translators.

Maybe instead Assert(0) with a comment or something like that?

-- 
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

John Naylor <john.naylor@2ndquadrant.com> writes:
> On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>> 09.09.2020 18:29, Tom Lane wrote:
>>> But it's not user-visible is it?  That should surely be a can't-happen
>>> case.

>> I've encountered this while translating NLS messages in postgres.po and
>> ecpg.po. So I think it should at least puzzle translators.

> Maybe instead Assert(0) with a comment or something like that?

Maybe what we need is yyerror_internal() for messages that don't require
translation.  Or just convert it to a plain elog(ERROR) ... that would
lose the possibility of providing an error cursor, but that seems like
something we don't need here either.

            regards, tom lane