public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v29 6/6] Doc: Add Collation Versions section. 2+ messages / 2 participants [nested] [flat]
* [PATCH v29 6/6] Doc: Add Collation Versions section. @ 2020-03-11 02:01 Thomas Munro <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Thomas Munro @ 2020-03-11 02:01 UTC (permalink / raw) Supply a brief introduction to collation version concepts. Author: Thomas Munro <[email protected]> Reviewed-by: Julien Rouhaud <[email protected]> Discussion: https://postgr.es/m/CAEepm%3D0uEQCpfq_%2BLYFBdArCe4Ot98t1aR4eYiYTe%3DyavQygiQ%40mail.gmail.com --- doc/src/sgml/charset.sgml | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml index 4b4563c5b9..12a82ff18c 100644 --- a/doc/src/sgml/charset.sgml +++ b/doc/src/sgml/charset.sgml @@ -948,6 +948,41 @@ CREATE COLLATION ignore_accents (provider = icu, locale = 'und-u-ks-level1-kc-tr </tip> </sect3> </sect2> + + <sect2 id="collation-versions"> + <title>Collation Versions</title> + + <para> + The ordering defined by a collation is not necessarily fixed over time. + If a collation changes for any reason, persistent data structures such as + b-trees that depend on a stable ordering of text might be corrupted. + <productname>PostgreSQL</productname> defends against this by recording + the current version of each referenced collation for any index that + depends on it in the + <link linkend="catalog-pg-depend"><structname>pg_depend</structname></link> + catalog, if the collation provider makes it available. If the provider + later begins to report a different version, a warning will be issued + when the index is accessed, until either the <xref linkend="sql-reindex"/> + or the <xref linkend="sql-alterindex"/> command is used to update the + version. + </para> + <para> + Version information is available for collations from the + <literal>icu</literal> provider on all operating systems. For the + <literal>libc</literal> provider, versions are currently only available + on systems using the GNU C library (most Linux systems). + </para> + + <note> + <para> + When using the GNU C library for collations, the C library's version + is used as a proxy for the collation version. Many Linux distributions + change collation definitions only when upgrading the C library, but this + approach is imperfect as maintainers are free to back-port newer + collation definitions to older C library releases. + </para> + </note> + </sect2> </sect1> <sect1 id="multibyte"> -- 2.20.1 --9jxsPFA5p3P2qPhR-- ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: bug fix and documentation improvement about vacuumdb @ 2023-09-15 02:39 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Kyotaro Horiguchi @ 2023-09-15 02:39 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected]; [email protected] At Thu, 14 Sep 2023 07:57:57 -0700, Nathan Bossart <[email protected]> wrote in > On Thu, Sep 14, 2023 at 02:06:51PM +0200, Daniel Gustafsson wrote: > > I can reproduce that, a single -N works but adding multiple -N's makes none of > > them excluded. The current coding does this: > > > > if (objfilter & OBJFILTER_SCHEMA_EXCLUDE) > > appendPQExpBufferStr(&catalog_query, "OPERATOR(pg_catalog.!=) "); > > > > If the join is instead made to exclude the oids in listed_objects with a left > > join and a clause on object_oid being null I can make the current query work > > without adding a second clause. I don't have strong feelings wrt if we should > > add a NOT IN () or fix this JOIN, but we shouldn't have a faulty join together > > with the fix. With your patch the existing join is left in place, let's fix that. > > Yeah, I think we can fix the JOIN as you suggest. I quickly put a patch > together to demonstrate. We should probably add some tests... It seems to work fine. However, if we're aiming for consistent spacing, the "IS NULL" (two spaces in between) might be an concern. > >> Third, for the description of the -N option, I wonder if "vacuum all tables except > >> in the specified schema(s)" might be clearer. The current one says nothing about > >> tables not in the specified schema. > > > > Maybe, but the point of vacuumdb is to analyze a database so I'm not sure who > > would expect anything else than vacuuming everything but the excluded schema > > when specifying -N. What else could "vacuumdb -N foo" be interpreted to do > > that can be confusing? > > I agree with Daniel on this one. +1. regards. -- Kyotaro Horiguchi NTT Open Source Software Center ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-09-15 02:39 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-03-11 02:01 [PATCH v29 6/6] Doc: Add Collation Versions section. Thomas Munro <[email protected]> 2023-09-15 02:39 Re: bug fix and documentation improvement about vacuumdb Kyotaro Horiguchi <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox