Minor fixes for upcoming version 13

Started by Alexander Lakhinover 5 years ago5 messageshackers
Jump to latest
#1Alexander Lakhin
exclusion@gmail.com

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

Attachments:

minor-fixes.patchtext/x-patch; charset=UTF-8; name=minor-fixes.patchDownload+7-6
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alexander Lakhin (#1)
Re: Minor fixes for upcoming version 13

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

#3Alexander Lakhin
exclusion@gmail.com
In reply to: Tom Lane (#2)
Re: Minor fixes for upcoming version 13

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

#4John Naylor
john.naylor@enterprisedb.com
In reply to: Alexander Lakhin (#3)
Re: Minor fixes for upcoming version 13

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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: John Naylor (#4)
Re: Minor fixes for upcoming version 13

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