mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-28 14:57:20 +02:00
doc: more replacement of <literal> with something better
Reported-by: Alexander Law Author: Alexander Law Backpatch-through: 9.6
This commit is contained in:
parent
616be05dfe
commit
1414d490f7
@ -1227,8 +1227,8 @@ include_dir 'conf.d'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If this is on, you should create users as <literal>username@dbname</>.
|
||||
When <literal>username</> is passed by a connecting client,
|
||||
If this is on, you should create users as <replaceable>username@dbname</>.
|
||||
When <replaceable>username</> is passed by a connecting client,
|
||||
<literal>@</> and the database name are appended to the user
|
||||
name and that database-specific user name is looked up by the
|
||||
server. Note that when you create users with names containing
|
||||
|
@ -13737,7 +13737,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
|
||||
<entry>No</entry>
|
||||
<entry>
|
||||
multiple continuous percentile: returns an array of results matching
|
||||
the shape of the <literal>fractions</literal> parameter, with each
|
||||
the shape of the <replaceable>fractions</replaceable> parameter, with each
|
||||
non-null element replaced by the value corresponding to that percentile
|
||||
</entry>
|
||||
</row>
|
||||
@ -13782,7 +13782,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
|
||||
<entry>No</entry>
|
||||
<entry>
|
||||
multiple discrete percentile: returns an array of results matching the
|
||||
shape of the <literal>fractions</literal> parameter, with each non-null
|
||||
shape of the <replaceable>fractions</replaceable> parameter, with each non-null
|
||||
element replaced by the input value corresponding to that percentile
|
||||
</entry>
|
||||
</row>
|
||||
@ -16787,7 +16787,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
<para>
|
||||
<function>pg_options_to_table</function> returns the set of storage
|
||||
option name/value pairs
|
||||
(<literal>option_name</>/<literal>option_value</>) when passed
|
||||
(<replaceable>option_name</>/<replaceable>option_value</>) when passed
|
||||
<structname>pg_class</>.<structfield>reloptions</> or
|
||||
<structname>pg_attribute</>.<structfield>attoptions</>.
|
||||
</para>
|
||||
|
@ -349,7 +349,7 @@ END;
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The standard's <literal>AS <data type></literal> expression is not
|
||||
The standard's <literal>AS <replaceable>data_type</></literal> expression is not
|
||||
supported.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -127,7 +127,7 @@ SELECT SESSION_USER, CURRENT_USER;
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname>
|
||||
allows identifier syntax (<literal>"rolename"</literal>), while
|
||||
allows identifier syntax (<literal>"<replaceable>rolename</>"</literal>), while
|
||||
the SQL standard requires the role name to be written as a string
|
||||
literal. SQL does not allow this command during a transaction;
|
||||
<productname>PostgreSQL</productname> does not make this
|
||||
|
@ -101,7 +101,7 @@ SELECT SESSION_USER, CURRENT_USER;
|
||||
The SQL standard allows some other expressions to appear in place
|
||||
of the literal <replaceable>user_name</replaceable>, but these options
|
||||
are not important in practice. <productname>PostgreSQL</productname>
|
||||
allows identifier syntax (<literal>"username"</literal>), which SQL
|
||||
allows identifier syntax (<literal>"<replaceable>username</>"</literal>), which SQL
|
||||
does not. SQL does not allow this command during a transaction;
|
||||
<productname>PostgreSQL</productname> does not make this
|
||||
restriction because there is no reason to.
|
||||
|
@ -3622,10 +3622,10 @@ SELECT plainto_tsquery('supernovae stars');
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The optional parameter <literal>PATTERN</literal> can be the name of
|
||||
The optional parameter <replaceable>PATTERN</replaceable> can be the name of
|
||||
a text search object, optionally schema-qualified. If
|
||||
<literal>PATTERN</literal> is omitted then information about all
|
||||
visible objects will be displayed. <literal>PATTERN</literal> can be a
|
||||
<replaceable>PATTERN</replaceable> is omitted then information about all
|
||||
visible objects will be displayed. <replaceable>PATTERN</replaceable> can be a
|
||||
regular expression and can provide <emphasis>separate</emphasis> patterns
|
||||
for the schema and object names. The following examples illustrate this:
|
||||
|
||||
|
@ -204,8 +204,8 @@ SELECT clean_emp();
|
||||
|
||||
<para>
|
||||
If an argument is of a composite type, then the dot notation,
|
||||
e.g., <literal>argname.fieldname</literal> or
|
||||
<literal>$1.fieldname</literal>, can be used to access attributes of the
|
||||
e.g., <literal><replaceable>argname</>.<replaceable>fieldname</></literal> or
|
||||
<literal>$1.<replaceable>fieldname</></literal>, can be used to access attributes of the
|
||||
argument. Again, you might need to qualify the argument's name with the
|
||||
function name to make the form with an argument name unambiguous.
|
||||
</para>
|
||||
@ -527,7 +527,8 @@ LINE 1: SELECT new_emp().name;
|
||||
Another option is to use
|
||||
functional notation for extracting an attribute. The simple way
|
||||
to explain this is that we can use the
|
||||
notations <literal>attribute(table)</> and <literal>table.attribute</>
|
||||
notations <literal><replaceable>attribute</>(<replaceable>table</>)</>
|
||||
and <literal><replaceable>table</>.<replaceable>attribute</></>
|
||||
interchangeably.
|
||||
|
||||
<screen>
|
||||
@ -1305,12 +1306,15 @@ CREATE FUNCTION test(smallint, double precision) RETURNS ...
|
||||
<para>
|
||||
A function that takes a single argument of a composite type should
|
||||
generally not have the same name as any attribute (field) of that type.
|
||||
Recall that <literal>attribute(table)</literal> is considered equivalent
|
||||
to <literal>table.attribute</literal>. In the case that there is an
|
||||
Recall that <literal><replaceable>attribute</>(<replaceable>table</>)</literal>
|
||||
is considered equivalent
|
||||
to <literal><replaceable>table</>.<replaceable>attribute</></literal>.
|
||||
In the case that there is an
|
||||
ambiguity between a function on a composite type and an attribute of
|
||||
the composite type, the attribute will always be used. It is possible
|
||||
to override that choice by schema-qualifying the function name
|
||||
(that is, <literal>schema.func(table)</literal>) but it's better to
|
||||
(that is, <literal><replaceable>schema</>.<replaceable>func</>(<replaceable>table</>)
|
||||
</literal>) but it's better to
|
||||
avoid the problem by not choosing conflicting names.
|
||||
</para>
|
||||
|
||||
@ -2818,7 +2822,7 @@ HeapTuple heap_form_tuple(TupleDesc tupdesc, Datum *values, bool *isnull)
|
||||
HeapTuple BuildTupleFromCStrings(AttInMetadata *attinmeta, char **values)
|
||||
</programlisting>
|
||||
to build a <structname>HeapTuple</> given user data
|
||||
in C string form. <literal>values</literal> is an array of C strings,
|
||||
in C string form. <parameter>values</parameter> is an array of C strings,
|
||||
one for each attribute of the return row. Each C string should be in
|
||||
the form expected by the input function of the attribute data
|
||||
type. In order to return a null value for one of the attributes,
|
||||
|
Loading…
Reference in New Issue
Block a user