mirror of
https://github.com/postgres/postgres.git
synced 2025-07-22 00:01:40 -04:00
Compare commits
10 Commits
b690e5facb
...
151ffcf6d8
Author | SHA1 | Date | |
---|---|---|---|
|
151ffcf6d8 | ||
|
ec63622c03 | ||
|
a237a07d53 | ||
|
d594e0daf7 | ||
|
42d3125ada | ||
|
d391f6dcc3 | ||
|
7751352942 | ||
|
95a610b097 | ||
|
a8510a7d96 | ||
|
39c959ef25 |
@ -73,6 +73,35 @@
|
||||
however; see the <xref linkend="guc-hba-file"/> configuration parameter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>pg_hba.conf</filename> file is read on start-up and when
|
||||
the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the postmaster
|
||||
(using <literal>pg_ctl reload</literal>, calling the SQL function
|
||||
<function>pg_reload_conf()</function>, or using <literal>kill
|
||||
-HUP</literal>) to make it re-read the file.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The preceding statement is not true on Microsoft Windows: there, any
|
||||
changes in the <filename>pg_hba.conf</filename> file are immediately
|
||||
applied by subsequent new connections.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The system view
|
||||
<link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link>
|
||||
can be helpful for pre-testing changes to the <filename>pg_hba.conf</filename>
|
||||
file, or for diagnosing problems if loading of the file did not have the
|
||||
desired effects. Rows in the view with
|
||||
non-null <structfield>error</structfield> fields indicate problems in the
|
||||
corresponding lines of the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The general format of the <filename>pg_hba.conf</filename> file is
|
||||
a set of records, one per line. Blank lines are ignored, as is any
|
||||
@ -733,35 +762,6 @@ openssl x509 -in myclient.crt -noout --subject -nameopt RFC2253 | sed "s/^subjec
|
||||
range of allowed client IP addresses.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>pg_hba.conf</filename> file is read on start-up and when
|
||||
the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the postmaster
|
||||
(using <literal>pg_ctl reload</literal>, calling the SQL function
|
||||
<function>pg_reload_conf()</function>, or using <literal>kill
|
||||
-HUP</literal>) to make it re-read the file.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The preceding statement is not true on Microsoft Windows: there, any
|
||||
changes in the <filename>pg_hba.conf</filename> file are immediately
|
||||
applied by subsequent new connections.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The system view
|
||||
<link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link>
|
||||
can be helpful for pre-testing changes to the <filename>pg_hba.conf</filename>
|
||||
file, or for diagnosing problems if loading of the file did not have the
|
||||
desired effects. Rows in the view with
|
||||
non-null <structfield>error</structfield> fields indicate problems in the
|
||||
corresponding lines of the file.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
To connect to a particular database, a user must not only pass the
|
||||
@ -933,6 +933,28 @@ local db1,db2,@demodbs all md5
|
||||
As for <filename>pg_hba.conf</filename>, the lines in this file can
|
||||
be include directives, following the same rules.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>pg_ident.conf</filename> file is read on start-up and
|
||||
when the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the postmaster
|
||||
(using <literal>pg_ctl reload</literal>, calling the SQL function
|
||||
<function>pg_reload_conf()</function>, or using <literal>kill
|
||||
-HUP</literal>) to make it re-read the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The system view
|
||||
<link linkend="view-pg-ident-file-mappings"><structname>pg_ident_file_mappings</structname></link>
|
||||
can be helpful for pre-testing changes to the
|
||||
<filename>pg_ident.conf</filename> file, or for diagnosing problems if
|
||||
loading of the file did not have the desired effects. Rows in the view with
|
||||
non-null <structfield>error</structfield> fields indicate problems in the
|
||||
corresponding lines of the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is no restriction regarding how many database users a given
|
||||
operating system user can correspond to, nor vice versa. Thus, entries
|
||||
@ -999,27 +1021,6 @@ mymap /^(.*)@otherdomain\.com$ guest
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
The <filename>pg_ident.conf</filename> file is read on start-up and
|
||||
when the main server process receives a
|
||||
<systemitem>SIGHUP</systemitem><indexterm><primary>SIGHUP</primary></indexterm>
|
||||
signal. If you edit the file on an
|
||||
active system, you will need to signal the postmaster
|
||||
(using <literal>pg_ctl reload</literal>, calling the SQL function
|
||||
<function>pg_reload_conf()</function>, or using <literal>kill
|
||||
-HUP</literal>) to make it re-read the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The system view
|
||||
<link linkend="view-pg-ident-file-mappings"><structname>pg_ident_file_mappings</structname></link>
|
||||
can be helpful for pre-testing changes to the
|
||||
<filename>pg_ident.conf</filename> file, or for diagnosing problems if
|
||||
loading of the file did not have the desired effects. Rows in the view with
|
||||
non-null <structfield>error</structfield> fields indicate problems in the
|
||||
corresponding lines of the file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A <filename>pg_ident.conf</filename> file that could be used in
|
||||
conjunction with the <filename>pg_hba.conf</filename> file in <xref
|
||||
|
@ -20288,6 +20288,13 @@ SELECT NULLIF(value, '(none)') ...
|
||||
aggregation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While all aggregates below accept an optional
|
||||
<literal>ORDER BY</literal> clause (as outlined in <xref
|
||||
linkend="syntax-aggregates"/>), the clause has only been added to
|
||||
aggregates whose output is affected by ordering.
|
||||
</para>
|
||||
|
||||
<table id="functions-aggregate-table">
|
||||
<title>General-Purpose Aggregate Functions</title>
|
||||
<tgroup cols="2">
|
||||
@ -20325,7 +20332,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
<indexterm>
|
||||
<primary>array_agg</primary>
|
||||
</indexterm>
|
||||
<function>array_agg</function> ( <type>anynonarray</type> )
|
||||
<function>array_agg</function> ( <type>anynonarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>anyarray</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
@ -20336,7 +20343,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
|
||||
<row>
|
||||
<entry role="func_table_entry"><para role="func_signature">
|
||||
<function>array_agg</function> ( <type>anyarray</type> )
|
||||
<function>array_agg</function> ( <type>anyarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>anyarray</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
@ -20541,14 +20548,14 @@ SELECT NULLIF(value, '(none)') ...
|
||||
<indexterm>
|
||||
<primary>json_agg</primary>
|
||||
</indexterm>
|
||||
<function>json_agg</function> ( <type>anyelement</type> )
|
||||
<function>json_agg</function> ( <type>anyelement</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>json</returnvalue>
|
||||
</para>
|
||||
<para role="func_signature">
|
||||
<indexterm>
|
||||
<primary>jsonb_agg</primary>
|
||||
</indexterm>
|
||||
<function>jsonb_agg</function> ( <type>anyelement</type> )
|
||||
<function>jsonb_agg</function> ( <type>anyelement</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>jsonb</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
@ -20588,7 +20595,8 @@ SELECT NULLIF(value, '(none)') ...
|
||||
</indexterm>
|
||||
<function>json_object_agg</function> ( <parameter>key</parameter>
|
||||
<type>"any"</type>, <parameter>value</parameter>
|
||||
<type>"any"</type> )
|
||||
<type>"any"</type>
|
||||
<literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>json</returnvalue>
|
||||
</para>
|
||||
<para role="func_signature">
|
||||
@ -20597,7 +20605,8 @@ SELECT NULLIF(value, '(none)') ...
|
||||
</indexterm>
|
||||
<function>jsonb_object_agg</function> ( <parameter>key</parameter>
|
||||
<type>"any"</type>, <parameter>value</parameter>
|
||||
<type>"any"</type> )
|
||||
<type>"any"</type>
|
||||
<literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>jsonb</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
@ -20834,7 +20843,8 @@ SELECT NULLIF(value, '(none)') ...
|
||||
</para>
|
||||
<para role="func_signature">
|
||||
<function>string_agg</function> ( <parameter>value</parameter>
|
||||
<type>bytea</type>, <parameter>delimiter</parameter> <type>bytea</type> )
|
||||
<type>bytea</type>, <parameter>delimiter</parameter> <type>bytea</type>
|
||||
<literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>bytea</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
@ -20892,7 +20902,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
<indexterm>
|
||||
<primary>xmlagg</primary>
|
||||
</indexterm>
|
||||
<function>xmlagg</function> ( <type>xml</type> )
|
||||
<function>xmlagg</function> ( <type>xml</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
|
||||
<returnvalue>xml</returnvalue>
|
||||
</para>
|
||||
<para>
|
||||
|
@ -213,6 +213,12 @@ createdb -O <replaceable>rolename</replaceable> <replaceable>dbname</replaceable
|
||||
action being taken when those databases are created.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
However, <command>CREATE DATABASE</command> does not copy database-level
|
||||
<command>GRANT</command> permissions attached to the source database.
|
||||
The new database has default database-level permissions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is a second standard system database named
|
||||
<literal>template0</literal>.<indexterm><primary>template0</primary></indexterm> This
|
||||
|
@ -225,9 +225,10 @@ if docs_dep.found()
|
||||
|
||||
install_doc_man = custom_target('install-man',
|
||||
output: 'install-man',
|
||||
input: man,
|
||||
command: [
|
||||
python, install_files, '--prefix', dir_prefix,
|
||||
'--install-dirs', dir_man, man],
|
||||
'--install-dirs', dir_man, '@INPUT@'],
|
||||
build_always_stale: true, build_by_default: false,
|
||||
)
|
||||
alias_target('install-doc-man', install_doc_man)
|
||||
|
@ -137,7 +137,11 @@ REVOKE [ GRANT OPTION FOR ]
|
||||
<listitem>
|
||||
<para>
|
||||
The name of an existing role of which the current role is a member.
|
||||
If <literal>FOR ROLE</literal> is omitted, the current role is assumed.
|
||||
Default access privileges are not inherited, so member roles
|
||||
must use <command>SET ROLE</command> to access these privileges,
|
||||
or <command>ALTER DEFAULT PRIVILEGES</command> must be run for
|
||||
each member role. If <literal>FOR ROLE</literal> is omitted,
|
||||
the current role is assumed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -59,15 +59,16 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Presently, <literal>ON SELECT</literal> rules must be unconditional
|
||||
<literal>INSTEAD</literal> rules and must have actions that consist
|
||||
of a single <command>SELECT</command> command. Thus, an
|
||||
<literal>ON SELECT</literal> rule effectively turns the table into
|
||||
a view, whose visible contents are the rows returned by the rule's
|
||||
<command>SELECT</command> command rather than whatever had been
|
||||
stored in the table (if anything). It is considered better style
|
||||
to write a <command>CREATE VIEW</command> command than to create a
|
||||
real table and define an <literal>ON SELECT</literal> rule for it.
|
||||
Presently, <literal>ON SELECT</literal> rules can only be attached
|
||||
to views. Such a rule must be named <literal>"_RETURN"</literal>,
|
||||
must be an unconditional <literal>INSTEAD</literal> rule, and must have
|
||||
an action that consists of a single <command>SELECT</command> command.
|
||||
This command defines the visible contents of the view. (The view
|
||||
itself is basically a dummy table with no storage.) It's best to
|
||||
regard such a rule as an implementation detail. While a view can be
|
||||
redefined via <literal>CREATE OR REPLACE RULE "_RETURN" AS
|
||||
...</literal>, it's better style to use <literal>CREATE OR REPLACE
|
||||
VIEW</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1119,6 +1119,10 @@ INSERT INTO tbl1 VALUES ($1, $2) \bind 'first value' 'second value' \g
|
||||
destination, because all data must pass through the client/server
|
||||
connection. For large amounts of data the <acronym>SQL</acronym>
|
||||
command might be preferable.
|
||||
Also, because of this pass-through method, <literal>\copy
|
||||
... from</literal> in <acronym>CSV</acronym> mode will erroneously
|
||||
treat a <literal>\.</literal> data value alone on a line as an
|
||||
end-of-input marker.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
|
@ -1647,7 +1647,20 @@ sqrt(2)
|
||||
are always just expressions and cannot be output-column names or numbers.
|
||||
For example:
|
||||
<programlisting>
|
||||
SELECT array_agg(a ORDER BY b DESC) FROM table;
|
||||
WITH vals (v) AS ( VALUES (1),(3),(4),(3),(2) )
|
||||
SELECT array_agg(v ORDER BY v DESC) FROM vals;
|
||||
array_agg
|
||||
-------------
|
||||
{4,3,3,2,1}
|
||||
</programlisting>
|
||||
Since <type>jsonb</type> only keeps the last matching key, ordering
|
||||
of its keys can be significant:
|
||||
<programlisting>
|
||||
WITH vals (k, v) AS ( VALUES ('key0','1'), ('key1','3'), ('key1','2') )
|
||||
SELECT jsonb_object_agg(k, v ORDER BY v) FROM vals;
|
||||
jsonb_object_agg
|
||||
----------------------------
|
||||
{"key0": "1", "key1": "3"}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
@ -1668,20 +1681,19 @@ SELECT string_agg(a ORDER BY a, ',') FROM table; -- incorrect
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If <literal>DISTINCT</literal> is specified in addition to an
|
||||
<replaceable>order_by_clause</replaceable>, then all the <literal>ORDER BY</literal>
|
||||
expressions must match regular arguments of the aggregate; that is,
|
||||
you cannot sort on an expression that is not included in the
|
||||
<literal>DISTINCT</literal> list.
|
||||
If <literal>DISTINCT</literal> is specified with an
|
||||
<replaceable>order_by_clause</replaceable>, <literal>ORDER
|
||||
BY</literal> expressions can only reference columns in the
|
||||
<literal>DISTINCT</literal> list. For example:
|
||||
<programlisting>
|
||||
WITH vals (v) AS ( VALUES (1),(3),(4),(3),(2) )
|
||||
SELECT array_agg(DISTINCT v ORDER BY v DESC) FROM vals;
|
||||
array_agg
|
||||
-----------
|
||||
{4,3,2,1}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The ability to specify both <literal>DISTINCT</literal> and <literal>ORDER BY</literal>
|
||||
in an aggregate function is a <productname>PostgreSQL</productname> extension.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Placing <literal>ORDER BY</literal> within the aggregate's regular argument
|
||||
list, as described so far, is used when ordering the input rows for
|
||||
|
@ -324,7 +324,7 @@ recurse_set_operations(Node *setOp, PlannerInfo *root,
|
||||
* anyway; otherwise do statistical estimation.
|
||||
*
|
||||
* XXX you don't really want to know about this: we do the estimation
|
||||
* using the subquery's original targetlist expressions, not the
|
||||
* using the subroot->parse's original targetlist expressions, not the
|
||||
* subroot->processed_tlist which might seem more appropriate. The
|
||||
* reason is that if the subquery is itself a setop, it may return a
|
||||
* processed_tlist containing "varno 0" Vars generated by
|
||||
@ -332,6 +332,9 @@ recurse_set_operations(Node *setOp, PlannerInfo *root,
|
||||
* mightily. We ought to get rid of the "varno 0" hack, but that
|
||||
* requires a redesign of the parsetree representation of setops, so
|
||||
* that there can be an RTE corresponding to each setop's output.
|
||||
* Note, we use this not subquery's targetlist but subroot->parse's
|
||||
* targetlist, because it was revised by self-join removal. subquery's
|
||||
* targetlist might contain the references to the removed relids.
|
||||
*/
|
||||
if (pNumGroups)
|
||||
{
|
||||
@ -341,7 +344,7 @@ recurse_set_operations(Node *setOp, PlannerInfo *root,
|
||||
*pNumGroups = subpath->rows;
|
||||
else
|
||||
*pNumGroups = estimate_num_groups(subroot,
|
||||
get_tlist_exprs(subquery->targetList, false),
|
||||
get_tlist_exprs(subroot->parse->targetList, false),
|
||||
subpath->rows,
|
||||
NULL,
|
||||
NULL);
|
||||
|
@ -627,6 +627,8 @@ handleCopyIn(PGconn *conn, FILE *copystream, bool isbinary, PGresult **res)
|
||||
* This code erroneously assumes '\.' on a line alone
|
||||
* inside a quoted CSV string terminates the \copy.
|
||||
* https://www.postgresql.org/message-id/E1TdNVQ-0001ju-GO@wrigleys.postgresql.org
|
||||
*
|
||||
* https://www.postgresql.org/message-id/bfcd57e4-8f23-4c3e-a5db-2571d09208e2@beta.fastmail.com
|
||||
*/
|
||||
if ((linelen == 3 && memcmp(fgresult, "\\.\n", 3) == 0) ||
|
||||
(linelen == 4 && memcmp(fgresult, "\\.\r\n", 4) == 0))
|
||||
|
@ -6759,6 +6759,23 @@ WHERE c3.id=c2.id AND c3.id*c2.id=c1.id*c1.id;
|
||||
Filter: ((id IS NOT NULL) AND ((id * id) IS NOT NULL))
|
||||
(3 rows)
|
||||
|
||||
-- Check the usage of a parse tree by the set operations (bug #18170)
|
||||
explain (costs off)
|
||||
SELECT c1.code FROM emp1 c1 LEFT JOIN emp1 c2 ON c1.id = c2.id
|
||||
WHERE c2.id IS NOT NULL
|
||||
EXCEPT ALL
|
||||
SELECT c3.code FROM emp1 c3;
|
||||
QUERY PLAN
|
||||
----------------------------------------------
|
||||
HashSetOp Except All
|
||||
-> Append
|
||||
-> Subquery Scan on "*SELECT* 1"
|
||||
-> Seq Scan on emp1 c2
|
||||
Filter: (id IS NOT NULL)
|
||||
-> Subquery Scan on "*SELECT* 2"
|
||||
-> Seq Scan on emp1 c3
|
||||
(7 rows)
|
||||
|
||||
-- We can remove the join even if we find the join can't duplicate rows and
|
||||
-- the base quals of each side are different. In the following case we end up
|
||||
-- moving quals over to s1 to make it so it can't match any rows.
|
||||
|
@ -2573,6 +2573,13 @@ explain (costs off)
|
||||
SELECT count(*) FROM emp1 c1, emp1 c2, emp1 c3
|
||||
WHERE c3.id=c2.id AND c3.id*c2.id=c1.id*c1.id;
|
||||
|
||||
-- Check the usage of a parse tree by the set operations (bug #18170)
|
||||
explain (costs off)
|
||||
SELECT c1.code FROM emp1 c1 LEFT JOIN emp1 c2 ON c1.id = c2.id
|
||||
WHERE c2.id IS NOT NULL
|
||||
EXCEPT ALL
|
||||
SELECT c3.code FROM emp1 c3;
|
||||
|
||||
-- We can remove the join even if we find the join can't duplicate rows and
|
||||
-- the base quals of each side are different. In the following case we end up
|
||||
-- moving quals over to s1 to make it so it can't match any rows.
|
||||
|
@ -140,8 +140,8 @@ sub mkvcbuild
|
||||
f2s.c file_perm.c file_utils.c hashfn.c ip.c jsonapi.c
|
||||
keywords.c kwlookup.c link-canary.c md5_common.c percentrepl.c
|
||||
pg_get_line.c pg_lzcompress.c pg_prng.c pgfnames.c psprintf.c relpath.c
|
||||
rmtree.c saslprep.c scram-common.c string.c stringinfo.c unicode_norm.c
|
||||
username.c wait_error.c wchar.c);
|
||||
rmtree.c saslprep.c scram-common.c string.c stringinfo.c
|
||||
unicode_category.c unicode_norm.c username.c wait_error.c wchar.c);
|
||||
|
||||
if ($solution->{options}->{openssl})
|
||||
{
|
||||
|
Loading…
x
Reference in New Issue
Block a user