Thread: 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
Attachment
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