Re: Terms.

Hey all,

At http://www.postgresql.org/docs/9.0/static/libpq-connect.html
the first sentence is
"The following functions deal with making a connection to a
PostgreSQLbackend server."
Please, change "backend server" to "backend" or "server", as of
at http://www.postgresql.org/docs/9.0/static/protocol.html
written:
"...the terms "backend" and "server" are interchangeable..."

Accuracy - the politeness of kings. :-)

Regards,
Dmitriy

On Fri, Sep 17, 2010 at 3:32 AM, Dmitriy Igrishin <dmitigr(at)gmail(dot)com> wrote:
> At http://www.postgresql.org/docs/9.0/static/libpq-connect.html
> the first sentence is
> "The following functions deal with making a connection to a PostgreSQL
> backend server."
> Please, change "backend server" to "backend" or "server", as of
> at http://www.postgresql.org/docs/9.0/static/protocol.html
> written:
> "...the terms "backend" and "server" are interchangeable..."
>
> Accuracy - the politeness of kings. :-)

Hmm. The existing text might be redundant, but I don't think it's
inaccurate. Since the rest of the section alternates back and forth
between the two terms, it seems like this might help to remind the
reader that they are effectively synonymous.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Hey Robert,

Hmm. The existing text might be redundant, but I don't think it's
> inaccurate. Since the rest of the section alternates back and forth
> between the two terms, it seems like this might help to remind the
> reader that they are effectively synonymous.
>
I am the reader and just a user of libpq, not a guru :-).
I must admit that this is a trifle, but I think it's indeed inaccurate.
Also I think, that it's inaccurate to call one function PQnfields()
and another PQftablecol(). Yes, terms "field" and "column" are
interchangeable, but (personally) I don't clearly understand why two
functions named not monotonous.
But all of the above is my personal point of view. So, just ignore it
if you don't like it :-)

Regards,
Dmitriy

On Fri, Sep 17, 2010 at 3:03 PM, Dmitriy Igrishin <dmitigr(at)gmail(dot)com> wrote:
> I am the reader and just a user of libpq, not a guru :-).
> I must admit that this is a trifle, but I think it's indeed inaccurate.
> Also I think, that it's inaccurate to call one function PQnfields()
> and another PQftablecol(). Yes, terms "field" and "column" are
> interchangeable, but (personally) I don't  clearly understand why two
> functions named not monotonous.

Yeah, the libpq functions have awfully strange names, and I don't even
think you've picked the strangest example. For example, PQftype
returns the type OID, and PQfmod returns the type modifier. Why not
PQftypemodifier or PQftypemod? Unfortunately, we're kind of stuck
with those names at this point, since changing them would break
backward compatibility. I suppose we could add more reasonably named
synonyms and encourage people to use those instead of the old ones,
but I think we'd still end up having to keep the old ones around
approximately forever.

With respect to PQnfields() vs. PQftablecol(), I think the word
"fields" is being used to refer to the columns of the result set, and
the word "columns" to refer to the columns of tables on the server.
So PQftablecol() is actually trying to tell you the number of the
table column where a particular "field" in the results came from.
This is sort of a subtle distinction, though, and the fact that
"field" is being abbreviated to "f" in some but not all cases doesn't
make it any more clear. PQftablecol() is really supposed to mean
"field-table-column" - i.e. look up the table column for this field.
But the name is definitely less than totally self-documenting.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Hey Robert,

2010/9/19 Robert Haas <robertmhaas(at)gmail(dot)com>

> Yeah, the libpq functions have awfully strange names, and I don't even
> think you've picked the strangest example. For example, PQftype
> returns the type OID, and PQfmod returns the type modifier. Why not
> PQftypemodifier or PQftypemod? Unfortunately, we're kind of stuck
> with those names at this point, since changing them would break
> backward compatibility. I suppose we could add more reasonably named
> synonyms and encourage people to use those instead of the old ones,
> but I think we'd still end up having to keep the old ones around
> approximately forever.
>
Unfortunately this is so.

>
> With respect to PQnfields() vs. PQftablecol(), I think the word
> "fields" is being used to refer to the columns of the result set, and
> the word "columns" to refer to the columns of tables on the server.
>
If so, why does the description of PQnfields() at
http://www.postgresql.org/docs/9.0/static/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO
says:
"Returns the number of columns (fields) in each row of the query result."
Furthermore, the description of PQfmod() says:
"Returns the type modifier of the column associated with the given column
number."
So, according the doc, the terms "field" and "column" are interchangeable.

So PQftablecol() is actually trying to tell you the number of the
> table column where a particular "field" in the results came from.
> This is sort of a subtle distinction, though, and the fact that
> "field" is being abbreviated to "f" in some but not all cases doesn't
> make it any more clear. PQftablecol() is really supposed to mean
> "field-table-column" - i.e. look up the table column for this field.
> But the name is definitely less than totally self-documenting.
>
IMO, it would be better if PQftablecol() was named PQtablefield(),
PQfmod() was named PQfieldTypeModifier()() and so on.

IMO, it would be better to only use terms "tuple" and "field" at least in
function naming.

Regards,
Dmitriy Igrishin

Robert Haas wrote:
> With respect to PQnfields() vs. PQftablecol(), I think the word
> "fields" is being used to refer to the columns of the result set, and
> the word "columns" to refer to the columns of tables on the server.
> So PQftablecol() is actually trying to tell you the number of the
> table column where a particular "field" in the results came from.
> This is sort of a subtle distinction, though, and the fact that
> "field" is being abbreviated to "f" in some but not all cases doesn't
> make it any more clear. PQftablecol() is really supposed to mean
> "field-table-column" - i.e. look up the table column for this field.
> But the name is definitely less than totally self-documenting.

FYI, many of these function names date back to Berkeley. Libpq is
called 'libpq' because of the original use of the QUEL query language,
i.e. lib Post-QUEL. We have a proud backward-compatibility history with
this library.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Hey Bruce,

Its interesting indeed, because I always wanted to know why libpq
named "libpq". Thanks!
But I wrote not about libpq functions, I just wanted to say about
unnecessary (IMO) redundancy - the combinations of terms "backend server"
seems to me inaccuracy.

--
Regards,
Dmitriy

Excerpts from Dmitriy Igrishin's message of lun sep 20 15:52:43 -0400 2010:
> Hey Bruce,
>
> Its interesting indeed, because I always wanted to know why libpq
> named "libpq". Thanks!
> But I wrote not about libpq functions, I just wanted to say about
> unnecessary (IMO) redundancy - the combinations of terms "backend server"
> seems to me inaccuracy.

could be, but we're already using that term elsewhere. Maybe we should
consistently use some other term.

$ git grep 'backend server'

doc/src/sgml/libpq.sgml: backend server and to receive the results of these queries.
doc/src/sgml/libpq.sgml: <productname>PostgreSQL</productname> backend server. An
doc/src/sgml/libpq.sgml: server process</><tertiary>in libpq</></> of the backend server
doc/src/sgml/problems.sgml: Here <quote>program</quote> refers to any executable, not only the backend server.
doc/src/sgml/problems.sgml: are specifically talking about the backend server, mention that, do not
doc/src/sgml/problems.sgml: backend server process is quite different from crash of the parent
doc/src/sgml/query.sgml: backend server machine, not the client, since the backend server
doc/src/sgml/ref/pg_ctl-ref.sgml: backend server (<xref linkend="app-postgres">), or displaying the
src/backend/libpq/pqsignal.c: * the frontend commands as well as the backend server.
src/backend/main/main.c: printf(_(" -T send SIGSTOP to all backend servers if one dies\n"));
src/backend/po/de.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/backend/po/es.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/backend/po/fr.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/backend/po/ja.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/backend/po/pt_BR.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/backend/po/tr.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
src/bin/psql/settings.h: int sversion; /* backend server version */
src/test/examples/testlibpq4.c: pghost = NULL; /* host name of the backend server */
src/test/examples/testlibpq4.c: pgport = NULL; /* port of the backend server */
src/test/examples/testlibpq4.c: pgtty = NULL; /* debugging tty for the backend server */

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Excerpts from Dmitriy Igrishin's message of lun sep 20 15:52:43 -0400 2010:
> > Hey Bruce,
> >
> > Its interesting indeed, because I always wanted to know why libpq
> > named "libpq". Thanks!
> > But I wrote not about libpq functions, I just wanted to say about
> > unnecessary (IMO) redundancy - the combinations of terms "backend server"
> > seems to me inaccuracy.
>
> could be, but we're already using that term elsewhere. Maybe we should
> consistently use some other term.
>
>
> $ git grep 'backend server'
>
> doc/src/sgml/libpq.sgml: backend server and to receive the results of these queries.
> doc/src/sgml/libpq.sgml: <productname>PostgreSQL</productname> backend server. An
> doc/src/sgml/libpq.sgml: server process</><tertiary>in libpq</></> of the backend server
> doc/src/sgml/problems.sgml: Here <quote>program</quote> refers to any executable, not only the backend server.
> doc/src/sgml/problems.sgml: are specifically talking about the backend server, mention that, do not
> doc/src/sgml/problems.sgml: backend server process is quite different from crash of the parent
> doc/src/sgml/query.sgml: backend server machine, not the client, since the backend server
> doc/src/sgml/ref/pg_ctl-ref.sgml: backend server (<xref linkend="app-postgres">), or displaying the
> src/backend/libpq/pqsignal.c: * the frontend commands as well as the backend server.
> src/backend/main/main.c: printf(_(" -T send SIGSTOP to all backend servers if one dies\n"));
> src/backend/po/de.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/backend/po/es.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/backend/po/fr.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/backend/po/ja.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/backend/po/pt_BR.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/backend/po/tr.po:msgid " -T send SIGSTOP to all backend servers if one dies\n"
> src/bin/psql/settings.h: int sversion; /* backend server version */
> src/test/examples/testlibpq4.c: pghost = NULL; /* host name of the backend server */
> src/test/examples/testlibpq4.c: pgport = NULL; /* port of the backend server */
> src/test/examples/testlibpq4.c: pgtty = NULL; /* debugging tty for the backend server */

Any ideas on this? Is "backend" better than "backend server"?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

2011/2/20 Bruce Momjian <bruce(at)momjian(dot)us>

> Alvaro Herrera wrote:
> > Excerpts from Dmitriy Igrishin's message of lun sep 20 15:52:43 -0400
> 2010:
> > > Hey Bruce,
> > >
> > > Its interesting indeed, because I always wanted to know why libpq
> > > named "libpq". Thanks!
> > > But I wrote not about libpq functions, I just wanted to say about
> > > unnecessary (IMO) redundancy - the combinations of terms "backend
> server"
> > > seems to me inaccuracy.
> >
> > could be, but we're already using that term elsewhere. Maybe we should
> > consistently use some other term.
> >
> >
> > $ git grep 'backend server'
> >
> > doc/src/sgml/libpq.sgml: backend server and to receive the results of
> these queries.
> > doc/src/sgml/libpq.sgml: <productname>PostgreSQL</productname> backend
> server. An
> > doc/src/sgml/libpq.sgml: server process</><tertiary>in libpq</></>
> of the backend server
> > doc/src/sgml/problems.sgml: Here <quote>program</quote> refers to any
> executable, not only the backend server.
> > doc/src/sgml/problems.sgml: are specifically talking about the backend
> server, mention that, do not
> > doc/src/sgml/problems.sgml: backend server process is quite different
> from crash of the parent
> > doc/src/sgml/query.sgml: backend server machine, not the client, since
> the backend server
> > doc/src/sgml/ref/pg_ctl-ref.sgml: backend server (<xref
> linkend="app-postgres">), or displaying the
> > src/backend/libpq/pqsignal.c: * the frontend commands as well as the
> backend server.
> > src/backend/main/main.c: printf(_(" -T send SIGSTOP to
> all backend servers if one dies\n"));
> > src/backend/po/de.po:msgid " -T send SIGSTOP to all backend
> servers if one dies\n"
> > src/backend/po/es.po:msgid " -T send SIGSTOP to all backend
> servers if one dies\n"
> > src/backend/po/fr.po:msgid " -T send SIGSTOP to all backend
> servers if one dies\n"
> > src/backend/po/ja.po:msgid " -T send SIGSTOP to all backend
> servers if one dies\n"
> > src/backend/po/pt_BR.po:msgid " -T send SIGSTOP to all
> backend servers if one dies\n"
> > src/backend/po/tr.po:msgid " -T send SIGSTOP to all backend
> servers if one dies\n"
> > src/bin/psql/settings.h: int sversion; /* backend server
> version */
> > src/test/examples/testlibpq4.c: pghost = NULL; /* host name
> of the backend server */
> > src/test/examples/testlibpq4.c: pgport = NULL; /* port of
> the backend server */
> > src/test/examples/testlibpq4.c: pgtty = NULL; /* debugging
> tty for the backend server */
>
> Any ideas on this? Is "backend" better than "backend server"?
>
Better, undoubtedly.
Another alternative is just "server". Why? Well, for consistency, e.g. with
http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
Here you may see phrase "All messages emitted by the PostgreSQL server ..."
and furthermore, there are some SQL standard's "SQLSTATE" code
which name includes "server" rather than "backend":
SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
But anyway, phrase "backend server" is incorrect.

>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>

--
// Dmitriy.

Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300 2011:

> Better, undoubtedly.
> Another alternative is just "server". Why? Well, for consistency, e.g. with
> http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> Here you may see phrase "All messages emitted by the PostgreSQL server ..."
> and furthermore, there are some SQL standard's "SQLSTATE" code
> which name includes "server" rather than "backend":
> SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> But anyway, phrase "backend server" is incorrect.

Maybe some cleanup would be good, but in that case please provide a
specific patch. The replacement suggested in the email that started
this thread seems OK, but wholesale replacement of the phrase "backend
server" with something else is likely to introduce as many mistakes as
it would fix. For example, the description of postgres' -T switch would
then be wrong.

I think using the protocol chapter as reference for terms to use is a
bad idea -- it's one of the most obscure chapters in the documentation.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Hey Alvaro,

2011/2/21 Alvaro Herrera <alvherre(at)commandprompt(dot)com>

> Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300 2011:
>
> > Better, undoubtedly.
> > Another alternative is just "server". Why? Well, for consistency, e.g.
> with
> > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> > Here you may see phrase "All messages emitted by the PostgreSQL server
> ..."
> > and furthermore, there are some SQL standard's "SQLSTATE" code
> > which name includes "server" rather than "backend":
> > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> > But anyway, phrase "backend server" is incorrect.
>
> Maybe some cleanup would be good, but in that case please provide a
> specific patch. The replacement suggested in the email that started
> this thread seems OK, but wholesale replacement of the phrase "backend
> server" with something else is likely to introduce as many mistakes as
> it would fix. For example, the description of postgres' -T switch would
> then be wrong.
>
But there is no "backend server" in the postgres(1) man page. Am I wrong?

>
> I think using the protocol chapter as reference for terms to use is a
> bad idea -- it's one of the most obscure chapters in the documentation.
>
Hmm. Why this chapter exists then ? :-)
IMO, mentioned chapter seems to me consistent. But we speak
here about "backend server", which seems to me totally obscure :-)
I think, that "backend" would be better.

>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

--
// Dmitriy.

Alvaro Herrera wrote:
> Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300 2011:
>
> > Better, undoubtedly.
> > Another alternative is just "server". Why? Well, for consistency, e.g. with
> > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> > Here you may see phrase "All messages emitted by the PostgreSQL server ..."
> > and furthermore, there are some SQL standard's "SQLSTATE" code
> > which name includes "server" rather than "backend":
> > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> > But anyway, phrase "backend server" is incorrect.
>
> Maybe some cleanup would be good, but in that case please provide a
> specific patch. The replacement suggested in the email that started
> this thread seems OK, but wholesale replacement of the phrase "backend
> server" with something else is likely to introduce as many mistakes as
> it would fix. For example, the description of postgres' -T switch would
> then be wrong.
>
> I think using the protocol chapter as reference for terms to use is a
> bad idea -- it's one of the most obscure chapters in the documentation.

OK, attached is my proposed patch; it mostly changes "backend server"
to "backend process".

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Excerpts from Bruce Momjian's message of vie mar 11 11:42:58 -0300 2011:
> Alvaro Herrera wrote:
> > Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300 2011:
> >
> > > Better, undoubtedly.
> > > Another alternative is just "server". Why? Well, for consistency, e.g. with
> > > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> > > Here you may see phrase "All messages emitted by the PostgreSQL server ..."
> > > and furthermore, there are some SQL standard's "SQLSTATE" code
> > > which name includes "server" rather than "backend":
> > > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> > > But anyway, phrase "backend server" is incorrect.
> >
> > Maybe some cleanup would be good, but in that case please provide a
> > specific patch. The replacement suggested in the email that started
> > this thread seems OK, but wholesale replacement of the phrase "backend
> > server" with something else is likely to introduce as many mistakes as
> > it would fix. For example, the description of postgres' -T switch would
> > then be wrong.
> >
> > I think using the protocol chapter as reference for terms to use is a
> > bad idea -- it's one of the most obscure chapters in the documentation.
>
> OK, attached is my proposed patch; it mostly changes "backend server"
> to "backend process".

Looks good to me, thanks for the effort.

This whole thread makes me think that we should consider having a
glossary of terms in the docs.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

2011/3/11 Alvaro Herrera <alvherre(at)commandprompt(dot)com>

> Excerpts from Bruce Momjian's message of vie mar 11 11:42:58 -0300 2011:
> > Alvaro Herrera wrote:
> > > Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300
> 2011:
> > >
> > > > Better, undoubtedly.
> > > > Another alternative is just "server". Why? Well, for consistency,
> e.g. with
> > > > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> > > > Here you may see phrase "All messages emitted by the PostgreSQL
> server ..."
> > > > and furthermore, there are some SQL standard's "SQLSTATE" code
> > > > which name includes "server" rather than "backend":
> > > > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> > > > But anyway, phrase "backend server" is incorrect.
> > >
> > > Maybe some cleanup would be good, but in that case please provide a
> > > specific patch. The replacement suggested in the email that started
> > > this thread seems OK, but wholesale replacement of the phrase "backend
> > > server" with something else is likely to introduce as many mistakes as
> > > it would fix. For example, the description of postgres' -T switch
> would
> > > then be wrong.
> > >
> > > I think using the protocol chapter as reference for terms to use is a
> > > bad idea -- it's one of the most obscure chapters in the documentation.
> >
> > OK, attached is my proposed patch; it mostly changes "backend server"
> > to "backend process".
>
> Looks good to me, thanks for the effort.
>
> This whole thread makes me think that we should consider having a
> glossary of terms in the docs.
>
+1.

>
> --
> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
> --
> Sent via pgsql-docs mailing list (pgsql-docs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
>

--
// Dmitriy.

2011/3/11 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>

>
>
> 2011/3/11 Alvaro Herrera <alvherre(at)commandprompt(dot)com>
>
> Excerpts from Bruce Momjian's message of vie mar 11 11:42:58 -0300 2011:
>> > Alvaro Herrera wrote:
>> > > Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300
>> 2011:
>> > >
>> > > > Better, undoubtedly.
>> > > > Another alternative is just "server". Why? Well, for consistency,
>> e.g. with
>> > > > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
>> > > > Here you may see phrase "All messages emitted by the PostgreSQL
>> server ..."
>> > > > and furthermore, there are some SQL standard's "SQLSTATE" code
>> > > > which name includes "server" rather than "backend":
>> > > > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
>> > > > But anyway, phrase "backend server" is incorrect.
>> > >
>> > > Maybe some cleanup would be good, but in that case please provide a
>> > > specific patch. The replacement suggested in the email that started
>> > > this thread seems OK, but wholesale replacement of the phrase "backend
>> > > server" with something else is likely to introduce as many mistakes as
>> > > it would fix. For example, the description of postgres' -T switch
>> would
>> > > then be wrong.
>> > >
>> > > I think using the protocol chapter as reference for terms to use is a
>> > > bad idea -- it's one of the most obscure chapters in the
>> documentation.
>> >
>> > OK, attached is my proposed patch; it mostly changes "backend server"
>> > to "backend process".
>>
>> Looks good to me, thanks for the effort.
>>
>> This whole thread makes me think that we should consider having a
>> glossary of terms in the docs.
>>
> +1.
>
The implementation of this idea can be very helpful especially
for people making translations of the documentation.

>
>> --
>>
>> Álvaro Herrera <alvherre(at)commandprompt(dot)com>
>> The PostgreSQL Company - Command Prompt, Inc.
>> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>>
>> --
>> Sent via pgsql-docs mailing list (pgsql-docs(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-docs
>>
>
>
>
> --
> // Dmitriy.
>
>
>

--
// Dmitriy.

Applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Excerpts from Dmitriy Igrishin's message of dom feb 20 06:19:19 -0300 2011:
> >
> > > Better, undoubtedly.
> > > Another alternative is just "server". Why? Well, for consistency, e.g. with
> > > http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> > > Here you may see phrase "All messages emitted by the PostgreSQL server ..."
> > > and furthermore, there are some SQL standard's "SQLSTATE" code
> > > which name includes "server" rather than "backend":
> > > SQLSERVER REJECTED ESTABLISHMENT OF SQLCONNECTION
> > > But anyway, phrase "backend server" is incorrect.
> >
> > Maybe some cleanup would be good, but in that case please provide a
> > specific patch. The replacement suggested in the email that started
> > this thread seems OK, but wholesale replacement of the phrase "backend
> > server" with something else is likely to introduce as many mistakes as
> > it would fix. For example, the description of postgres' -T switch would
> > then be wrong.
> >
> > I think using the protocol chapter as reference for terms to use is a
> > bad idea -- it's one of the most obscure chapters in the documentation.
>
> OK, attached is my proposed patch; it mostly changes "backend server"
> to "backend process".
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +

[ text/x-diff is unsupported, treating like TEXT/PLAIN ]

> diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
> index 59b4011..1c223cb 100644
> --- a/doc/src/sgml/libpq.sgml
> +++ b/doc/src/sgml/libpq.sgml
> @@ -1612,7 +1612,7 @@ int PQsocket(const PGconn *conn);
> <para>
> Returns the process <acronym>ID</acronym>
> (PID)<indexterm><primary>PID</><secondary>determining PID of
> - server process</><tertiary>in libpq</></> of the backend server
> + server process</><tertiary>in libpq</></> of the backend
> process handling this connection.
>
> <synopsis>
> diff --git a/doc/src/sgml/problems.sgml b/doc/src/sgml/problems.sgml
> index a65baa3..3f79c6e 100644
> --- a/doc/src/sgml/problems.sgml
> +++ b/doc/src/sgml/problems.sgml
> @@ -78,7 +78,7 @@
> </listitem>
> </itemizedlist>
>
> - Here <quote>program</quote> refers to any executable, not only the backend server.
> + Here <quote>program</quote> refers to any executable, not only the backend process.
> </para>
>
> <para>
> @@ -280,9 +280,9 @@
> When writing a bug report, please avoid confusing terminology.
> The software package in total is called <quote>PostgreSQL</quote>,
> sometimes <quote>Postgres</quote> for short. If you
> - are specifically talking about the backend server, mention that, do not
> + are specifically talking about the backend process, mention that, do not
> just say <quote>PostgreSQL crashes</quote>. A crash of a single
> - backend server process is quite different from crash of the parent
> + backend process is quite different from crash of the parent
> <quote>postgres</> process; please don't say <quote>the server
> crashed</> when you mean a single backend process went down, nor vice versa.
> Also, client programs such as the interactive frontend <quote><application>psql</application></quote>
> diff --git a/doc/src/sgml/query.sgml b/doc/src/sgml/query.sgml
> index 681d08a..f4fbf11 100644
> --- a/doc/src/sgml/query.sgml
> +++ b/doc/src/sgml/query.sgml
> @@ -264,8 +264,8 @@ INSERT INTO weather (date, city, temp_hi, temp_lo)
> COPY weather FROM '/home/user/weather.txt';
> </programlisting>
>
> - where the file name for the source file must be available to the
> - backend server machine, not the client, since the backend server
> + where the file name for the source file must be available on the
> + machine running the backend process, not the client, since the backend process
> reads the file directly. You can read more about the
> <command>COPY</command> command in <xref linkend="sql-copy">.
> </para>
> diff --git a/doc/src/sgml/ref/pg_ctl-ref.sgml b/doc/src/sgml/ref/pg_ctl-ref.sgml
> index 608749f..626ed1f 100644
> --- a/doc/src/sgml/ref/pg_ctl-ref.sgml
> +++ b/doc/src/sgml/ref/pg_ctl-ref.sgml
> @@ -134,7 +134,7 @@ PostgreSQL documentation
> <application>pg_ctl</application> is a utility for initializing a
> <productname>PostgreSQL</productname> database cluster, starting,
> stopping, or restarting the <productname>PostgreSQL</productname>
> - backend server (<xref linkend="app-postgres">), or displaying the
> + database server (<xref linkend="app-postgres">), or displaying the
> status of a running server. Although the server can be started
> manually, <application>pg_ctl</application> encapsulates tasks such
> as redirecting log output and properly detaching from the terminal
> diff --git a/src/backend/libpq/pqsignal.c b/src/backend/libpq/pqsignal.c
> index 31e37e9..0fee280 100644
> --- a/src/backend/libpq/pqsignal.c
> +++ b/src/backend/libpq/pqsignal.c
> @@ -22,7 +22,7 @@
> * how to handle signalling.
> *
> * signal(2) handling - this is here because it affects some of
> - * the frontend commands as well as the backend server.
> + * the frontend commands as well as the backend processes.
> *
> * Ultrix and SunOS provide BSD signal(2) semantics by default.
> *
> diff --git a/src/backend/main/main.c b/src/backend/main/main.c
> index 5d07788..43d182b 100644
> --- a/src/backend/main/main.c
> +++ b/src/backend/main/main.c
> @@ -310,7 +310,7 @@ help(const char *progname)
> printf(_(" -O allow system table structure changes\n"));
> printf(_(" -P disable system indexes\n"));
> printf(_(" -t pa|pl|ex show timings after each query\n"));
> - printf(_(" -T send SIGSTOP to all backend servers if one dies\n"));
> + printf(_(" -T send SIGSTOP to all backend processes if one dies\n"));
> printf(_(" -W NUM wait NUM seconds to allow attach from a debugger\n"));
>
> printf(_("\nOptions for single-user mode:\n"));
> diff --git a/src/test/examples/testlibpq4.c b/src/test/examples/testlibpq4.c
> index dafc6ae..0ec0431 100644
> --- a/src/test/examples/testlibpq4.c
> +++ b/src/test/examples/testlibpq4.c
> @@ -72,11 +72,11 @@ main(int argc, char **argv)
> * defaults by looking up environment variables or, failing that, using
> * hardwired constants
> */
> - pghost = NULL; /* host name of the backend server */
> - pgport = NULL; /* port of the backend server */
> + pghost = NULL; /* host name of the backend */
> + pgport = NULL; /* port of the backend */
> pgoptions = NULL; /* special options to start up the backend
> * server */
> - pgtty = NULL; /* debugging tty for the backend server */
> + pgtty = NULL; /* debugging tty for the backend */
>
> /* make a connection to the database */
> conn1 = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName1);

>
> --
> Sent via pgsql-docs mailing list (pgsql-docs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +