mirror of
https://github.com/postgres/postgres.git
synced 2025-09-11 00:12:06 +03:00
0413a55699
A child table can specify a compression or storage method different from its parents. This was previously an error. (But this was inconsistently enforced because for example the settings could be changed later using ALTER TABLE.) This now also allows an explicit override if multiple parents have different compression or storage settings, which was previously an error that could not be overridden. The compression and storage properties remains unchanged in a child inheriting from parent(s) after its creation, i.e., when using ALTER TABLE ... INHERIT. (This is not changed.) Before this change, the error detail would mention the first pair of conflicting parent compression or storage methods. But with this change it waits till the child specification is considered by which time we may have encountered many such conflicting pairs. Hence the error detail after this change does not include the conflicting compression/storage methods. Those can be obtained from parent definitions if necessary. The code to maintain list of all conflicting methods or even the first conflicting pair does not seem worth the convenience it offers. This change is inline with what we do with conflicting default values. Before this commit, the specified storage method could be stored in ColumnDef::storage (CREATE TABLE ... LIKE) or ColumnDef::storage_name (CREATE TABLE ...). This caused the MergeChildAttribute() and MergeInheritedAttribute() to ignore a storage method specified in the child definition since it looked only at ColumnDef::storage. This commit removes ColumnDef::storage and instead uses ColumnDef::storage_name to save any storage method specification. This is similar to how compression method specification is handled. Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/24656cec-d6ef-4d15-8b5b-e8dfc9c833a7@eisentraut.org
<!-- doc/src/sgml/README.links -->
Linking within DocBook documents can be confusing, so here is a summary:
Intra-document Linking
----------------------
<xref>
use to get chapter/section number from the title of the target
link, or xreflabel if defined at the target, or refentrytitle if target
is a refentry; has no close tag
http://www.oasis-open.org/docbook/documentation/reference/html/xref.html
linkend=
controls the target of the link/xref, required
endterm=
for <xref>, allows the text of the link/xref to be taken from a
different link target title
<link>
use to supply text for the link, only uses linkend, requires </link>
http://www.oasis-open.org/docbook/documentation/reference/html/link.html
can be embedded inside of <command>, unlike <xref>
External Linking
----------------
<ulink>
like <link>, but uses a URL (not a document target); requires
</ulink>; if no text is specified, the URL appears as the link
text
http://www.oasis-open.org/docbook/documentation/reference/html/ulink.html
url=
used by <ulink> to specify the URL, required
Guidelines
----------
- For an internal link, if you want to supply text, use <link>, else
<xref>.
- Specific nouns like GUC variables, SQL commands, and contrib modules
usually have xreflabels.
- For an external link, use <ulink>, with or without link text.
- xreflabels added to tags prevent the chapter/section for id's from being
referenced; only the xreflabel is accessible. Therefore, use xreflabels
only when linking is common, and chapter/section information is unneeded.