Обсуждение: fix typos

Recent typos...

On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote:
> Recent typos...

LGTM, thanks.

Here are some others I've been sitting on, mostly in .c files.

-- 
Justin

Op 02-08-2022 om 07:28 schreef John Naylor:
> 
> On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl 
> <mailto:er@xs4all.nl>> wrote:
>  >
>  > Recent typos...
> 
> The part of the sentence inside parentheses is not clear to me, before 
> or after the patch:
> 
>      Dropping an extension causes its component objects, and other 
> explicitly
>      dependent routines (see <xref linkend="sql-alterroutine"/>,
> -   the depends on extension action), to be dropped as well.
> +   that depend on extension action), to be dropped as well.
>     </para>
> 

Hm, I see what you mean, I did not notice that earlier and I won't make 
a guess as to intention.  Maybe Bruce can have another look? (commit 
5fe2d4c56e)


> --
> John Naylor
> EDB: http://www.enterprisedb.com <http://www.enterprisedb.com>

On Tue, Aug 2, 2022 at 4:32 AM Erik Rijkers <er@xs4all.nl> wrote:
> > The part of the sentence inside parentheses is not clear to me, before
> > or after the patch:
> >
> >      Dropping an extension causes its component objects, and other
> > explicitly
> >      dependent routines (see <xref linkend="sql-alterroutine"/>,
> > -   the depends on extension action), to be dropped as well.
> > +   that depend on extension action), to be dropped as well.
> >     </para>
> >
>
> Hm, I see what you mean, I did not notice that earlier and I won't make
> a guess as to intention.  Maybe Bruce can have another look? (commit
> 5fe2d4c56e)

I think that it's talking about this (documented) syntax:

ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
    [ NO ] DEPENDS ON EXTENSION extension_name

So the change from "depends" to "depend" here is incorrect. Maybe we
can say something like:

the <literal>DEPENDS ON EXTENSION
<replaceable>extension_name</replaceable><literal> action

(I haven't tested whether this markup works.)

-- 
Robert Haas
EDB: http://www.enterprisedb.com

John Naylor <john.naylor@enterprisedb.com> writes:
> On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>   ereport(ERROR,
>   (errcode(ERRCODE_OBJECT_IN_USE),
> - errmsg("could not drop replication origin with OID %d, in use by PID %d",
> + errmsg("could not drop replication origin with OID %u, in use by PID %d",

> RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> but it is inconsistent with other uses. So it seems we don't need to
> backpatch this one?

Um ... if it's int16, then it can't be an OID, so I'd say this message has
far worse problems than %d vs %u.  It should not use that terminology.

            regards, tom lane

I wrote:

> On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > John Naylor <john.naylor@enterprisedb.com> writes:
>
> > > RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> > > but it is inconsistent with other uses. So it seems we don't need to
> > > backpatch this one?
> >
> > Um ... if it's int16, then it can't be an OID, so I'd say this message has
> > far worse problems than %d vs %u.  It should not use that terminology.
>
> The catalog has the following. Since it's not a real oid, maybe this column should be rethought?

This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?

> CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId) BKI_SHARED_RELATION
> {
> /*
> * Locally known id that get included into WAL.
> *
> * This should never leave the system.
> *
> * Needs to fit into an uint16, so we don't waste too much space in WAL
> * records. For this reason we don't use a normal Oid column here, since
> * we need to handle allocation of new values manually.
> */
> Oid roident;

-- 
John Naylor
EDB: http://www.enterprisedb.com

This is really a straw-man proposal, since I'm not volunteering to do

the work, or suggest anybody else should do the same. That being the

case, it seems we should just go ahead with Justin's patch for

consistency. Possibly we could also change the messages to say "ID"?

John Naylor <john.naylor@enterprisedb.com> writes:
> This is really a straw-man proposal, since I'm not volunteering to do
> the work, or suggest anybody else should do the same. That being the
> case, it seems we should just go ahead with Justin's patch for
> consistency. Possibly we could also change the messages to say "ID"?

I'd be content if we change the user-facing messages (and documentation
if any) to say "ID" not "OID".

            regards, tom lane

On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Naylor <john.naylor@enterprisedb.com> writes:
> > This is really a straw-man proposal, since I'm not volunteering to do
> > the work, or suggest anybody else should do the same. That being the
> > case, it seems we should just go ahead with Justin's patch for
> > consistency. Possibly we could also change the messages to say "ID"?
>
> I'd be content if we change the user-facing messages (and documentation
> if any) to say "ID" not "OID".

The documentation has both, so it makes sense to standardize on "ID".
The messages all had oid/OID, which I changed in the attached. I think
I got all the places.

I'm thinking it's not wrong enough to confuse people, but consistency
is good, so backpatch to v15 and no further. Does anyone want to make
a case otherwise?

-- 
John Naylor
EDB: http://www.enterprisedb.com

On Tue, Aug 16, 2022 at 8:48 AM John Naylor
<john.naylor@enterprisedb.com> wrote:
>
> On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > John Naylor <john.naylor@enterprisedb.com> writes:
> > > This is really a straw-man proposal, since I'm not volunteering to do
> > > the work, or suggest anybody else should do the same. That being the
> > > case, it seems we should just go ahead with Justin's patch for
> > > consistency. Possibly we could also change the messages to say "ID"?
> >
> > I'd be content if we change the user-facing messages (and documentation
> > if any) to say "ID" not "OID".
>
> The documentation has both, so it makes sense to standardize on "ID".
> The messages all had oid/OID, which I changed in the attached. I think
> I got all the places.
>
> I'm thinking it's not wrong enough to confuse people, but consistency
> is good, so backpatch to v15 and no further. Does anyone want to make
> a case otherwise?

This is done.

-- 
John Naylor
EDB: http://www.enterprisedb.com