Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit77055b6

Browse files
committed
Replace PostgreSQL with &productname; (new instances)
1 parent2285393 commit77055b6

27 files changed

+48
-48
lines changed

‎doc/src/sgml/backup.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -933,7 +933,7 @@ SELECT * FROM pg_stop_backup(false);
933933
The process for an exclusive backup is mostly the same as for a
934934
non-exclusive one, but it differs in a few key steps. It does not allow
935935
more than one concurrent backup to run, and there can be some issues on
936-
the server if it crashes during the backup. Prior toPostgreSQL 9.6, this
936+
the server if it crashes during the backup. Prior to&productname; 9.6, this
937937
was the only low-level method available, but it is now recommended that
938938
all users upgrade their scripts to use non-exclusive backups if possible.
939939
</para>

‎doc/src/sgml/bgworker.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -80,7 +80,7 @@ typedef struct BackgroundWorker
8080
<para>
8181
<indexterm><primary>BGWORKER_SHMEM_ACCESS</primary></indexterm>
8282
Requests shared memory access. Workers without shared memory access
83-
cannot access any of <productname>PostgreSQL's</productname> shared
83+
cannot access any of <productname>&productname;'s</productname> shared
8484
data structures, such as heavyweight or lightweight locks, shared
8585
buffers, or any custom data structures which the worker itself may
8686
wish to create and use.

‎doc/src/sgml/catalogs.sgml‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -589,7 +589,7 @@
589589

590590
<note>
591591
<para>
592-
Before <productname>PostgreSQL</> 9.6, <structname>pg_am</structname>
592+
Before <productname>&productname;</> 9.6, <structname>pg_am</structname>
593593
contained many additional columns representing properties of index access
594594
methods. That data is now only directly visible at the C code level.
595595
However, <function>pg_index_column_has_property()</function> and related
@@ -7596,11 +7596,11 @@
75967596
<para>
75977597
The view <structname>pg_config</structname> describes the
75987598
compile-time configuration parameters of the currently installed
7599-
version of <productname>PostgreSQL</>. It is intended, for example, to
7599+
version of <productname>&productname;</>. It is intended, for example, to
76007600
be used by software packages that want to interface to
7601-
<productname>PostgreSQL</> to facilitate finding the required header
7601+
<productname>&productname;</> to facilitate finding the required header
76027602
files and libraries. It provides the same basic information as the
7603-
<xref linkend="app-pgconfig"> <productname>PostgreSQL</> client
7603+
<xref linkend="app-pgconfig"> <productname>&productname;</> client
76047604
application.
76057605
</para>
76067606

‎doc/src/sgml/client-auth.sgml‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1034,7 +1034,7 @@ omicron bryanh guest1
10341034
also used. It is recommended to
10351035
leave <literal>include_realm</literal> set to the default (1) and to
10361036
provide an explicit mapping in <filename>pg_ident.conf</> to convert
1037-
principal names to <productname>PostgreSQL</> user names.
1037+
principal names to <productname>&productname;</> user names.
10381038
</para>
10391039
</listitem>
10401040
</varlistentry>
@@ -1115,7 +1115,7 @@ omicron bryanh guest1
11151115
also used. It is recommended to
11161116
leave <literal>include_realm</literal> set to the default (1) and to
11171117
provide an explicit mapping in <filename>pg_ident.conf</> to convert
1118-
principal names to <productname>PostgreSQL</> user names.
1118+
principal names to <productname>&productname;</> user names.
11191119
</para>
11201120
</listitem>
11211121
</varlistentry>
@@ -1752,16 +1752,16 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
17521752
</para>
17531753

17541754
<para>
1755-
BSD Authentication in <productname>PostgreSQL</> uses
1755+
BSD Authentication in <productname>&productname;</> uses
17561756
the <literal>auth-postgresql</literal> login type and authenticates with
17571757
the <literal>postgresql</literal> login class if that's defined
17581758
in <filename>login.conf</filename>. By default that login class does not
1759-
exist, and <productname>PostgreSQL</> will use the default login class.
1759+
exist, and <productname>&productname;</> will use the default login class.
17601760
</para>
17611761

17621762
<note>
17631763
<para>
1764-
To use BSD Authentication, thePostgreSQL user account (that is, the
1764+
To use BSD Authentication, the&productname; user account (that is, the
17651765
operating system user running the server) must first be added to
17661766
the <literal>auth</literal> group. The <literal>auth</literal> group
17671767
exists by default on OpenBSD systems.

‎doc/src/sgml/config.sgml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3056,7 +3056,7 @@ include_dir 'conf.d'
30563056
<literal>s3</> and <literal>s4</>.
30573057
</para>
30583058
<para>
3059-
The second syntax was used before <productname>PostgreSQL</>
3059+
The second syntax was used before <productname>&productname;</>
30603060
version 9.6 and is still supported. It's the same as the first syntax
30613061
with <replaceable class="parameter">num_sync</replaceable> equal to 1.
30623062
For example, <literal>1 (s1, s2)</> and
@@ -4519,7 +4519,7 @@ local0.* /var/log/postgresql
45194519
determines how messages are delivered to syslog. When on (the
45204520
default), messages are split by lines, and long lines are split so
45214521
that they will fit into 1024 bytes, which is a typical size limit for
4522-
traditional syslog implementations. When off,PostgreSQL server log
4522+
traditional syslog implementations. When off,&productname; server log
45234523
messages are delivered to the syslog service as is, and it is up to
45244524
the syslog service to cope with the potentially bulky messages.
45254525
</para>

‎doc/src/sgml/extend.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -354,7 +354,7 @@
354354
</para>
355355

356356
<para>
357-
<productname>PostgreSQL</> does not currently support extension scripts
357+
<productname>&productname;</> does not currently support extension scripts
358358
issuing <command>CREATE POLICY</command> or <command>SECURITY LABEL</command>
359359
statements. These are expected to be set after the extension has been
360360
created. All RLS policies and security labels on extension objects will be

‎doc/src/sgml/func.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7750,7 +7750,7 @@ SELECT EXTRACT(YEAR FROM TIMESTAMP '2001-02-16 20:38:40');
77507750
+/-Infinity for monotonically-increasing fields (<literal>epoch</>,
77517751
<literal>julian</>, <literal>year</>, <literal>isoyear</>,
77527752
<literal>decade</>, <literal>century</>, and <literal>millennium</>).
7753-
For other fields, NULL is returned. <productname>PostgreSQL</>
7753+
For other fields, NULL is returned. <productname>&productname;</>
77547754
versions before 9.6 returned zero for all cases of infinite input.
77557755
</para>
77567756
</note>

‎doc/src/sgml/indices.sgml‎

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1163,10 +1163,10 @@ CREATE INDEX test1c_content_y_index ON test1c (content COLLATE "y");
11631163
</indexterm>
11641164

11651165
<para>
1166-
All indexes in <productname>PostgreSQL</> are <firstterm>secondary</>
1166+
All indexes in <productname>&productname;</> are <firstterm>secondary</>
11671167
indexes, meaning that each index is stored separately from the table's
11681168
main data area (which is called the table's <firstterm>heap</>
1169-
in <productname>PostgreSQL</> terminology). This means that in an
1169+
in <productname>&productname;</> terminology). This means that in an
11701170
ordinary index scan, each row retrieval requires fetching data from both
11711171
the index and the heap. Furthermore, while the index entries that match a
11721172
given indexable <literal>WHERE</> condition are usually close together in
@@ -1179,7 +1179,7 @@ CREATE INDEX test1c_content_y_index ON test1c (content COLLATE "y");
11791179
</para>
11801180

11811181
<para>
1182-
To solve this performance problem, <productname>PostgreSQL</>
1182+
To solve this performance problem, <productname>&productname;</>
11831183
supports <firstterm>index-only scans</>, which can answer queries from an
11841184
index alone without any heap access. The basic idea is to return values
11851185
directly out of each index entry instead of consulting the associated heap
@@ -1226,14 +1226,14 @@ SELECT x FROM tab WHERE x = 'key' AND z &lt; 42;
12261226
If these two fundamental requirements are met, then all the data values
12271227
required by the query are available from the index, so an index-only scan
12281228
is physically possible. But there is an additional requirement for any
1229-
table scan in <productname>PostgreSQL</>: it must verify that each
1229+
table scan in <productname>&productname;</>: it must verify that each
12301230
retrieved row be <quote>visible</> to the query's MVCC snapshot, as
12311231
discussed in <xref linkend="mvcc">. Visibility information is not stored
12321232
in index entries, only in heap entries; so at first glance it would seem
12331233
that every row retrieval would require a heap access anyway. And this is
12341234
indeed the case, if the table row has been modified recently. However,
12351235
for seldom-changing data there is a way around this
1236-
problem. <productname>PostgreSQL</> tracks, for each page in a table's
1236+
problem. <productname>&productname;</> tracks, for each page in a table's
12371237
heap, whether all rows stored in that page are old enough to be visible to
12381238
all current and future transactions. This information is stored in a bit
12391239
in the table's <firstterm>visibility map</>. An index-only scan, after
@@ -1284,7 +1284,7 @@ SELECT y FROM tab WHERE x = 'key';
12841284
SELECT f(x) FROM tab WHERE f(x) &lt; 1;
12851285
</programlisting>
12861286
as an index-only scan; and this is very attractive if <literal>f()</> is
1287-
an expensive-to-compute function. However, <productname>PostgreSQL</>'s
1287+
an expensive-to-compute function. However, <productname>&productname;</>'s
12881288
planner is currently not very smart about such cases. It considers a
12891289
query to be potentially executable by index-only scan only when
12901290
all <emphasis>columns</> needed by the query are available from the index.
@@ -1300,7 +1300,7 @@ SELECT f(x) FROM tab WHERE f(x) &lt; 1;
13001300
indexable <literal>WHERE</> clauses to the index column. It will usually
13011301
get this right in simple queries such as shown above, but not in queries
13021302
that involve joins. These deficiencies may be remedied in future versions
1303-
of <productname>PostgreSQL</>.
1303+
of <productname>&productname;</>.
13041304
</para>
13051305

13061306
<para>
@@ -1321,7 +1321,7 @@ SELECT target FROM tests WHERE subject = 'some-subject' AND success;
13211321
not need to recheck that part of the <literal>WHERE</> clause at run time:
13221322
all entries found in the index necessarily have <literal>success = true</>
13231323
so this need not be explicitly checked in the
1324-
plan. <productname>PostgreSQL</> versions 9.6 and later will recognize
1324+
plan. <productname>&productname;</> versions 9.6 and later will recognize
13251325
such cases and allow index-only scans to be generated, but older versions
13261326
will not.
13271327
</para>

‎doc/src/sgml/intarray.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -307,7 +307,7 @@ SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
307307
<para>
308308
The source directory <filename>contrib/intarray/bench</> contains a
309309
benchmark test suite, which can be run against an installed
310-
<productname>PostgreSQL</> server. (It also requires <filename>DBD::Pg</>
310+
<productname>&productname;</> server. (It also requires <filename>DBD::Pg</>
311311
to be installed.) To run:
312312
</para>
313313

‎doc/src/sgml/libpq.sgml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2777,7 +2777,7 @@ char *PQresultErrorField(const PGresult *res, int fieldcode);
27772777
<literal>INFO</>, or <literal>LOG</> (in a notice message).
27782778
This is identical to the <symbol>PG_DIAG_SEVERITY</> field except
27792779
that the contents are never localized. This is present only in
2780-
reports generated by <productname>PostgreSQL</> versions 9.6
2780+
reports generated by <productname>&productname;</> versions 9.6
27812781
and later.
27822782
</para>
27832783
</listitem>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp