Compare commits

...

4 Commits

Author SHA1 Message Date
Bruce Momjian
930bc76bec doc: \copy can get data values \. and end-of-input confused
Reported-by: Svante Richter

Discussion: https://postgr.es/m/fcd57e4-8f23-4c3e-a5db-2571d09208e2@beta.fastmail.com

Backpatch-through: 11
2023-11-03 13:57:58 -04:00
Bruce Momjian
54af107cb1 doc: CREATE DATABASE doesn't copy db-level perms. from template
Reported-by: david@kapitaltrading.com

Discussion: https://postgr.es/m/166007719137.995877.13951579839074751714@wrigleys.postgresql.org

Backpatch-through: 11
2023-11-03 13:39:50 -04:00
Tom Lane
3f9fe9b76f Doc: update CREATE RULE ref page's hoary discussion of views.
This text left one with the impression that an ON SELECT rule could
be attached to a plain table, which has not been true since commit
264c06820 (meaning the text was already misleading when written,
evidently by me in 96bd67f61).  However, it didn't get really bad
until b23cd185f removed the convert-a-table-to-a-view logic, which
had made it possible for scripts that thought they were attaching
ON SELECTs to tables to still work.

Rewrite into a form that makes it clear that an ON SELECT rule
is better regarded as an implementation detail of a view.
Pre-v16, point out that adding ON SELECT to a table actually
converts it to a view.

Per bug #18178 from Joshua Uyehara.  Back-patch to all supported
branches.

Discussion: https://postgr.es/m/18178-05534d7064044d2d@postgresql.org
2023-11-03 11:48:23 -04:00
Bruce Momjian
272db03bb9 doc: ALTER DEFAULT PRIVILEGES does not affect inherited roles
Reported-by: Jordi Gutiérrez Hermoso

Discussion: https://postgr.es/m/72652d72e1816bfc3c05d40f9e0e0373d07823c8.camel@octave.org

Co-authored-by: Laurenz Albe

Backpatch-through: 11
2023-11-03 09:51:52 -04:00
5 changed files with 27 additions and 10 deletions

View File

@ -207,6 +207,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

View File

@ -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>

View File

@ -59,15 +59,17 @@ 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. (Attaching one to a table converts the table into a view.)
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>

View File

@ -1060,6 +1060,10 @@ testdb=&gt;
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>

View File

@ -633,6 +633,7 @@ 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.
* http://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 (strcmp(buf, "\\.\n") == 0 ||
strcmp(buf, "\\.\r\n") == 0)