documentation structure
Started by Robert Haasalmost 2 years ago94 messages
I was looking at the documentation index this morning[1]https://www.postgresql.org/docs/16/index.html, and I can't
help feeling like there are some parts of it that are over-emphasized
and some parts that are under-emphasized. I'm not sure what we can do
about this exactly, but I thought it worth writing an email and seeing
what other people think.
The two sections of the documentation that seem really
under-emphasized to me are the GUC documentation and the SQL
reference. The GUC documentation is all buried under "20. Server
Configuration" and the SQL command reference is under "I. SQL
commands". For reasons that I don't understand, all chapters except
for those in "VI. Reference" are numbered, but the chapters in that
section have Roman numerals instead.
I don't know what other people's experience is, but for me, wanting to
know what a command does or what a setting does is extremely common.
Therefore, I think these chapters are disproportionately important and
should be emphasized more. In the case of the GUC reference, one idea
I have is to split up "III. Server Administration". My proposal is
that we divide it into three sections. The first would be called "III.
Server Installation" and would cover chapters 16 (installation from
binaries) through 19 (server setup and operation). The second would be
called "IV. Server Configuration" -- so every section that's currently
a subsection of "server configuration" would become a top-level
chapter. The third division would be "V. Server Administration," and
would cover the current chapters 21-33. This is probably far from
perfect, but it seems like a relatively simple change and better than
what we have now.
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.
The stuff that I think is over-emphasized is as follows: (a) chapters
1-3, the tutorial; (b) chapters 4-6, which are essentially a
continuation of the tutorial, and not at all similar to chapters 8-11
which are chalk-full of detailed technical information; (c) chapters
43-46, one per procedural language; perhaps these could just be
demoted to sub-sections of chapter 42 on procedural languages; (d)
chapters 47 (server programming interface), 50 (replication progress
tracking), and 51 (archive modules), all of which are important to
document but none of which seem important enough to put them in the
top-level documentation index; and (e) large parts of section "VII.
Internals," which again contain tons of stuff of very marginal
interest. The first ~4 chapters of the internals section seem like
they might be mainstream enough to justify the level of prominence
that we give them, but the rest has got to be of interest to a tiny
minority of readers.
I think it might be possible to consolidate the internals section by
grouping a bunch of existing entries together by category. Basically,
after the first few chapters, you've got stuff that is of interest to
C programmers writing core or extension code; and you've got
explainers on things like GEQO and index op-classes and support
functions which might be of interest even to non-programmers. I think
for example that we don't need separate top-level chapters on writing
procedural language handlers, FDWs, tablesample methods, custom scan
providers, table access methods, index access methods, and WAL
resource managers. Some or all of those could be grouped under a
single chapter, perhaps, e.g. Using PostgreSQL Extensibility
Interfaces.
Thoughts? I realize that this topic is HIGHLY prone to ENDLESS
bikeshedding, and it's inevitable that not everybody is going to
agree. But I hope we can agree that it's completely silly that it's
vastly easier to find the documentation about the backup manifest
format than it is to find the documentation on CREATE TABLE or
shared_buffers, and if we can agree on that, then perhaps we can agree
on some way to make things better.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Mon, 18 Mar 2024 at 15:12, Robert Haas <robertmhaas@gmail.com> wrote:
I'm not going into detail about the other docs comments, I don't have
much of an opinion either way on the mentioned sections. You make good
arguments; yet I don't usually use those sections of the docs but
rather do code searches.
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.
Could "SQL Commands" be a top-level construct, with subsections for
SQL/DML, SQL/DDL, SQL/Transaction management, and PG's
extensions/administrative/misc features? I sometimes find myself
trying to mentally organize what SQL commands users can use vs those
accessible to database owners and administrators, which is not
currently organized as such in the SQL Commands section.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
Re: documentation structure
On Mon, Mar 18, 2024 at 10:55 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.Could "SQL Commands" be a top-level construct, with subsections for
SQL/DML, SQL/DDL, SQL/Transaction management, and PG's
extensions/administrative/misc features? I sometimes find myself
trying to mentally organize what SQL commands users can use vs those
accessible to database owners and administrators, which is not
currently organized as such in the SQL Commands section.
Yeah, I wondered about that, too. Or for example you could group all
CREATE commands together, all ALTER commands together, all DROP
commands together, etc. But I can't really see a future in such
schemes, because having a single page that links to the reference
documentation for every single command we have in alphabetical order
is incredibly handy, or at least I have found it so. So my feeling -
at least at present - is that it's more fruitful to look into cutting
down the amount of clutter that appears in the top-level documentation
index, and maybe finding ways to make important sections like the SQL
reference more prominent.
Given how much documentation we have, it's just not going to be
possible to make everything that matters conveniently visible at the
top level. I think if people have to click down a level for the SQL
reference, that's fine, as long as the link they need to click on is
reasonably visible. What annoys me about the present structure is that
it isn't. You don't get any visual clue that the "SQL Commands" page
with ~100 subpages is more important than "51. Archive Modules" or
"33. Regression Tests" or "58. Writing a Procedural Language Handler,"
but it totally is.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Mon, Mar 18, 2024 at 10:12 AM Robert Haas <robertmhaas@gmail.com> wrote:
I was looking at the documentation index this morning[1], and I can't
help feeling like there are some parts of it that are over-emphasized
and some parts that are under-emphasized. I'm not sure what we can do
about this exactly, but I thought it worth writing an email and seeing
what other people think.
I agree, and my usage patterns of the docs are similar.
As the project progresses and more features are added and tacked on to
existing docs, things can get
murky or buried. I imagine that web access and search logs could paint a
picture of documentation usage.
I don't know what other people's experience is, but for me, wanting to
know what a command does or what a setting does is extremely common.
Therefore, I think these chapters are disproportionately important and
should be emphasized more. In the case of the GUC reference, one idea
+1
I have is to split up "III. Server Administration". My proposal is
that we divide it into three sections. The first would be called "III.
Server Installation" and would cover chapters 16 (installation from
binaries) through 19 (server setup and operation). The second would be
called "IV. Server Configuration" -- so every section that's currently
a subsection of "server configuration" would become a top-level
chapter. The third division would be "V. Server Administration," and
would cover the current chapters 21-33. This is probably far from
I like all of those.
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.
I think it'd be easier to read if current "VI. Reference" came right after
"Server Administration",
ahead of "Client Interfaces" and "Server Programming", which are of
interest to a much smaller
subset of users.
Also if the subchapters were numbered like the rest of them. I don't think
the roman numerals are
particularly helpful.
The stuff that I think is over-emphasized is as follows: (a) chapters
1-3, the tutorial; (b) chapters 4-6, which are essentially a
...
Also +1
Thoughts? I realize that this topic is HIGHLY prone to ENDLESS
bikeshedding, and it's inevitable that not everybody is going to
agree. But I hope we can agree that it's completely silly that it's
vastly easier to find the documentation about the backup manifest
format than it is to find the documentation on CREATE TABLE or
shared_buffers, and if we can agree on that, then perhaps we can agree
on some way to make things better.
Impossible to please everyone, but I'm sure we can improve things.
I've contributed to different parts of the docs over the years, and would
be happy
to help with this work.
Roberto
Re: documentation structure
On Mon, 2024-03-18 at 10:11 -0400, Robert Haas wrote:
The two sections of the documentation that seem really
under-emphasized to me are the GUC documentation and the SQL
reference. The GUC documentation is all buried under "20. Server
Configuration" and the SQL command reference is under "I. SQL
commands". For reasons that I don't understand, all chapters except
for those in "VI. Reference" are numbered, but the chapters in that
section have Roman numerals instead.
That last fact is very odd indeed and could be easily fixed.
I don't know what other people's experience is, but for me, wanting to
know what a command does or what a setting does is extremely common.
Therefore, I think these chapters are disproportionately important and
should be emphasized more. In the case of the GUC reference, one idea
I have is to split up "III. Server Administration". My proposal is
that we divide it into three sections. The first would be called "III.
Server Installation" and would cover chapters 16 (installation from
binaries) through 19 (server setup and operation). The second would be
called "IV. Server Configuration" -- so every section that's currently
a subsection of "server configuration" would become a top-level
chapter. The third division would be "V. Server Administration," and
would cover the current chapters 21-33. This is probably far from
perfect, but it seems like a relatively simple change and better than
what we have now.
I'm fine with splitting up "Server Administration" into three sections
like you propose.
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.
I think that both the GUCs and the SQL reference could be top-level
sections. For the GUCs there is an obvious split in sub-chapters,
and the SQL reference could be a top-level section without any chapters
under it.
The stuff that I think is over-emphasized is as follows: (a) chapters
1-3, the tutorial; (b) chapters 4-6, which are essentially a
continuation of the tutorial, and not at all similar to chapters 8-11
which are chalk-full of detailed technical information; (c) chapters
43-46, one per procedural language; perhaps these could just be
demoted to sub-sections of chapter 42 on procedural languages; (d)
chapters 47 (server programming interface), 50 (replication progress
tracking), and 51 (archive modules), all of which are important to
document but none of which seem important enough to put them in the
top-level documentation index; and (e) large parts of section "VII.
Internals," which again contain tons of stuff of very marginal
interest. The first ~4 chapters of the internals section seem like
they might be mainstream enough to justify the level of prominence
that we give them, but the rest has got to be of interest to a tiny
minority of readers.
I disagree that the tutorial is over-emphasized.
I also disagree that chapters 4 to 6 are a continuation of the tutorial.
Or at least, they shouldn't be.
When I am looking for a documentation reference on something like
security considerations of SECURITY DEFINER functions, my first
impulse is to look in chapter 5 (Data Definition) or in chapter 38
(Extending SQL), and I am surprised to find it discussed in the
SQL reference of CREATE FUNCTION.
Another case in point is the "Notes" section for CREATE VIEW. Why is
that not somewhere under "Data Definition"?
For me, the reference should be terse and focused on the syntax.
Changing that is probably a lost cause by now, but I feel that we need
not encourage that development any more by playing down the earlier
chapters.
I think it might be possible to consolidate the internals section by
grouping a bunch of existing entries together by category. Basically,
after the first few chapters, you've got stuff that is of interest to
C programmers writing core or extension code; and you've got
explainers on things like GEQO and index op-classes and support
functions which might be of interest even to non-programmers. I think
for example that we don't need separate top-level chapters on writing
procedural language handlers, FDWs, tablesample methods, custom scan
providers, table access methods, index access methods, and WAL
resource managers. Some or all of those could be grouped under a
single chapter, perhaps, e.g. Using PostgreSQL Extensibility
Interfaces.
I have no strong feelings about that.
Yours,
Laurenz Albe
Re: documentation structure
Laurenz Albe <laurenz.albe@cybertec.at> writes:
On Mon, 2024-03-18 at 10:11 -0400, Robert Haas wrote:
I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.
I think that both the GUCs and the SQL reference could be top-level
sections. For the GUCs there is an obvious split in sub-chapters,
and the SQL reference could be a top-level section without any chapters
under it.
I'd be in favor of promoting all three of the "Reference" things to
the top level, except that as Robert says, it seems likely that that
would end in having a hundred individual command reference pages
visible in the topmost table of contents. Also, if we manage to
suppress that, did we really make it any more prominent? Not sure.
Making "SQL commands" top-level with half a dozen subsections would
solve the visibility problem, but I'm not real eager to go there,
because I foresee endless arguments about which subsection a given
command goes in. Robert's point about wanting a single alphabetized
list is valid too (although you could imagine that being a list in an
introductory section, similar to what we have for system catalogs).
This might be a silly suggestion, but: could we just render the
"most important" chapter titles in a larger font?
regards, tom lane
Re: documentation structure
On Mon, Mar 18, 2024 at 6:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
This might be a silly suggestion, but: could we just render the
"most important" chapter titles in a larger font?
It's not the silliest suggestion ever -- you could have proposed
<blink>! -- but I also suspect it's not the right answer. Of course,
varying the font size can be a great way of emphasizing some things
more than others, but it doesn't usually work out well to just take a
document that was designed to be displayed in a uniform font size and
enlarge bits of text here and there. You usually want to have some
kind of overall plan of which font size is a single component.
For example, on a corporate home page, it's quite common to have two
nav bars, the larger of which has entries that correspond to the
company's product offerings and/or marketing materials, and the
smaller of which has "utility functions" like "login", "contact us",
and "search". Font size can be an effective tool for emphasizing the
relative importance of one nav bar versus the other, but you don't
start by deciding which things are going to get displayed in a larger
font. You start with an overall idea of the layout and then the font
size flows out of that.
Just riffing a bit, you could imagine adding a nav bar to our
documentation, either across the top or along the side, that is always
there on every page of the documentation and contains those links that
we want to make sure are always visible. Necessarily, these must be
limited in number. Then on the home page you could have the whole
table of contents as we do today, and you use that to navigate to
everything that isn't one of the quick links.
Or you can imagine that the home page of our documentation isn't just
a tree view like it is today; it might instead be written in paragraph
form. "Welcome to the PostgreSQL documentation! If you're new here,
check out our <link>tutorial</link>! Otherwise, you might be
interested in our <link>SQL reference</link>, our <link>configuration
reference</link>, or our <link>banana plantation</link>. If none of
those sound like what you want, check out the <link>documentation
index</link>." Obviously in order to actually work, something like
this would need to be expanded into enough paragraphs to actually
cover all of the important sections of the documentation, and probably
not mention banana plantations. Or maybe it wouldn't be just
paragraphs, but a two-column table, with each row of the table having
a main title and link in the narrower lefthand column and a blurb with
more links in the wider righthand column.
I'm sure there are a lot of other ways to do this, too. Our main
documentation page is very old-school, and there are probably a bunch
of ways to do better.
But I'm not sure how easy it would be to get agreement on something
specific, and I don't know how well our toolchain can support anything
other than what we've already got. I've also learned from painful
experience that you can't fix bad content with good markup. I think it
is worth spending some effort on trying to beat the existing format
into submission, promoting things that seem to deserve it and demoting
those that seem to deserve that. At some point, we'll probably reach a
point of diminishing returns, either because we all agree we've done
as well as we can, or because we can't agree on what else to do, and
maybe at that point the only way to improve further is with better web
design and/or a different documentation toolchain. But I think it's
fairly clear that we're not at that point now.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On 18 Mar 2024, at 22:40, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Mon, 2024-03-18 at 10:11 -0400, Robert Haas wrote:
For reasons that I don't understand, all chapters except
for those in "VI. Reference" are numbered, but the chapters in that
section have Roman numerals instead.That last fact is very odd indeed and could be easily fixed.
It's actually not very odd, the reference section is using <reference> elements
and we had missed the arabic numerals setting on those. The attached fixes
that for me. That being said, we've had roman numerals for the reference
section since forever (all the way down to the 7.2 docs online has it) so maybe
it was intentional? Or no one managed to see it until Robert did, I've
certainly never noticed it until now.
--
Daniel Gustafsson
Attachments:
reference-autolabel.diffapplication/octet-stream; name=reference-autolabel.diff; x-unix-mode=0644Download
diff --git a/doc/src/sgml/stylesheet-common.xsl b/doc/src/sgml/stylesheet-common.xsl
index a2e3db67a3..319c92e8ab 100644
--- a/doc/src/sgml/stylesheet-common.xsl
+++ b/doc/src/sgml/stylesheet-common.xsl
@@ -35,6 +35,7 @@
<xsl:param name="section.label.includes.component.label" select="1"></xsl:param>
<xsl:param name="refentry.generate.name" select="0"></xsl:param>
<xsl:param name="refentry.generate.title" select="1"></xsl:param>
+<xsl:param name="reference.autolabel" select="1"></xsl:param>
<xsl:param name="refentry.xref.manvolnum" select="0"/>
<xsl:param name="formal.procedures" select="0"></xsl:param>
<xsl:param name="generate.consistent.ids" select="1"/>
Re: documentation structure
Daniel Gustafsson <daniel@yesql.se> writes:
It's actually not very odd, the reference section is using <reference> elements
and we had missed the arabic numerals setting on those. The attached fixes
that for me. That being said, we've had roman numerals for the reference
section since forever (all the way down to the 7.2 docs online has it) so maybe
it was intentional?
I'm quite sure it *was* intentional. Maybe it was a bad idea, but
it's not that way simply because nobody thought about it.
regards, tom lane
Re: documentation structure
On Mon, Mar 18, 2024 at 10:12 AM Robert Haas <robertmhaas@gmail.com> wrote:
I was looking at the documentation index this morning[1], and I can't
help feeling like there are some parts of it that are over-emphasized
and some parts that are under-emphasized. I'm not sure what we can do
about this exactly, but I thought it worth writing an email and seeing
what other people think.The two sections of the documentation that seem really
under-emphasized to me are the GUC documentation and the SQL
reference. The GUC documentation is all buried under "20. Server
Configuration" and the SQL command reference is under "I. SQL
commands". For reasons that I don't understand, all chapters except
for those in "VI. Reference" are numbered, but the chapters in that
section have Roman numerals instead.I don't know what other people's experience is, but for me, wanting to
know what a command does or what a setting does is extremely common.
Therefore, I think these chapters are disproportionately important and
should be emphasized more. In the case of the GUC reference, one idea
I have is to split up "III. Server Administration". My proposal is
that we divide it into three sections. The first would be called "III.
Server Installation" and would cover chapters 16 (installation from
binaries) through 19 (server setup and operation). The second would be
called "IV. Server Configuration" -- so every section that's currently
a subsection of "server configuration" would become a top-level
chapter. The third division would be "V. Server Administration," and
would cover the current chapters 21-33. This is probably far from
perfect, but it seems like a relatively simple change and better than
what we have now.I don't know what to do about "I. SQL commands". It's obviously
impractical to promote that to a top-level section, because it's got a
zillion sub-pages which I don't think we want in the top-level
documentation index. But having it as one of several unnumbered
chapters interposed between 51 and 52 doesn't seem great either.The stuff that I think is over-emphasized is as follows: (a) chapters
1-3, the tutorial; (b) chapters 4-6, which are essentially a
continuation of the tutorial, and not at all similar to chapters 8-11
which are chalk-full of detailed technical information; (c) chapters
43-46, one per procedural language; perhaps these could just be
demoted to sub-sections of chapter 42 on procedural languages; (d)
chapters 47 (server programming interface), 50 (replication progress
tracking), and 51 (archive modules), all of which are important to
document but none of which seem important enough to put them in the
top-level documentation index; and (e) large parts of section "VII.
Internals," which again contain tons of stuff of very marginal
interest. The first ~4 chapters of the internals section seem like
they might be mainstream enough to justify the level of prominence
that we give them, but the rest has got to be of interest to a tiny
minority of readers.I think it might be possible to consolidate the internals section by
grouping a bunch of existing entries together by category. Basically,
after the first few chapters, you've got stuff that is of interest to
C programmers writing core or extension code; and you've got
explainers on things like GEQO and index op-classes and support
functions which might be of interest even to non-programmers. I think
for example that we don't need separate top-level chapters on writing
procedural language handlers, FDWs, tablesample methods, custom scan
providers, table access methods, index access methods, and WAL
resource managers. Some or all of those could be grouped under a
single chapter, perhaps, e.g. Using PostgreSQL Extensibility
Interfaces.Thoughts? I realize that this topic is HIGHLY prone to ENDLESS
bikeshedding, and it's inevitable that not everybody is going to
agree. But I hope we can agree that it's completely silly that it's
vastly easier to find the documentation about the backup manifest
format than it is to find the documentation on CREATE TABLE or
shared_buffers, and if we can agree on that, then perhaps we can agree
on some way to make things better.
+many for improving the index.
My own pet docs peeve is a purely editorial one: func.sgml is a 30k line
beast, and I think there's a good case for splitting out at least the
larger chunks of it.
cheers
andrew
Re: documentation structure
On Mon, Mar 18, 2024 at 5:40 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
I also disagree that chapters 4 to 6 are a continuation of the tutorial.
Or at least, they shouldn't be.
When I am looking for a documentation reference on something like
security considerations of SECURITY DEFINER functions, my first
impulse is to look in chapter 5 (Data Definition) or in chapter 38
(Extending SQL), and I am surprised to find it discussed in the
SQL reference of CREATE FUNCTION.
I looked at this a bit more closely. There's actually a lot of
detailed technical information in chapters 4 and 5, but chapter 6 is
extremely short and mostly recapitulates chapter 2.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Tue, Mar 19, 2024 at 5:39 PM Andrew Dunstan <andrew@dunslane.net> wrote:
+many for improving the index.
Here's a series of four patches. Taken together, they cut down the
number of numbered chapters from 76 to 68. I think we could easily
save that much again if I wrote a few more patches along similar
lines, but I'm posting these first to see what people think.
0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from Source Code" chapter and retitled it
"Installation".
0002 removes the "Monitoring Disk Usage" chapter by folding it into
the immediately-preceding "Monitoring Database Activity" chapter. I
kind of feel like the "Monitoring Disk Usage" chapter might be in need
of a bigger rewrite or just outright removal, but there's surely not
enough content here to justify making it a top-level chapter.
0003 merges all of the "Internals" chapters whose names are the names
of built-in index access methods (Btree, Gin, etc.) into a single
chapter called "Built-In Index Access Methods". All of these chapters
have a very similar structure and none of them are very long, so it
makes a lot of sense, at least in my mind, to consolidate them into
one.
0004 merges the "Generic WAL Records" and "Custom WAL Resource
Managers" chapter together, creating a new chapter called "Write Ahead
Logging for Extensions".
Overall, I think this achieves a minor but pleasant level of
de-cluttering of the index. It's going to take a lot more than one
morning's work to produce a major improvement, but at least this is
something.
--
Robert Haas
EDB: http://www.enterprisedb.com
Attachments:
v1-0001-docs-Remove-the-Installation-from-Binaries-chapte.patchapplication/octet-stream; name=v1-0001-docs-Remove-the-Installation-from-Binaries-chapte.patchDownload
From ec645d3429006b0f7c693a6d65f1dc196264e0a1 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 10:08:05 -0400
Subject: [PATCH v1 1/4] docs: Remove the "Installation from Binaries" chapter.
The entire chapter was four sentences. Move the most useful
information from those sentences to the "Installation from Source
Code" chapter, and rename that to just "Installation".
---
doc/src/sgml/filelist.sgml | 1 -
doc/src/sgml/install-binaries.sgml | 24 ------------------------
doc/src/sgml/installation.sgml | 23 +++++++++++++++++------
doc/src/sgml/postgres.sgml | 1 -
4 files changed, 17 insertions(+), 32 deletions(-)
delete mode 100644 doc/src/sgml/install-binaries.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index e0dca81cb2..b7d1222e3e 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -36,7 +36,6 @@
<!ENTITY client-auth SYSTEM "client-auth.sgml">
<!ENTITY diskusage SYSTEM "diskusage.sgml">
<!ENTITY high-availability SYSTEM "high-availability.sgml">
-<!ENTITY installbin SYSTEM "install-binaries.sgml">
<!ENTITY installation SYSTEM "installation.sgml">
<!ENTITY targets-meson SYSTEM "targets-meson.sgml">
<!ENTITY maintenance SYSTEM "maintenance.sgml">
diff --git a/doc/src/sgml/install-binaries.sgml b/doc/src/sgml/install-binaries.sgml
deleted file mode 100644
index 001c3c7be0..0000000000
--- a/doc/src/sgml/install-binaries.sgml
+++ /dev/null
@@ -1,24 +0,0 @@
-<!-- doc/src/sgml/install-binaries.sgml -->
-<chapter id="install-binaries">
- <title>Installation from Binaries</title>
-
- <indexterm>
- <primary>installation</primary>
- <secondary>binaries</secondary>
- </indexterm>
-
- <para>
- <productname>PostgreSQL</productname> is available in the form of binary
- packages for most common operating systems today. When available, this is
- the recommended way to install PostgreSQL for users of the system. Building
- from source (see <xref linkend="installation" />) is only recommended for
- people developing <productname>PostgreSQL</productname> or extensions.
- </para>
-
- <para>
- For an updated list of platforms providing binary packages, please visit
- the download section on the <productname>PostgreSQL</productname> website at
- <ulink url="https://www.postgresql.org/download/"></ulink> and follow the
- instructions for the specific platform.
- </para>
-</chapter>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index a453f804cd..7b2e6786f4 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -1,18 +1,29 @@
<!-- doc/src/sgml/installation.sgml -->
<chapter id="installation">
- <title>Installation from Source Code</title>
+ <title>Installation</title>
<indexterm zone="installation">
<primary>installation</primary>
</indexterm>
<para>
- This chapter describes the installation of
- <productname>PostgreSQL</productname> using the source code
- distribution. If you are installing a pre-packaged distribution,
- such as an RPM or Debian package, ignore this chapter
- and see <xref linkend="install-binaries" /> instead.
+ Since <productname>PostgreSQL</productname> is available in the form of
+ binary packages for most common operating systems today, it is typically not
+ necessary to build from source.
+ </para>
+
+ <para>
+ For an updated list of platforms providing binary packages, please visit
+ the download section on the <productname>PostgreSQL</productname> website at
+ <ulink url="https://www.postgresql.org/download/"></ulink> and follow the
+ instructions for the specific platform.
+ </para>
+
+ <para>
+ If you wish to compile from source code, for example to develop
+ <productname>PostgreSQL</productname> or an extension, the following
+ sections explain how to do this.
</para>
<sect1 id="install-requirements">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 2c107199d3..7c234ff1db 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -150,7 +150,6 @@ break is not needed in a wider output rendering.
</para>
</partintro>
- &installbin;
&installation;
&runtime;
&config;
--
2.39.3 (Apple Git-145)
v1-0002-docs-Demote-Monitoring-Disk-Usage-from-chapter-to.patchapplication/octet-stream; name=v1-0002-docs-Demote-Monitoring-Disk-Usage-from-chapter-to.patchDownload
From 756789a3b8f3b8ae609851e18f365bb5863f6f7a Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 10:52:16 -0400
Subject: [PATCH v1 2/4] docs: Demote "Monitoring Disk Usage" from chapter to
section.
This chapter is very short, and the immediately preceding chapter is
called "Monitoring Database Activity". So, instead of having a
separate chapter for this, make it the last section of the preceding
chapter instead.
---
doc/src/sgml/diskusage.sgml | 144 -----------------------------------
doc/src/sgml/filelist.sgml | 1 -
doc/src/sgml/monitoring.sgml | 143 ++++++++++++++++++++++++++++++++++
doc/src/sgml/postgres.sgml | 1 -
4 files changed, 143 insertions(+), 146 deletions(-)
delete mode 100644 doc/src/sgml/diskusage.sgml
diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
deleted file mode 100644
index 75467582e4..0000000000
--- a/doc/src/sgml/diskusage.sgml
+++ /dev/null
@@ -1,144 +0,0 @@
-<!-- doc/src/sgml/diskusage.sgml -->
-
-<chapter id="diskusage">
- <title>Monitoring Disk Usage</title>
-
- <para>
- This chapter discusses how to monitor the disk usage of a
- <productname>PostgreSQL</productname> database system.
- </para>
-
- <sect1 id="disk-usage">
- <title>Determining Disk Usage</title>
-
- <indexterm zone="disk-usage">
- <primary>disk usage</primary>
- </indexterm>
-
- <para>
- Each table has a primary heap disk file where most of the data is
- stored. If the table has any columns with potentially-wide values,
- there also might be a <acronym>TOAST</acronym> file associated with the table,
- which is used to store values too wide to fit comfortably in the main
- table (see <xref linkend="storage-toast"/>). There will be one valid index
- on the <acronym>TOAST</acronym> table, if present. There also might be indexes
- associated with the base table. Each table and index is stored in a
- separate disk file — possibly more than one file, if the file would
- exceed one gigabyte. Naming conventions for these files are described
- in <xref linkend="storage-file-layout"/>.
- </para>
-
- <para>
- You can monitor disk space in three ways:
- using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
- using the <xref linkend="oid2name"/> module, or
- using manual inspection of the system catalogs.
- The SQL functions are the easiest to use and are generally recommended.
- The remainder of this section shows how to do it by inspection of the
- system catalogs.
- </para>
-
- <para>
- Using <application>psql</application> on a recently vacuumed or analyzed database,
- you can issue queries to see the disk usage of any table:
-<programlisting>
-SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
-
- pg_relation_filepath | relpages
-----------------------+----------
- base/16384/16806 | 60
-(1 row)
-</programlisting>
- Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
- is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
- a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
- is of interest if you want to examine the table's disk file directly.
- </para>
-
- <para>
- To show the space used by <acronym>TOAST</acronym> tables, use a query
- like the following:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class,
- (SELECT reltoastrelid
- FROM pg_class
- WHERE relname = 'customer') AS ss
-WHERE oid = ss.reltoastrelid OR
- oid = (SELECT indexrelid
- FROM pg_index
- WHERE indrelid = ss.reltoastrelid)
-ORDER BY relname;
-
- relname | relpages
-----------------------+----------
- pg_toast_16806 | 0
- pg_toast_16806_index | 1
-</programlisting>
- </para>
-
- <para>
- You can easily display index sizes, too:
-<programlisting>
-SELECT c2.relname, c2.relpages
-FROM pg_class c, pg_class c2, pg_index i
-WHERE c.relname = 'customer' AND
- c.oid = i.indrelid AND
- c2.oid = i.indexrelid
-ORDER BY c2.relname;
-
- relname | relpages
--------------------+----------
- customer_id_index | 26
-</programlisting>
- </para>
-
- <para>
- It is easy to find your largest tables and indexes using this
- information:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class
-ORDER BY relpages DESC;
-
- relname | relpages
-----------------------+----------
- bigtable | 3290
- customer | 3144
-</programlisting>
- </para>
- </sect1>
-
- <sect1 id="disk-full">
- <title>Disk Full Failure</title>
-
- <para>
- The most important disk monitoring task of a database administrator
- is to make sure the disk doesn't become full. A filled data disk will
- not result in data corruption, but it might prevent useful activity
- from occurring. If the disk holding the WAL files grows full, database
- server panic and consequent shutdown might occur.
- </para>
-
- <para>
- If you cannot free up additional space on the disk by deleting
- other things, you can move some of the database files to other file
- systems by making use of tablespaces. See <xref
- linkend="manage-ag-tablespaces"/> for more information about that.
- </para>
-
- <tip>
- <para>
- Some file systems perform badly when they are almost full, so do
- not wait until the disk is completely full to take action.
- </para>
- </tip>
-
- <para>
- If your system supports per-user disk quotas, then the database
- will naturally be subject to whatever quota is placed on the user
- the server runs as. Exceeding the quota will have the same bad
- effects as running out of disk space entirely.
- </para>
- </sect1>
-</chapter>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index b7d1222e3e..f39b4efe38 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -34,7 +34,6 @@
<!ENTITY backup SYSTEM "backup.sgml">
<!ENTITY charset SYSTEM "charset.sgml">
<!ENTITY client-auth SYSTEM "client-auth.sgml">
-<!ENTITY diskusage SYSTEM "diskusage.sgml">
<!ENTITY high-availability SYSTEM "high-availability.sgml">
<!ENTITY installation SYSTEM "installation.sgml">
<!ENTITY targets-meson SYSTEM "targets-meson.sgml">
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 8736eac284..eda54b4985 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -7282,4 +7282,147 @@ if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
</sect1>
+ <sect1 id="diskusage">
+ <title>Monitoring Disk Usage</title>
+
+ <para>
+ This section discusses how to monitor the disk usage of a
+ <productname>PostgreSQL</productname> database system.
+ </para>
+
+ <sect2 id="disk-usage">
+ <title>Determining Disk Usage</title>
+
+ <indexterm zone="disk-usage">
+ <primary>disk usage</primary>
+ </indexterm>
+
+ <para>
+ Each table has a primary heap disk file where most of the data is
+ stored. If the table has any columns with potentially-wide values,
+ there also might be a <acronym>TOAST</acronym> file associated with the table,
+ which is used to store values too wide to fit comfortably in the main
+ table (see <xref linkend="storage-toast"/>). There will be one valid index
+ on the <acronym>TOAST</acronym> table, if present. There also might be indexes
+ associated with the base table. Each table and index is stored in a
+ separate disk file — possibly more than one file, if the file would
+ exceed one gigabyte. Naming conventions for these files are described
+ in <xref linkend="storage-file-layout"/>.
+ </para>
+
+ <para>
+ You can monitor disk space in three ways:
+ using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
+ using the <xref linkend="oid2name"/> module, or
+ using manual inspection of the system catalogs.
+ The SQL functions are the easiest to use and are generally recommended.
+ The remainder of this section shows how to do it by inspection of the
+ system catalogs.
+ </para>
+
+ <para>
+ Using <application>psql</application> on a recently vacuumed or analyzed
+ database, you can issue queries to see the disk usage of any table:
+<programlisting>
+SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
+
+ pg_relation_filepath | relpages
+----------------------+----------
+ base/16384/16806 | 60
+(1 row)
+</programlisting>
+ Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
+ is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
+ a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
+ is of interest if you want to examine the table's disk file directly.
+ </para>
+
+ <para>
+ To show the space used by <acronym>TOAST</acronym> tables, use a query
+ like the following:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class,
+ (SELECT reltoastrelid
+ FROM pg_class
+ WHERE relname = 'customer') AS ss
+WHERE oid = ss.reltoastrelid OR
+ oid = (SELECT indexrelid
+ FROM pg_index
+ WHERE indrelid = ss.reltoastrelid)
+ORDER BY relname;
+
+ relname | relpages
+----------------------+----------
+ pg_toast_16806 | 0
+ pg_toast_16806_index | 1
+</programlisting>
+ </para>
+
+ <para>
+ You can easily display index sizes, too:
+<programlisting>
+SELECT c2.relname, c2.relpages
+FROM pg_class c, pg_class c2, pg_index i
+WHERE c.relname = 'customer' AND
+ c.oid = i.indrelid AND
+ c2.oid = i.indexrelid
+ORDER BY c2.relname;
+
+ relname | relpages
+-------------------+----------
+ customer_id_index | 26
+</programlisting>
+ </para>
+
+ <para>
+ It is easy to find your largest tables and indexes using this
+ information:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class
+ORDER BY relpages DESC;
+
+ relname | relpages
+----------------------+----------
+ bigtable | 3290
+ customer | 3144
+</programlisting>
+ </para>
+ </sect2>
+
+ <sect2 id="disk-full">
+ <title>Disk Full Failure</title>
+
+ <para>
+ The most important disk monitoring task of a database administrator
+ is to make sure the disk doesn't become full. A filled data disk will
+ not result in data corruption, but it might prevent useful activity
+ from occurring. If the disk holding the WAL files grows full, database
+ server panic and consequent shutdown might occur.
+ </para>
+
+ <para>
+ If you cannot free up additional space on the disk by deleting
+ other things, you can move some of the database files to other file
+ systems by making use of tablespaces. See <xref
+ linkend="manage-ag-tablespaces"/> for more information about that.
+ </para>
+
+ <tip>
+ <para>
+ Some file systems perform badly when they are almost full, so do
+ not wait until the disk is completely full to take action.
+ </para>
+ </tip>
+
+ <para>
+ If your system supports per-user disk quotas, then the database
+ will naturally be subject to whatever quota is placed on the user
+ the server runs as. Exceeding the quota will have the same bad
+ effects as running out of disk space entirely.
+ </para>
+ </sect2>
+ </sect1>
+
</chapter>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 7c234ff1db..73b497bcf8 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -161,7 +161,6 @@ break is not needed in a wider output rendering.
&backup;
&high-availability;
&monitoring;
- &diskusage;
&wal;
&logical-replication;
&jit;
--
2.39.3 (Apple Git-145)
v1-0004-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchapplication/octet-stream; name=v1-0004-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchDownload
From 5304db1a398bee08e540a6b638de4693a01e5dff Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 12:12:48 -0400
Subject: [PATCH v1 4/4] docs: Consolidate into new "WAL for Extensions"
chapter.
Previously, we had consecutive, very short chapters called "Generic
WAL" and "Custom WAL Resource Managers," explaining different approaches
to the same problem. Merge them into a single chapter.
---
doc/src/sgml/custom-rmgr.sgml | 105 ----------
doc/src/sgml/filelist.sgml | 3 +-
doc/src/sgml/generic-wal.sgml | 174 ----------------
doc/src/sgml/postgres.sgml | 3 +-
doc/src/sgml/wal-for-extensions.sgml | 283 +++++++++++++++++++++++++++
5 files changed, 285 insertions(+), 283 deletions(-)
delete mode 100644 doc/src/sgml/custom-rmgr.sgml
delete mode 100644 doc/src/sgml/generic-wal.sgml
create mode 100644 doc/src/sgml/wal-for-extensions.sgml
diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
deleted file mode 100644
index 0d98229295..0000000000
--- a/doc/src/sgml/custom-rmgr.sgml
+++ /dev/null
@@ -1,105 +0,0 @@
-<!-- doc/src/sgml/custom-rmgr.sgml -->
-
-<chapter id="custom-rmgr">
- <title>Custom WAL Resource Managers</title>
-
- <para>
- This chapter explains the interface between the core
- <productname>PostgreSQL</productname> system and custom WAL resource
- managers, which enable extensions to integrate directly with the <link
- linkend="wal"><acronym>WAL</acronym></link>.
- </para>
- <para>
- An extension, especially a <link linkend="tableam">Table Access
- Method</link> or <link linkend="indexam">Index Access Method</link>, may
- need to use WAL for recovery, replication, and/or <link
- linkend="logicaldecoding">Logical Decoding</link>. Custom resource managers
- are a more flexible alternative to <link linkend="generic-wal">Generic
- WAL</link> (which does not support logical decoding), but more complex for
- an extension to implement.
- </para>
- <para>
- To create a new custom WAL resource manager, first define an
- <structname>RmgrData</structname> structure with implementations for the
- resource manager methods. Refer to
- <filename>src/backend/access/transam/README</filename> and
- <filename>src/include/access/xlog_internal.h</filename> in the
- <productname>PostgreSQL</productname> source.
-<programlisting>
-/*
- * Method table for resource managers.
- *
- * This struct must be kept in sync with the PG_RMGR definition in
- * rmgr.c.
- *
- * rm_identify must return a name for the record based on xl_info (without
- * reference to the rmid). For example, XLOG_BTREE_VACUUM would be named
- * "VACUUM". rm_desc can then be called to obtain additional detail for the
- * record, if available (e.g. the last block).
- *
- * rm_mask takes as input a page modified by the resource manager and masks
- * out bits that shouldn't be flagged by wal_consistency_checking.
- *
- * RmgrTable[] is indexed by RmgrId values (see rmgrlist.h). If rm_name is
- * NULL, the corresponding RmgrTable entry is considered invalid.
- */
-typedef struct RmgrData
-{
- const char *rm_name;
- void (*rm_redo) (XLogReaderState *record);
- void (*rm_desc) (StringInfo buf, XLogReaderState *record);
- const char *(*rm_identify) (uint8 info);
- void (*rm_startup) (void);
- void (*rm_cleanup) (void);
- void (*rm_mask) (char *pagedata, BlockNumber blkno);
- void (*rm_decode) (struct LogicalDecodingContext *ctx,
- struct XLogRecordBuffer *buf);
-} RmgrData;
-</programlisting>
- </para>
-
- <para>
- The <filename>src/test/modules/test_custom_rmgrs</filename> module
- contains a working example, which demonstrates usage of custom WAL
- resource managers.
- </para>
-
- <para>
- Then, register your new resource
- manager.
-
-<programlisting>
-/*
- * Register a new custom WAL resource manager.
- *
- * Resource manager IDs must be globally unique across all extensions. Refer
- * to https://wiki.postgresql.org/wiki/CustomWALResourceManagers to reserve a
- * unique RmgrId for your extension, to avoid conflicts with other extension
- * developers. During development, use RM_EXPERIMENTAL_ID to avoid needlessly
- * reserving a new ID.
- */
-extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
-</programlisting>
- <function>RegisterCustomRmgr</function> must be called from the
- extension module's <link linkend="xfunc-c-dynload">_PG_init</link> function.
- While developing a new extension, use <literal>RM_EXPERIMENTAL_ID</literal>
- for <parameter>rmid</parameter>. When you are ready to release the extension
- to users, reserve a new resource manager ID at the <ulink
- url="https://wiki.postgresql.org/wiki/CustomWALResourceManagers">Custom WAL
- Resource Manager</ulink> page.
- </para>
-
- <para>
- Place the extension module implementing the custom resource manager in <xref
- linkend="guc-shared-preload-libraries"/> so that it will be loaded early
- during <productname>PostgreSQL</productname> startup.
- </para>
- <note>
- <para>
- The extension must remain in <varname>shared_preload_libraries</varname>
- as long as any custom WAL records may exist in the system. Otherwise
- <productname>PostgreSQL</productname> will not be able to apply or decode
- the custom WAL records, which may prevent the server from starting.
- </para>
- </note>
-</chapter>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index de683e3400..6e5ff6fa69 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -100,8 +100,7 @@
<!ENTITY storage SYSTEM "storage.sgml">
<!ENTITY transaction SYSTEM "xact.sgml">
<!ENTITY tablesample-method SYSTEM "tablesample-method.sgml">
-<!ENTITY generic-wal SYSTEM "generic-wal.sgml">
-<!ENTITY custom-rmgr SYSTEM "custom-rmgr.sgml">
+<!ENTITY wal-for-extensions SYSTEM "wal-for-extensions.sgml">
<!ENTITY backup-manifest SYSTEM "backup-manifest.sgml">
<!-- contrib information -->
diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml
deleted file mode 100644
index a028856d2e..0000000000
--- a/doc/src/sgml/generic-wal.sgml
+++ /dev/null
@@ -1,174 +0,0 @@
-<!-- doc/src/sgml/generic-wal.sgml -->
-
-<chapter id="generic-wal">
- <title>Generic WAL Records</title>
-
- <para>
- Although all built-in WAL-logged modules have their own types of WAL
- records, there is also a generic WAL record type, which describes changes
- to pages in a generic way. This is useful for extensions that provide
- custom access methods.
- </para>
-
- <para>
- In comparison with <link linkend="custom-rmgr">Custom WAL Resource
- Managers</link>, Generic WAL is simpler for an extension to implement and
- does not require the extension library to be loaded in order to apply the
- records.
- </para>
-
- <note>
- <para>
- Generic WAL records are ignored during <link
- linkend="logicaldecoding">Logical Decoding</link>. If logical decoding is
- required for your extension, consider a Custom WAL Resource Manager.
- </para>
- </note>
-
- <para>
- The API for constructing generic WAL records is defined in
- <filename>access/generic_xlog.h</filename> and implemented
- in <filename>access/transam/generic_xlog.c</filename>.
- </para>
-
- <para>
- To perform a WAL-logged data update using the generic WAL record
- facility, follow these steps:
-
- <orderedlist>
- <listitem>
- <para>
- <function>state = GenericXLogStart(relation)</function> — start
- construction of a generic WAL record for the given relation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>page = GenericXLogRegisterBuffer(state, buffer, flags)</function>
- — register a buffer to be modified within the current generic WAL
- record. This function returns a pointer to a temporary copy of the
- buffer's page, where modifications should be made. (Do not modify the
- buffer's contents directly.) The third argument is a bit mask of flags
- applicable to the operation. Currently the only such flag is
- <literal>GENERIC_XLOG_FULL_IMAGE</literal>, which indicates that a full-page
- image rather than a delta update should be included in the WAL record.
- Typically this flag would be set if the page is new or has been
- rewritten completely.
- <function>GenericXLogRegisterBuffer</function> can be repeated if the
- WAL-logged action needs to modify multiple pages.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Apply modifications to the page images obtained in the previous step.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>GenericXLogFinish(state)</function> — apply the changes to
- the buffers and emit the generic WAL record.
- </para>
- </listitem>
- </orderedlist>
- </para>
-
- <para>
- WAL record construction can be canceled between any of the above steps by
- calling <function>GenericXLogAbort(state)</function>. This will discard all
- changes to the page image copies.
- </para>
-
- <para>
- Please note the following points when using the generic WAL record
- facility:
-
- <itemizedlist>
- <listitem>
- <para>
- No direct modifications of buffers are allowed! All modifications must
- be done in copies acquired from <function>GenericXLogRegisterBuffer()</function>.
- In other words, code that makes generic WAL records should never call
- <function>BufferGetPage()</function> for itself. However, it remains the
- caller's responsibility to pin/unpin and lock/unlock the buffers at
- appropriate times. Exclusive lock must be held on each target buffer
- from before <function>GenericXLogRegisterBuffer()</function> until after
- <function>GenericXLogFinish()</function>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Registrations of buffers (step 2) and modifications of page images
- (step 3) can be mixed freely, i.e., both steps may be repeated in any
- sequence. Keep in mind that buffers should be registered in the same
- order in which locks are to be obtained on them during replay.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The maximum number of buffers that can be registered for a generic WAL
- record is <literal>MAX_GENERIC_XLOG_PAGES</literal>. An error will be thrown
- if this limit is exceeded.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Generic WAL assumes that the pages to be modified have standard
- layout, and in particular that there is no useful data between
- <structfield>pd_lower</structfield> and <structfield>pd_upper</structfield>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Since you are modifying copies of buffer
- pages, <function>GenericXLogStart()</function> does not start a critical
- section. Thus, you can safely do memory allocation, error throwing,
- etc. between <function>GenericXLogStart()</function> and
- <function>GenericXLogFinish()</function>. The only actual critical section is
- present inside <function>GenericXLogFinish()</function>. There is no need to
- worry about calling <function>GenericXLogAbort()</function> during an error
- exit, either.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <function>GenericXLogFinish()</function> takes care of marking buffers dirty
- and setting their LSNs. You do not need to do this explicitly.
- </para>
- </listitem>
-
- <listitem>
- <para>
- For unlogged relations, everything works the same except that no
- actual WAL record is emitted. Thus, you typically do not need to do
- any explicit checks for unlogged relations.
- </para>
- </listitem>
-
- <listitem>
- <para>
- The generic WAL redo function will acquire exclusive locks to buffers
- in the same order as they were registered. After redoing all changes,
- the locks will be released in the same order.
- </para>
- </listitem>
-
- <listitem>
- <para>
- If <literal>GENERIC_XLOG_FULL_IMAGE</literal> is not specified for a
- registered buffer, the generic WAL record contains a delta between
- the old and the new page images. This delta is based on byte-by-byte
- comparison. This is not very compact for the case of moving data
- within a page, and might be improved in the future.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-</chapter>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 0235c0e352..5bc47a9e71 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -255,8 +255,7 @@ break is not needed in a wider output rendering.
&geqo;
&tableam;
&indexam;
- &generic-wal;
- &custom-rmgr;
+ &wal-for-extensions;
&indextypes;
&storage;
&transaction;
diff --git a/doc/src/sgml/wal-for-extensions.sgml b/doc/src/sgml/wal-for-extensions.sgml
new file mode 100644
index 0000000000..cc233358dd
--- /dev/null
+++ b/doc/src/sgml/wal-for-extensions.sgml
@@ -0,0 +1,283 @@
+<!-- doc/src/sgml/wal-for-extensions.sgml -->
+
+<chapter id="wal-for-extensions">
+ <title>Write Ahead Logging for Extensions</title>
+
+ <sect1 id="generic-wal">
+ <title>Generic WAL Records</title>
+
+ <para>
+ Although all built-in WAL-logged modules have their own types of WAL
+ records, there is also a generic WAL record type, which describes changes
+ to pages in a generic way. This is useful for extensions that provide
+ custom access methods.
+ </para>
+
+ <para>
+ In comparison with <link linkend="custom-rmgr">Custom WAL Resource
+ Managers</link>, Generic WAL is simpler for an extension to implement and
+ does not require the extension library to be loaded in order to apply the
+ records.
+ </para>
+
+ <note>
+ <para>
+ Generic WAL records are ignored during <link
+ linkend="logicaldecoding">Logical Decoding</link>. If logical decoding is
+ required for your extension, consider a Custom WAL Resource Manager.
+ </para>
+ </note>
+
+ <para>
+ The API for constructing generic WAL records is defined in
+ <filename>access/generic_xlog.h</filename> and implemented
+ in <filename>access/transam/generic_xlog.c</filename>.
+ </para>
+
+ <para>
+ To perform a WAL-logged data update using the generic WAL record
+ facility, follow these steps:
+
+ <orderedlist>
+ <listitem>
+ <para>
+ <function>state = GenericXLogStart(relation)</function> — start
+ construction of a generic WAL record for the given relation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <function>page = GenericXLogRegisterBuffer(state, buffer, flags)</function>
+ — register a buffer to be modified within the current generic WAL
+ record. This function returns a pointer to a temporary copy of the
+ buffer's page, where modifications should be made. (Do not modify the
+ buffer's contents directly.) The third argument is a bit mask of flags
+ applicable to the operation. Currently the only such flag is
+ <literal>GENERIC_XLOG_FULL_IMAGE</literal>, which indicates that a full-page
+ image rather than a delta update should be included in the WAL record.
+ Typically this flag would be set if the page is new or has been
+ rewritten completely.
+ <function>GenericXLogRegisterBuffer</function> can be repeated if the
+ WAL-logged action needs to modify multiple pages.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Apply modifications to the page images obtained in the previous step.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <function>GenericXLogFinish(state)</function> — apply the changes to
+ the buffers and emit the generic WAL record.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+
+ <para>
+ WAL record construction can be canceled between any of the above steps by
+ calling <function>GenericXLogAbort(state)</function>. This will discard all
+ changes to the page image copies.
+ </para>
+
+ <para>
+ Please note the following points when using the generic WAL record
+ facility:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ No direct modifications of buffers are allowed! All modifications must
+ be done in copies acquired from <function>GenericXLogRegisterBuffer()</function>.
+ In other words, code that makes generic WAL records should never call
+ <function>BufferGetPage()</function> for itself. However, it remains the
+ caller's responsibility to pin/unpin and lock/unlock the buffers at
+ appropriate times. Exclusive lock must be held on each target buffer
+ from before <function>GenericXLogRegisterBuffer()</function> until after
+ <function>GenericXLogFinish()</function>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Registrations of buffers (step 2) and modifications of page images
+ (step 3) can be mixed freely, i.e., both steps may be repeated in any
+ sequence. Keep in mind that buffers should be registered in the same
+ order in which locks are to be obtained on them during replay.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The maximum number of buffers that can be registered for a generic WAL
+ record is <literal>MAX_GENERIC_XLOG_PAGES</literal>. An error will be thrown
+ if this limit is exceeded.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Generic WAL assumes that the pages to be modified have standard
+ layout, and in particular that there is no useful data between
+ <structfield>pd_lower</structfield> and <structfield>pd_upper</structfield>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Since you are modifying copies of buffer
+ pages, <function>GenericXLogStart()</function> does not start a critical
+ section. Thus, you can safely do memory allocation, error throwing,
+ etc. between <function>GenericXLogStart()</function> and
+ <function>GenericXLogFinish()</function>. The only actual critical section is
+ present inside <function>GenericXLogFinish()</function>. There is no need to
+ worry about calling <function>GenericXLogAbort()</function> during an error
+ exit, either.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <function>GenericXLogFinish()</function> takes care of marking buffers dirty
+ and setting their LSNs. You do not need to do this explicitly.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For unlogged relations, everything works the same except that no
+ actual WAL record is emitted. Thus, you typically do not need to do
+ any explicit checks for unlogged relations.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The generic WAL redo function will acquire exclusive locks to buffers
+ in the same order as they were registered. After redoing all changes,
+ the locks will be released in the same order.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If <literal>GENERIC_XLOG_FULL_IMAGE</literal> is not specified for a
+ registered buffer, the generic WAL record contains a delta between
+ the old and the new page images. This delta is based on byte-by-byte
+ comparison. This is not very compact for the case of moving data
+ within a page, and might be improved in the future.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect1>
+
+ <sect1 id="custom-rmgr">
+ <title>Custom WAL Resource Managers</title>
+
+ <para>
+ This section explains the interface between the core
+ <productname>PostgreSQL</productname> system and custom WAL resource
+ managers, which enable extensions to integrate directly with the <link
+ linkend="wal"><acronym>WAL</acronym></link>.
+ </para>
+ <para>
+ An extension, especially a <link linkend="tableam">Table Access
+ Method</link> or <link linkend="indexam">Index Access Method</link>, may
+ need to use WAL for recovery, replication, and/or <link
+ linkend="logicaldecoding">Logical Decoding</link>. Custom resource managers
+ are a more flexible alternative to <link linkend="generic-wal">Generic
+ WAL</link> (which does not support logical decoding), but more complex for
+ an extension to implement.
+ </para>
+ <para>
+ To create a new custom WAL resource manager, first define an
+ <structname>RmgrData</structname> structure with implementations for the
+ resource manager methods. Refer to
+ <filename>src/backend/access/transam/README</filename> and
+ <filename>src/include/access/xlog_internal.h</filename> in the
+ <productname>PostgreSQL</productname> source.
+<programlisting>
+/*
+ * Method table for resource managers.
+ *
+ * This struct must be kept in sync with the PG_RMGR definition in
+ * rmgr.c.
+ *
+ * rm_identify must return a name for the record based on xl_info (without
+ * reference to the rmid). For example, XLOG_BTREE_VACUUM would be named
+ * "VACUUM". rm_desc can then be called to obtain additional detail for the
+ * record, if available (e.g. the last block).
+ *
+ * rm_mask takes as input a page modified by the resource manager and masks
+ * out bits that shouldn't be flagged by wal_consistency_checking.
+ *
+ * RmgrTable[] is indexed by RmgrId values (see rmgrlist.h). If rm_name is
+ * NULL, the corresponding RmgrTable entry is considered invalid.
+ */
+typedef struct RmgrData
+{
+ const char *rm_name;
+ void (*rm_redo) (XLogReaderState *record);
+ void (*rm_desc) (StringInfo buf, XLogReaderState *record);
+ const char *(*rm_identify) (uint8 info);
+ void (*rm_startup) (void);
+ void (*rm_cleanup) (void);
+ void (*rm_mask) (char *pagedata, BlockNumber blkno);
+ void (*rm_decode) (struct LogicalDecodingContext *ctx,
+ struct XLogRecordBuffer *buf);
+} RmgrData;
+</programlisting>
+ </para>
+
+ <para>
+ The <filename>src/test/modules/test_custom_rmgrs</filename> module
+ contains a working example, which demonstrates usage of custom WAL
+ resource managers.
+ </para>
+
+ <para>
+ Then, register your new resource
+ manager.
+
+<programlisting>
+/*
+ * Register a new custom WAL resource manager.
+ *
+ * Resource manager IDs must be globally unique across all extensions. Refer
+ * to https://wiki.postgresql.org/wiki/CustomWALResourceManagers to reserve a
+ * unique RmgrId for your extension, to avoid conflicts with other extension
+ * developers. During development, use RM_EXPERIMENTAL_ID to avoid needlessly
+ * reserving a new ID.
+ */
+extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
+</programlisting>
+ <function>RegisterCustomRmgr</function> must be called from the
+ extension module's <link linkend="xfunc-c-dynload">_PG_init</link> function.
+ While developing a new extension, use <literal>RM_EXPERIMENTAL_ID</literal>
+ for <parameter>rmid</parameter>. When you are ready to release the extension
+ to users, reserve a new resource manager ID at the <ulink
+ url="https://wiki.postgresql.org/wiki/CustomWALResourceManagers">Custom WAL
+ Resource Manager</ulink> page.
+ </para>
+
+ <para>
+ Place the extension module implementing the custom resource manager in <xref
+ linkend="guc-shared-preload-libraries"/> so that it will be loaded early
+ during <productname>PostgreSQL</productname> startup.
+ </para>
+ <note>
+ <para>
+ The extension must remain in <varname>shared_preload_libraries</varname>
+ as long as any custom WAL records may exist in the system. Otherwise
+ <productname>PostgreSQL</productname> will not be able to apply or decode
+ the custom WAL records, which may prevent the server from starting.
+ </para>
+ </note>
+ </sect1>
+
+</chapter>
--
2.39.3 (Apple Git-145)
v1-0003-docs-Merge-separate-chapters-on-built-in-index-AM.patchapplication/octet-stream; name=v1-0003-docs-Merge-separate-chapters-on-built-in-index-AM.patchDownload
From 322cf03dbb7aaf61109f89b44e03e6e9a8d6b3f8 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 11:51:53 -0400
Subject: [PATCH v1 3/4] docs: Merge separate chapters on built-in index AMs
into one.
The documetation index is getting very long, which makes it hard
to find things. Since these chapters are all very similar in structure
and content, merging them is a natural way of reducing the size of
the toplevel index.
---
doc/src/sgml/brin.sgml | 1344 --------
doc/src/sgml/btree.sgml | 914 ------
doc/src/sgml/filelist.sgml | 7 +-
doc/src/sgml/gin.sgml | 714 -----
doc/src/sgml/gist.sgml | 1387 ---------
doc/src/sgml/hash.sgml | 162 -
doc/src/sgml/indextypes.sgml | 5597 ++++++++++++++++++++++++++++++++++
doc/src/sgml/postgres.sgml | 7 +-
doc/src/sgml/spgist.sgml | 1076 -------
9 files changed, 5599 insertions(+), 5609 deletions(-)
delete mode 100644 doc/src/sgml/brin.sgml
delete mode 100644 doc/src/sgml/btree.sgml
delete mode 100644 doc/src/sgml/gin.sgml
delete mode 100644 doc/src/sgml/gist.sgml
delete mode 100644 doc/src/sgml/hash.sgml
create mode 100644 doc/src/sgml/indextypes.sgml
delete mode 100644 doc/src/sgml/spgist.sgml
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
deleted file mode 100644
index d898cc4720..0000000000
--- a/doc/src/sgml/brin.sgml
+++ /dev/null
@@ -1,1344 +0,0 @@
-<!-- doc/src/sgml/brin.sgml -->
-
-<chapter id="brin">
-<title>BRIN Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>BRIN</secondary>
- </indexterm>
-
-<sect1 id="brin-intro">
- <title>Introduction</title>
-
- <para>
- <acronym>BRIN</acronym> stands for Block Range Index.
- <acronym>BRIN</acronym> is designed for handling very large tables
- in which certain columns have some natural correlation with their
- physical location within the table.
- </para>
-
- <para>
- <acronym>BRIN</acronym> works in terms of <firstterm>block ranges</firstterm>
- (or <quote>page ranges</quote>).
- A block range is a group of pages that are physically
- adjacent in the table; for each block range, some summary info is stored
- by the index.
- For example, a table storing a store's sale orders might have
- a date column on which each order was placed, and most of the time
- the entries for earlier orders will appear earlier in the table as well;
- a table storing a ZIP code column might have all codes for a city
- grouped together naturally.
- </para>
-
- <para>
- <acronym>BRIN</acronym> indexes can satisfy queries via regular bitmap
- index scans, and will return all tuples in all pages within each range if
- the summary info stored by the index is <firstterm>consistent</firstterm> with the
- query conditions.
- The query executor is in charge of rechecking these tuples and discarding
- those that do not match the query conditions — in other words, these
- indexes are lossy.
- Because a <acronym>BRIN</acronym> index is very small, scanning the index
- adds little overhead compared to a sequential scan, but may avoid scanning
- large parts of the table that are known not to contain matching tuples.
- </para>
-
- <para>
- The specific data that a <acronym>BRIN</acronym> index will store,
- as well as the specific queries that the index will be able to satisfy,
- depend on the operator class selected for each column of the index.
- Data types having a linear sort order can have operator classes that
- store the minimum and maximum value within each block range, for instance;
- geometrical types might store the bounding box for all the objects
- in the block range.
- </para>
-
- <para>
- The size of the block range is determined at index creation time by
- the <literal>pages_per_range</literal> storage parameter. The number of index
- entries will be equal to the size of the relation in pages divided by
- the selected value for <literal>pages_per_range</literal>. Therefore, the smaller
- the number, the larger the index becomes (because of the need to
- store more index entries), but at the same time the summary data stored can
- be more precise and more data blocks can be skipped during an index scan.
- </para>
-
- <sect2 id="brin-operation">
- <title>Index Maintenance</title>
-
- <para>
- At the time of creation, all existing heap pages are scanned and a
- summary index tuple is created for each range, including the
- possibly-incomplete range at the end.
- As new pages are filled with data, page ranges that are already
- summarized will cause the summary information to be updated with data
- from the new tuples.
- When a new page is created that does not fall within the last
- summarized range, the range that the new page belongs to
- does not automatically acquire a summary tuple;
- those tuples remain unsummarized until a summarization run is
- invoked later, creating the initial summary for that range.
- </para>
-
- <para>
- There are several ways to trigger the initial summarization of a page range.
- If the table is vacuumed, either manually or by
- <link linkend="autovacuum">autovacuum</link>, all existing unsummarized
- page ranges are summarized.
- Also, if the index's
- <xref linkend="index-reloption-autosummarize"/> parameter is enabled,
- which it isn't by default,
- whenever autovacuum runs in that database, summarization will occur for all
- unsummarized page ranges that have been filled,
- regardless of whether the table itself is processed by autovacuum; see below.
- </para>
-
- <para>
- Lastly, the following functions can be used (while these functions run,
- <xref linkend="guc-search-path"/> is temporarily changed to
- <literal>pg_catalog, pg_temp</literal>):
- <simplelist>
- <member>
- <function>brin_summarize_new_values(regclass)</function>
- which summarizes all unsummarized ranges;
- </member>
- <member>
- <function>brin_summarize_range(regclass, bigint)</function>
- which summarizes only the range containing the given page,
- if it is unsummarized.
- </member>
- </simplelist>
- </para>
-
- <para>
- When autosummarization is enabled, a request is sent to
- <literal>autovacuum</literal> to execute a targeted summarization
- for a block range when an insertion is detected for the first item
- of the first page of the next block range,
- to be fulfilled the next time an autovacuum
- worker finishes running in the
- same database. If the request queue is full, the request is not recorded
- and a message is sent to the server log:
-<screen>
-LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was not recorded
-</screen>
- When this happens, the range will remain unsummarized until the next
- regular vacuum run on the table, or one of the functions mentioned above
- are invoked.
- </para>
-
- <para>
- Conversely, a range can be de-summarized using the
- <function>brin_desummarize_range(regclass, bigint)</function> function,
- which is useful when the index tuple is no longer a very good
- representation because the existing values have changed.
- See <xref linkend="functions-admin-index"/> for details.
- </para>
-
- </sect2>
-</sect1>
-
-<sect1 id="brin-builtin-opclasses">
- <title>Built-in Operator Classes</title>
-
- <para>
- The core <productname>PostgreSQL</productname> distribution
- includes the <acronym>BRIN</acronym> operator classes shown in
- <xref linkend="brin-builtin-opclasses-table"/>.
- </para>
-
- <para>
- The <firstterm>minmax</firstterm>
- operator classes store the minimum and the maximum values appearing
- in the indexed column within the range. The <firstterm>inclusion</firstterm>
- operator classes store a value which includes the values in the indexed
- column within the range. The <firstterm>bloom</firstterm> operator
- classes build a Bloom filter for all values in the range. The
- <firstterm>minmax-multi</firstterm> operator classes store multiple
- minimum and maximum values, representing values appearing in the indexed
- column within the range.
- </para>
-
- <table id="brin-builtin-opclasses-table">
- <title>Built-in <acronym>BRIN</acronym> Operator Classes</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Name</entry>
- <entry>Indexable Operators</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry valign="middle" morerows="4"><literal>bit_minmax_ops</literal></entry>
- <entry><literal>= (bit,bit)</literal></entry>
- </row>
- <row><entry><literal>< (bit,bit)</literal></entry></row>
- <row><entry><literal>> (bit,bit)</literal></entry></row>
- <row><entry><literal><= (bit,bit)</literal></entry></row>
- <row><entry><literal>>= (bit,bit)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="12"><literal>box_inclusion_ops</literal></entry>
- <entry><literal>@> (box,point)</literal></entry>
- </row>
- <row><entry><literal><< (box,box)</literal></entry></row>
- <row><entry><literal>&< (box,box)</literal></entry></row>
- <row><entry><literal>&> (box,box)</literal></entry></row>
- <row><entry><literal>>> (box,box)</literal></entry></row>
- <row><entry><literal><@ (box,box)</literal></entry></row>
- <row><entry><literal>@> (box,box)</literal></entry></row>
- <row><entry><literal>~= (box,box)</literal></entry></row>
- <row><entry><literal>&& (box,box)</literal></entry></row>
- <row><entry><literal><<| (box,box)</literal></entry></row>
- <row><entry><literal>&<| (box,box)</literal></entry></row>
- <row><entry><literal>|&> (box,box)</literal></entry></row>
- <row><entry><literal>|>> (box,box)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>bpchar_bloom_ops</literal></entry>
- <entry><literal>= (character,character)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>bpchar_minmax_ops</literal></entry>
- <entry><literal>= (character,character)</literal></entry>
- </row>
- <row><entry><literal>< (character,character)</literal></entry></row>
- <row><entry><literal><= (character,character)</literal></entry></row>
- <row><entry><literal>> (character,character)</literal></entry></row>
- <row><entry><literal>>= (character,character)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>bytea_bloom_ops</literal></entry>
- <entry><literal>= (bytea,bytea)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>bytea_minmax_ops</literal></entry>
- <entry><literal>= (bytea,bytea)</literal></entry>
- </row>
- <row><entry><literal>< (bytea,bytea)</literal></entry></row>
- <row><entry><literal><= (bytea,bytea)</literal></entry></row>
- <row><entry><literal>> (bytea,bytea)</literal></entry></row>
- <row><entry><literal>>= (bytea,bytea)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>char_bloom_ops</literal></entry>
- <entry><literal>= ("char","char")</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>char_minmax_ops</literal></entry>
- <entry><literal>= ("char","char")</literal></entry>
- </row>
- <row><entry><literal>< ("char","char")</literal></entry></row>
- <row><entry><literal><= ("char","char")</literal></entry></row>
- <row><entry><literal>> ("char","char")</literal></entry></row>
- <row><entry><literal>>= ("char","char")</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>date_bloom_ops</literal></entry>
- <entry><literal>= (date,date)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>date_minmax_ops</literal></entry>
- <entry><literal>= (date,date)</literal></entry>
- </row>
- <row><entry><literal>< (date,date)</literal></entry></row>
- <row><entry><literal><= (date,date)</literal></entry></row>
- <row><entry><literal>> (date,date)</literal></entry></row>
- <row><entry><literal>>= (date,date)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>date_minmax_multi_ops</literal></entry>
- <entry><literal>= (date,date)</literal></entry>
- </row>
- <row><entry><literal>< (date,date)</literal></entry></row>
- <row><entry><literal><= (date,date)</literal></entry></row>
- <row><entry><literal>> (date,date)</literal></entry></row>
- <row><entry><literal>>= (date,date)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>float4_bloom_ops</literal></entry>
- <entry><literal>= (float4,float4)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>float4_minmax_ops</literal></entry>
- <entry><literal>= (float4,float4)</literal></entry>
- </row>
- <row><entry><literal>< (float4,float4)</literal></entry></row>
- <row><entry><literal>> (float4,float4)</literal></entry></row>
- <row><entry><literal><= (float4,float4)</literal></entry></row>
- <row><entry><literal>>= (float4,float4)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>float4_minmax_multi_ops</literal></entry>
- <entry><literal>= (float4,float4)</literal></entry>
- </row>
- <row><entry><literal>< (float4,float4)</literal></entry></row>
- <row><entry><literal>> (float4,float4)</literal></entry></row>
- <row><entry><literal><= (float4,float4)</literal></entry></row>
- <row><entry><literal>>= (float4,float4)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>float8_bloom_ops</literal></entry>
- <entry><literal>= (float8,float8)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>float8_minmax_ops</literal></entry>
- <entry><literal>= (float8,float8)</literal></entry>
- </row>
- <row><entry><literal>< (float8,float8)</literal></entry></row>
- <row><entry><literal><= (float8,float8)</literal></entry></row>
- <row><entry><literal>> (float8,float8)</literal></entry></row>
- <row><entry><literal>>= (float8,float8)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>float8_minmax_multi_ops</literal></entry>
- <entry><literal>= (float8,float8)</literal></entry>
- </row>
- <row><entry><literal>< (float8,float8)</literal></entry></row>
- <row><entry><literal><= (float8,float8)</literal></entry></row>
- <row><entry><literal>> (float8,float8)</literal></entry></row>
- <row><entry><literal>>= (float8,float8)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="5"><literal>inet_inclusion_ops</literal></entry>
- <entry><literal><< (inet,inet)</literal></entry>
- </row>
- <row><entry><literal><<= (inet,inet)</literal></entry></row>
- <row><entry><literal>>> (inet,inet)</literal></entry></row>
- <row><entry><literal>>>= (inet,inet)</literal></entry></row>
- <row><entry><literal>= (inet,inet)</literal></entry></row>
- <row><entry><literal>&& (inet,inet)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>inet_bloom_ops</literal></entry>
- <entry><literal>= (inet,inet)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>inet_minmax_ops</literal></entry>
- <entry><literal>= (inet,inet)</literal></entry>
- </row>
- <row><entry><literal>< (inet,inet)</literal></entry></row>
- <row><entry><literal><= (inet,inet)</literal></entry></row>
- <row><entry><literal>> (inet,inet)</literal></entry></row>
- <row><entry><literal>>= (inet,inet)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>inet_minmax_multi_ops</literal></entry>
- <entry><literal>= (inet,inet)</literal></entry>
- </row>
- <row><entry><literal>< (inet,inet)</literal></entry></row>
- <row><entry><literal><= (inet,inet)</literal></entry></row>
- <row><entry><literal>> (inet,inet)</literal></entry></row>
- <row><entry><literal>>= (inet,inet)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>int2_bloom_ops</literal></entry>
- <entry><literal>= (int2,int2)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int2_minmax_ops</literal></entry>
- <entry><literal>= (int2,int2)</literal></entry>
- </row>
- <row><entry><literal>< (int2,int2)</literal></entry></row>
- <row><entry><literal>> (int2,int2)</literal></entry></row>
- <row><entry><literal><= (int2,int2)</literal></entry></row>
- <row><entry><literal>>= (int2,int2)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int2_minmax_multi_ops</literal></entry>
- <entry><literal>= (int2,int2)</literal></entry>
- </row>
- <row><entry><literal>< (int2,int2)</literal></entry></row>
- <row><entry><literal>> (int2,int2)</literal></entry></row>
- <row><entry><literal><= (int2,int2)</literal></entry></row>
- <row><entry><literal>>= (int2,int2)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>int4_bloom_ops</literal></entry>
- <entry><literal>= (int4,int4)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int4_minmax_ops</literal></entry>
- <entry><literal>= (int4,int4)</literal></entry>
- </row>
- <row><entry><literal>< (int4,int4)</literal></entry></row>
- <row><entry><literal>> (int4,int4)</literal></entry></row>
- <row><entry><literal><= (int4,int4)</literal></entry></row>
- <row><entry><literal>>= (int4,int4)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int4_minmax_multi_ops</literal></entry>
- <entry><literal>= (int4,int4)</literal></entry>
- </row>
- <row><entry><literal>< (int4,int4)</literal></entry></row>
- <row><entry><literal>> (int4,int4)</literal></entry></row>
- <row><entry><literal><= (int4,int4)</literal></entry></row>
- <row><entry><literal>>= (int4,int4)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>int8_bloom_ops</literal></entry>
- <entry><literal>= (bigint,bigint)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int8_minmax_ops</literal></entry>
- <entry><literal>= (bigint,bigint)</literal></entry>
- </row>
- <row><entry><literal>< (bigint,bigint)</literal></entry></row>
- <row><entry><literal>> (bigint,bigint)</literal></entry></row>
- <row><entry><literal><= (bigint,bigint)</literal></entry></row>
- <row><entry><literal>>= (bigint,bigint)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>int8_minmax_multi_ops</literal></entry>
- <entry><literal>= (bigint,bigint)</literal></entry>
- </row>
- <row><entry><literal>< (bigint,bigint)</literal></entry></row>
- <row><entry><literal>> (bigint,bigint)</literal></entry></row>
- <row><entry><literal><= (bigint,bigint)</literal></entry></row>
- <row><entry><literal>>= (bigint,bigint)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>interval_bloom_ops</literal></entry>
- <entry><literal>= (interval,interval)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>interval_minmax_ops</literal></entry>
- <entry><literal>= (interval,interval)</literal></entry>
- </row>
- <row><entry><literal>< (interval,interval)</literal></entry></row>
- <row><entry><literal><= (interval,interval)</literal></entry></row>
- <row><entry><literal>> (interval,interval)</literal></entry></row>
- <row><entry><literal>>= (interval,interval)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>interval_minmax_multi_ops</literal></entry>
- <entry><literal>= (interval,interval)</literal></entry>
- </row>
- <row><entry><literal>< (interval,interval)</literal></entry></row>
- <row><entry><literal><= (interval,interval)</literal></entry></row>
- <row><entry><literal>> (interval,interval)</literal></entry></row>
- <row><entry><literal>>= (interval,interval)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>macaddr_bloom_ops</literal></entry>
- <entry><literal>= (macaddr,macaddr)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>macaddr_minmax_ops</literal></entry>
- <entry><literal>= (macaddr,macaddr)</literal></entry>
- </row>
- <row><entry><literal>< (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal><= (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal>> (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal>>= (macaddr,macaddr)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>macaddr_minmax_multi_ops</literal></entry>
- <entry><literal>= (macaddr,macaddr)</literal></entry>
- </row>
- <row><entry><literal>< (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal><= (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal>> (macaddr,macaddr)</literal></entry></row>
- <row><entry><literal>>= (macaddr,macaddr)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>macaddr8_bloom_ops</literal></entry>
- <entry><literal>= (macaddr8,macaddr8)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>macaddr8_minmax_ops</literal></entry>
- <entry><literal>= (macaddr8,macaddr8)</literal></entry>
- </row>
- <row><entry><literal>< (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal><= (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal>> (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal>>= (macaddr8,macaddr8)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>macaddr8_minmax_multi_ops</literal></entry>
- <entry><literal>= (macaddr8,macaddr8)</literal></entry>
- </row>
- <row><entry><literal>< (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal><= (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal>> (macaddr8,macaddr8)</literal></entry></row>
- <row><entry><literal>>= (macaddr8,macaddr8)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>name_bloom_ops</literal></entry>
- <entry><literal>= (name,name)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>name_minmax_ops</literal></entry>
- <entry><literal>= (name,name)</literal></entry>
- </row>
- <row><entry><literal>< (name,name)</literal></entry></row>
- <row><entry><literal><= (name,name)</literal></entry></row>
- <row><entry><literal>> (name,name)</literal></entry></row>
- <row><entry><literal>>= (name,name)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>numeric_bloom_ops</literal></entry>
- <entry><literal>= (numeric,numeric)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>numeric_minmax_ops</literal></entry>
- <entry><literal>= (numeric,numeric)</literal></entry>
- </row>
- <row><entry><literal>< (numeric,numeric)</literal></entry></row>
- <row><entry><literal><= (numeric,numeric)</literal></entry></row>
- <row><entry><literal>> (numeric,numeric)</literal></entry></row>
- <row><entry><literal>>= (numeric,numeric)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>numeric_minmax_multi_ops</literal></entry>
- <entry><literal>= (numeric,numeric)</literal></entry>
- </row>
- <row><entry><literal>< (numeric,numeric)</literal></entry></row>
- <row><entry><literal><= (numeric,numeric)</literal></entry></row>
- <row><entry><literal>> (numeric,numeric)</literal></entry></row>
- <row><entry><literal>>= (numeric,numeric)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>oid_bloom_ops</literal></entry>
- <entry><literal>= (oid,oid)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>oid_minmax_ops</literal></entry>
- <entry><literal>= (oid,oid)</literal></entry>
- </row>
- <row><entry><literal>< (oid,oid)</literal></entry></row>
- <row><entry><literal>> (oid,oid)</literal></entry></row>
- <row><entry><literal><= (oid,oid)</literal></entry></row>
- <row><entry><literal>>= (oid,oid)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>oid_minmax_multi_ops</literal></entry>
- <entry><literal>= (oid,oid)</literal></entry>
- </row>
- <row><entry><literal>< (oid,oid)</literal></entry></row>
- <row><entry><literal>> (oid,oid)</literal></entry></row>
- <row><entry><literal><= (oid,oid)</literal></entry></row>
- <row><entry><literal>>= (oid,oid)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>pg_lsn_bloom_ops</literal></entry>
- <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>pg_lsn_minmax_ops</literal></entry>
- <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
- </row>
- <row><entry><literal>< (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal>> (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal><= (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal>>= (pg_lsn,pg_lsn)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>pg_lsn_minmax_multi_ops</literal></entry>
- <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
- </row>
- <row><entry><literal>< (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal>> (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal><= (pg_lsn,pg_lsn)</literal></entry></row>
- <row><entry><literal>>= (pg_lsn,pg_lsn)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="13"><literal>range_inclusion_ops</literal></entry>
- <entry><literal>= (anyrange,anyrange)</literal></entry>
- </row>
- <row><entry><literal>< (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal><= (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>>= (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>&& (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>@> (anyrange,anyelement)</literal></entry></row>
- <row><entry><literal>@> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal><@ (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal><< (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>>> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>&< (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>&> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>-|- (anyrange,anyrange)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>text_bloom_ops</literal></entry>
- <entry><literal>= (text,text)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>text_minmax_ops</literal></entry>
- <entry><literal>= (text,text)</literal></entry>
- </row>
- <row><entry><literal>< (text,text)</literal></entry></row>
- <row><entry><literal><= (text,text)</literal></entry></row>
- <row><entry><literal>> (text,text)</literal></entry></row>
- <row><entry><literal>>= (text,text)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>tid_bloom_ops</literal></entry>
- <entry><literal>= (tid,tid)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>tid_minmax_ops</literal></entry>
- <entry><literal>= (tid,tid)</literal></entry>
- </row>
- <row><entry><literal>< (tid,tid)</literal></entry></row>
- <row><entry><literal>> (tid,tid)</literal></entry></row>
- <row><entry><literal><= (tid,tid)</literal></entry></row>
- <row><entry><literal>>= (tid,tid)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>tid_minmax_multi_ops</literal></entry>
- <entry><literal>= (tid,tid)</literal></entry>
- </row>
- <row><entry><literal>< (tid,tid)</literal></entry></row>
- <row><entry><literal>> (tid,tid)</literal></entry></row>
- <row><entry><literal><= (tid,tid)</literal></entry></row>
- <row><entry><literal>>= (tid,tid)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>timestamp_bloom_ops</literal></entry>
- <entry><literal>= (timestamp,timestamp)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timestamp_minmax_ops</literal></entry>
- <entry><literal>= (timestamp,timestamp)</literal></entry>
- </row>
- <row><entry><literal>< (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal><= (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal>> (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal>>= (timestamp,timestamp)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timestamp_minmax_multi_ops</literal></entry>
- <entry><literal>= (timestamp,timestamp)</literal></entry>
- </row>
- <row><entry><literal>< (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal><= (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal>> (timestamp,timestamp)</literal></entry></row>
- <row><entry><literal>>= (timestamp,timestamp)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>timestamptz_bloom_ops</literal></entry>
- <entry><literal>= (timestamptz,timestamptz)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timestamptz_minmax_ops</literal></entry>
- <entry><literal>= (timestamptz,timestamptz)</literal></entry>
- </row>
- <row><entry><literal>< (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal><= (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal>> (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal>>= (timestamptz,timestamptz)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timestamptz_minmax_multi_ops</literal></entry>
- <entry><literal>= (timestamptz,timestamptz)</literal></entry>
- </row>
- <row><entry><literal>< (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal><= (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal>> (timestamptz,timestamptz)</literal></entry></row>
- <row><entry><literal>>= (timestamptz,timestamptz)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>time_bloom_ops</literal></entry>
- <entry><literal>= (time,time)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>time_minmax_ops</literal></entry>
- <entry><literal>= (time,time)</literal></entry>
- </row>
- <row><entry><literal>< (time,time)</literal></entry></row>
- <row><entry><literal><= (time,time)</literal></entry></row>
- <row><entry><literal>> (time,time)</literal></entry></row>
- <row><entry><literal>>= (time,time)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>time_minmax_multi_ops</literal></entry>
- <entry><literal>= (time,time)</literal></entry>
- </row>
- <row><entry><literal>< (time,time)</literal></entry></row>
- <row><entry><literal><= (time,time)</literal></entry></row>
- <row><entry><literal>> (time,time)</literal></entry></row>
- <row><entry><literal>>= (time,time)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>timetz_bloom_ops</literal></entry>
- <entry><literal>= (timetz,timetz)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timetz_minmax_ops</literal></entry>
- <entry><literal>= (timetz,timetz)</literal></entry>
- </row>
- <row><entry><literal>< (timetz,timetz)</literal></entry></row>
- <row><entry><literal><= (timetz,timetz)</literal></entry></row>
- <row><entry><literal>> (timetz,timetz)</literal></entry></row>
- <row><entry><literal>>= (timetz,timetz)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>timetz_minmax_multi_ops</literal></entry>
- <entry><literal>= (timetz,timetz)</literal></entry>
- </row>
- <row><entry><literal>< (timetz,timetz)</literal></entry></row>
- <row><entry><literal><= (timetz,timetz)</literal></entry></row>
- <row><entry><literal>> (timetz,timetz)</literal></entry></row>
- <row><entry><literal>>= (timetz,timetz)</literal></entry></row>
-
- <row>
- <entry valign="middle"><literal>uuid_bloom_ops</literal></entry>
- <entry><literal>= (uuid,uuid)</literal></entry>
- </row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>uuid_minmax_ops</literal></entry>
- <entry><literal>= (uuid,uuid)</literal></entry>
- </row>
- <row><entry><literal>< (uuid,uuid)</literal></entry></row>
- <row><entry><literal>> (uuid,uuid)</literal></entry></row>
- <row><entry><literal><= (uuid,uuid)</literal></entry></row>
- <row><entry><literal>>= (uuid,uuid)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>uuid_minmax_multi_ops</literal></entry>
- <entry><literal>= (uuid,uuid)</literal></entry>
- </row>
- <row><entry><literal>< (uuid,uuid)</literal></entry></row>
- <row><entry><literal>> (uuid,uuid)</literal></entry></row>
- <row><entry><literal><= (uuid,uuid)</literal></entry></row>
- <row><entry><literal>>= (uuid,uuid)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="4"><literal>varbit_minmax_ops</literal></entry>
- <entry><literal>= (varbit,varbit)</literal></entry>
- </row>
- <row><entry><literal>< (varbit,varbit)</literal></entry></row>
- <row><entry><literal>> (varbit,varbit)</literal></entry></row>
- <row><entry><literal><= (varbit,varbit)</literal></entry></row>
- <row><entry><literal>>= (varbit,varbit)</literal></entry></row>
- </tbody>
- </tgroup>
- </table>
-
- <sect2 id="brin-builtin-opclasses--parameters">
- <title>Operator Class Parameters</title>
-
- <para>
- Some of the built-in operator classes allow specifying parameters affecting
- behavior of the operator class. Each operator class has its own set of
- allowed parameters. Only the <literal>bloom</literal> and <literal>minmax-multi</literal>
- operator classes allow specifying parameters:
- </para>
-
- <para>
- bloom operator classes accept these parameters:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><literal>n_distinct_per_range</literal></term>
- <listitem>
- <para>
- Defines the estimated number of distinct non-null values in the block
- range, used by <acronym>BRIN</acronym> bloom indexes for sizing of the
- Bloom filter. It behaves similarly to <literal>n_distinct</literal> option
- for <xref linkend="sql-altertable"/>. When set to a positive value,
- each block range is assumed to contain this number of distinct non-null
- values. When set to a negative value, which must be greater than or
- equal to -1, the number of distinct non-null values is assumed to grow linearly with
- the maximum possible number of tuples in the block range (about 290
- rows per block). The default value is <literal>-0.1</literal>, and
- the minimum number of distinct non-null values is <literal>16</literal>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>false_positive_rate</literal></term>
- <listitem>
- <para>
- Defines the desired false positive rate used by <acronym>BRIN</acronym>
- bloom indexes for sizing of the Bloom filter. The values must be
- between 0.0001 and 0.25. The default value is 0.01, which is 1% false
- positive rate.
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-
- <para>
- minmax-multi operator classes accept these parameters:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><literal>values_per_range</literal></term>
- <listitem>
- <para>
- Defines the maximum number of values stored by <acronym>BRIN</acronym>
- minmax indexes to summarize a block range. Each value may represent
- either a point, or a boundary of an interval. Values must be between
- 8 and 256, and the default value is 32.
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
- </sect2>
-
-</sect1>
-
-<sect1 id="brin-extensibility">
- <title>Extensibility</title>
-
- <para>
- The <acronym>BRIN</acronym> interface has a high level of abstraction,
- requiring the access method implementer only to implement the semantics
- of the data type being accessed. The <acronym>BRIN</acronym> layer
- itself takes care of concurrency, logging and searching the index structure.
- </para>
-
- <para>
- All it takes to get a <acronym>BRIN</acronym> access method working is to
- implement a few user-defined methods, which define the behavior of
- summary values stored in the index and the way they interact with
- scan keys.
- In short, <acronym>BRIN</acronym> combines
- extensibility with generality, code reuse, and a clean interface.
- </para>
-
- <para>
- There are four methods that an operator class for <acronym>BRIN</acronym>
- must provide:
-
- <variablelist>
- <varlistentry>
- <term><function>BrinOpcInfo *opcInfo(Oid type_oid)</function></term>
- <listitem>
- <para>
- Returns internal information about the indexed columns' summary data.
- The return value must point to a palloc'd <structname>BrinOpcInfo</structname>,
- which has this definition:
-<programlisting>
-typedef struct BrinOpcInfo
-{
- /* Number of columns stored in an index column of this opclass */
- uint16 oi_nstored;
-
- /* Opaque pointer for the opclass' private use */
- void *oi_opaque;
-
- /* Type cache entries of the stored columns */
- TypeCacheEntry *oi_typcache[FLEXIBLE_ARRAY_MEMBER];
-} BrinOpcInfo;
-</programlisting>
- <structname>BrinOpcInfo</structname>.<structfield>oi_opaque</structfield> can be used by the
- operator class routines to pass information between support functions
- during an index scan.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>bool consistent(BrinDesc *bdesc, BrinValues *column,
- ScanKey *keys, int nkeys)</function></term>
- <listitem>
- <para>
- Returns whether all the ScanKey entries are consistent with the given
- indexed values for a range.
- The attribute number to use is passed as part of the scan key.
- Multiple scan keys for the same attribute may be passed at once; the
- number of entries is determined by the <literal>nkeys</literal> parameter.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>bool consistent(BrinDesc *bdesc, BrinValues *column,
- ScanKey key)</function></term>
- <listitem>
- <para>
- Returns whether the ScanKey is consistent with the given indexed
- values for a range.
- The attribute number to use is passed as part of the scan key.
- This is an older backward-compatible variant of the consistent function.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>bool addValue(BrinDesc *bdesc, BrinValues *column,
- Datum newval, bool isnull)</function></term>
- <listitem>
- <para>
- Given an index tuple and an indexed value, modifies the indicated
- attribute of the tuple so that it additionally represents the new value.
- If any modification was done to the tuple, <literal>true</literal> is
- returned.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>bool unionTuples(BrinDesc *bdesc, BrinValues *a,
- BrinValues *b)</function></term>
- <listitem>
- <para>
- Consolidates two index tuples. Given two index tuples, modifies the
- indicated attribute of the first of them so that it represents both tuples.
- The second tuple is not modified.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- An operator class for <acronym>BRIN</acronym> can optionally specify the
- following method:
-
- <variablelist>
- <varlistentry>
- <term><function>void options(local_relopts *relopts)</function></term>
- <listitem>
- <para>
- Defines a set of user-visible parameters that control operator class
- behavior.
- </para>
-
- <para>
- The <function>options</function> function is passed a pointer to a
- <structname>local_relopts</structname> struct, which needs to be
- filled with a set of operator class specific options. The options
- can be accessed from other support functions using the
- <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
- <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
- </para>
-
- <para>
- Since both key extraction of indexed values and representation of the
- key in <acronym>BRIN</acronym> are flexible, they may depend on
- user-specified parameters.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- The core distribution includes support for four types of operator classes:
- minmax, minmax-multi, inclusion and bloom. Operator class definitions
- using them are shipped for in-core data types as appropriate. Additional
- operator classes can be defined by the user for other data types using
- equivalent definitions, without having to write any source code;
- appropriate catalog entries being declared is enough. Note that
- assumptions about the semantics of operator strategies are embedded in the
- support functions' source code.
- </para>
-
- <para>
- Operator classes that implement completely different semantics are also
- possible, provided implementations of the four main support functions
- described above are written. Note that backwards compatibility across major
- releases is not guaranteed: for example, additional support functions might
- be required in later releases.
- </para>
-
- <para>
- To write an operator class for a data type that implements a totally
- ordered set, it is possible to use the minmax support functions
- alongside the corresponding operators, as shown in
- <xref linkend="brin-extensibility-minmax-table"/>.
- All operator class members (functions and operators) are mandatory.
- </para>
-
- <table id="brin-extensibility-minmax-table">
- <title>Function and Support Numbers for Minmax Operator Classes</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Operator class member</entry>
- <entry>Object</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>Support Function 1</entry>
- <entry>internal function <function>brin_minmax_opcinfo()</function></entry>
- </row>
- <row>
- <entry>Support Function 2</entry>
- <entry>internal function <function>brin_minmax_add_value()</function></entry>
- </row>
- <row>
- <entry>Support Function 3</entry>
- <entry>internal function <function>brin_minmax_consistent()</function></entry>
- </row>
- <row>
- <entry>Support Function 4</entry>
- <entry>internal function <function>brin_minmax_union()</function></entry>
- </row>
- <row>
- <entry>Operator Strategy 1</entry>
- <entry>operator less-than</entry>
- </row>
- <row>
- <entry>Operator Strategy 2</entry>
- <entry>operator less-than-or-equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 3</entry>
- <entry>operator equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 4</entry>
- <entry>operator greater-than-or-equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 5</entry>
- <entry>operator greater-than</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- To write an operator class for a complex data type which has values
- included within another type, it's possible to use the inclusion support
- functions alongside the corresponding operators, as shown
- in <xref linkend="brin-extensibility-inclusion-table"/>. It requires
- only a single additional function, which can be written in any language.
- More functions can be defined for additional functionality. All operators
- are optional. Some operators require other operators, as shown as
- dependencies on the table.
- </para>
-
- <table id="brin-extensibility-inclusion-table">
- <title>Function and Support Numbers for Inclusion Operator Classes</title>
- <tgroup cols="3">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <colspec colname="col3" colwidth="1*"/>
- <thead>
- <row>
- <entry>Operator class member</entry>
- <entry>Object</entry>
- <entry>Dependency</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>Support Function 1</entry>
- <entry>internal function <function>brin_inclusion_opcinfo()</function></entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 2</entry>
- <entry>internal function <function>brin_inclusion_add_value()</function></entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 3</entry>
- <entry>internal function <function>brin_inclusion_consistent()</function></entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 4</entry>
- <entry>internal function <function>brin_inclusion_union()</function></entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 11</entry>
- <entry>function to merge two elements</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 12</entry>
- <entry>optional function to check whether two elements are mergeable</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 13</entry>
- <entry>optional function to check if an element is contained within another</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Support Function 14</entry>
- <entry>optional function to check whether an element is empty</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Operator Strategy 1</entry>
- <entry>operator left-of</entry>
- <entry>Operator Strategy 4</entry>
- </row>
- <row>
- <entry>Operator Strategy 2</entry>
- <entry>operator does-not-extend-to-the-right-of</entry>
- <entry>Operator Strategy 5</entry>
- </row>
- <row>
- <entry>Operator Strategy 3</entry>
- <entry>operator overlaps</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Operator Strategy 4</entry>
- <entry>operator does-not-extend-to-the-left-of</entry>
- <entry>Operator Strategy 1</entry>
- </row>
- <row>
- <entry>Operator Strategy 5</entry>
- <entry>operator right-of</entry>
- <entry>Operator Strategy 2</entry>
- </row>
- <row>
- <entry>Operator Strategy 6, 18</entry>
- <entry>operator same-as-or-equal-to</entry>
- <entry>Operator Strategy 7</entry>
- </row>
- <row>
- <entry>Operator Strategy 7, 16, 24, 25</entry>
- <entry>operator contains-or-equal-to</entry>
- <entry></entry>
- </row>
- <row>
- <entry>Operator Strategy 8, 26, 27</entry>
- <entry>operator is-contained-by-or-equal-to</entry>
- <entry>Operator Strategy 3</entry>
- </row>
- <row>
- <entry>Operator Strategy 9</entry>
- <entry>operator does-not-extend-above</entry>
- <entry>Operator Strategy 11</entry>
- </row>
- <row>
- <entry>Operator Strategy 10</entry>
- <entry>operator is-below</entry>
- <entry>Operator Strategy 12</entry>
- </row>
- <row>
- <entry>Operator Strategy 11</entry>
- <entry>operator is-above</entry>
- <entry>Operator Strategy 9</entry>
- </row>
- <row>
- <entry>Operator Strategy 12</entry>
- <entry>operator does-not-extend-below</entry>
- <entry>Operator Strategy 10</entry>
- </row>
- <row>
- <entry>Operator Strategy 20</entry>
- <entry>operator less-than</entry>
- <entry>Operator Strategy 5</entry>
- </row>
- <row>
- <entry>Operator Strategy 21</entry>
- <entry>operator less-than-or-equal-to</entry>
- <entry>Operator Strategy 5</entry>
- </row>
- <row>
- <entry>Operator Strategy 22</entry>
- <entry>operator greater-than</entry>
- <entry>Operator Strategy 1</entry>
- </row>
- <row>
- <entry>Operator Strategy 23</entry>
- <entry>operator greater-than-or-equal-to</entry>
- <entry>Operator Strategy 1</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Support function numbers 1 through 10 are reserved for the BRIN internal
- functions, so the SQL level functions start with number 11. Support
- function number 11 is the main function required to build the index.
- It should accept two arguments with the same data type as the operator class,
- and return the union of them. The inclusion operator class can store union
- values with different data types if it is defined with the
- <literal>STORAGE</literal> parameter. The return value of the union
- function should match the <literal>STORAGE</literal> data type.
- </para>
-
- <para>
- Support function numbers 12 and 14 are provided to support
- irregularities of built-in data types. Function number 12
- is used to support network addresses from different families which
- are not mergeable. Function number 14 is used to support
- empty ranges. Function number 13 is an optional but
- recommended one, which allows the new value to be checked before
- it is passed to the union function. As the BRIN framework can shortcut
- some operations when the union is not changed, using this
- function can improve index performance.
- </para>
-
- <para>
- To write an operator class for a data type that implements only an equality
- operator and supports hashing, it is possible to use the bloom support procedures
- alongside the corresponding operators, as shown in
- <xref linkend="brin-extensibility-bloom-table"/>.
- All operator class members (procedures and operators) are mandatory.
- </para>
-
- <table id="brin-extensibility-bloom-table">
- <title>Procedure and Support Numbers for Bloom Operator Classes</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Operator class member</entry>
- <entry>Object</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>Support Procedure 1</entry>
- <entry>internal function <function>brin_bloom_opcinfo()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 2</entry>
- <entry>internal function <function>brin_bloom_add_value()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 3</entry>
- <entry>internal function <function>brin_bloom_consistent()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 4</entry>
- <entry>internal function <function>brin_bloom_union()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 5</entry>
- <entry>internal function <function>brin_bloom_options()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 11</entry>
- <entry>function to compute hash of an element</entry>
- </row>
- <row>
- <entry>Operator Strategy 1</entry>
- <entry>operator equal-to</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Support procedure numbers 1-10 are reserved for the BRIN internal
- functions, so the SQL level functions start with number 11. Support
- function number 11 is the main function required to build the index.
- It should accept one argument with the same data type as the operator class,
- and return a hash of the value.
- </para>
-
- <para>
- The minmax-multi operator class is also intended for data types implementing
- a totally ordered set, and may be seen as a simple extension of the minmax
- operator class. While minmax operator class summarizes values from each block
- range into a single contiguous interval, minmax-multi allows summarization
- into multiple smaller intervals to improve handling of outlier values.
- It is possible to use the minmax-multi support procedures alongside the
- corresponding operators, as shown in
- <xref linkend="brin-extensibility-minmax-multi-table"/>.
- All operator class members (procedures and operators) are mandatory.
- </para>
-
- <table id="brin-extensibility-minmax-multi-table">
- <title>Procedure and Support Numbers for minmax-multi Operator Classes</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Operator class member</entry>
- <entry>Object</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>Support Procedure 1</entry>
- <entry>internal function <function>brin_minmax_multi_opcinfo()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 2</entry>
- <entry>internal function <function>brin_minmax_multi_add_value()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 3</entry>
- <entry>internal function <function>brin_minmax_multi_consistent()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 4</entry>
- <entry>internal function <function>brin_minmax_multi_union()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 5</entry>
- <entry>internal function <function>brin_minmax_multi_options()</function></entry>
- </row>
- <row>
- <entry>Support Procedure 11</entry>
- <entry>function to compute distance between two values (length of a range)</entry>
- </row>
- <row>
- <entry>Operator Strategy 1</entry>
- <entry>operator less-than</entry>
- </row>
- <row>
- <entry>Operator Strategy 2</entry>
- <entry>operator less-than-or-equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 3</entry>
- <entry>operator equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 4</entry>
- <entry>operator greater-than-or-equal-to</entry>
- </row>
- <row>
- <entry>Operator Strategy 5</entry>
- <entry>operator greater-than</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Both minmax and inclusion operator classes support cross-data-type
- operators, though with these the dependencies become more complicated.
- The minmax operator class requires a full set of operators to be
- defined with both arguments having the same data type. It allows
- additional data types to be supported by defining extra sets
- of operators. Inclusion operator class operator strategies are dependent
- on another operator strategy as shown in
- <xref linkend="brin-extensibility-inclusion-table"/>, or the same
- operator strategy as themselves. They require the dependency
- operator to be defined with the <literal>STORAGE</literal> data type as the
- left-hand-side argument and the other supported data type to be the
- right-hand-side argument of the supported operator. See
- <literal>float4_minmax_ops</literal> as an example of minmax, and
- <literal>box_inclusion_ops</literal> as an example of inclusion.
- </para>
-</sect1>
-</chapter>
diff --git a/doc/src/sgml/btree.sgml b/doc/src/sgml/btree.sgml
deleted file mode 100644
index be8210286b..0000000000
--- a/doc/src/sgml/btree.sgml
+++ /dev/null
@@ -1,914 +0,0 @@
-<!-- doc/src/sgml/btree.sgml -->
-
-<chapter id="btree">
-<title>B-Tree Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>B-Tree</secondary>
- </indexterm>
-
-<sect1 id="btree-intro">
- <title>Introduction</title>
-
- <para>
- <productname>PostgreSQL</productname> includes an implementation of the
- standard <acronym>btree</acronym> (multi-way balanced tree) index data
- structure. Any data type that can be sorted into a well-defined linear
- order can be indexed by a btree index. The only limitation is that an
- index entry cannot exceed approximately one-third of a page (after TOAST
- compression, if applicable).
- </para>
-
- <para>
- Because each btree operator class imposes a sort order on its data type,
- btree operator classes (or, really, operator families) have come to be
- used as <productname>PostgreSQL</productname>'s general representation
- and understanding of sorting semantics. Therefore, they've acquired
- some features that go beyond what would be needed just to support btree
- indexes, and parts of the system that are quite distant from the
- btree <acronym>AM</acronym> make use of them.
- </para>
-
-</sect1>
-
-<sect1 id="btree-behavior">
- <title>Behavior of B-Tree Operator Classes</title>
-
- <para>
- As shown in <xref linkend="xindex-btree-strat-table"/>, a btree operator
- class must provide five comparison operators,
- <literal><</literal>,
- <literal><=</literal>,
- <literal>=</literal>,
- <literal>>=</literal> and
- <literal>></literal>.
- One might expect that <literal><></literal> should also be part of
- the operator class, but it is not, because it would almost never be
- useful to use a <literal><></literal> WHERE clause in an index
- search. (For some purposes, the planner treats <literal><></literal>
- as associated with a btree operator class; but it finds that operator via
- the <literal>=</literal> operator's negator link, rather than
- from <structname>pg_amop</structname>.)
- </para>
-
- <para>
- When several data types share near-identical sorting semantics, their
- operator classes can be grouped into an operator family. Doing so is
- advantageous because it allows the planner to make deductions about
- cross-type comparisons. Each operator class within the family should
- contain the single-type operators (and associated support functions)
- for its input data type, while cross-type comparison operators and
- support functions are <quote>loose</quote> in the family. It is
- recommendable that a complete set of cross-type operators be included
- in the family, thus ensuring that the planner can represent any
- comparison conditions that it deduces from transitivity.
- </para>
-
- <para>
- There are some basic assumptions that a btree operator family must
- satisfy:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- An <literal>=</literal> operator must be an equivalence relation; that
- is, for all non-null values <replaceable>A</replaceable>,
- <replaceable>B</replaceable>, <replaceable>C</replaceable> of the
- data type:
-
- <itemizedlist>
- <listitem>
- <para>
- <replaceable>A</replaceable> <literal>=</literal>
- <replaceable>A</replaceable> is true
- (<firstterm>reflexive law</firstterm>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <replaceable>A</replaceable> <literal>=</literal>
- <replaceable>B</replaceable>,
- then <replaceable>B</replaceable> <literal>=</literal>
- <replaceable>A</replaceable>
- (<firstterm>symmetric law</firstterm>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <replaceable>A</replaceable> <literal>=</literal>
- <replaceable>B</replaceable> and <replaceable>B</replaceable>
- <literal>=</literal> <replaceable>C</replaceable>,
- then <replaceable>A</replaceable> <literal>=</literal>
- <replaceable>C</replaceable>
- (<firstterm>transitive law</firstterm>)
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
-
- <listitem>
- <para>
- A <literal><</literal> operator must be a strong ordering relation;
- that is, for all non-null values <replaceable>A</replaceable>,
- <replaceable>B</replaceable>, <replaceable>C</replaceable>:
-
- <itemizedlist>
- <listitem>
- <para>
- <replaceable>A</replaceable> <literal><</literal>
- <replaceable>A</replaceable> is false
- (<firstterm>irreflexive law</firstterm>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <replaceable>A</replaceable> <literal><</literal>
- <replaceable>B</replaceable>
- and <replaceable>B</replaceable> <literal><</literal>
- <replaceable>C</replaceable>,
- then <replaceable>A</replaceable> <literal><</literal>
- <replaceable>C</replaceable>
- (<firstterm>transitive law</firstterm>)
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
-
- <listitem>
- <para>
- Furthermore, the ordering is total; that is, for all non-null
- values <replaceable>A</replaceable>, <replaceable>B</replaceable>:
-
- <itemizedlist>
- <listitem>
- <para>
- exactly one of <replaceable>A</replaceable> <literal><</literal>
- <replaceable>B</replaceable>, <replaceable>A</replaceable>
- <literal>=</literal> <replaceable>B</replaceable>, and
- <replaceable>B</replaceable> <literal><</literal>
- <replaceable>A</replaceable> is true
- (<firstterm>trichotomy law</firstterm>)
- </para>
- </listitem>
- </itemizedlist>
-
- (The trichotomy law justifies the definition of the comparison support
- function, of course.)
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The other three operators are defined in terms of <literal>=</literal>
- and <literal><</literal> in the obvious way, and must act consistently
- with them.
- </para>
-
- <para>
- For an operator family supporting multiple data types, the above laws must
- hold when <replaceable>A</replaceable>, <replaceable>B</replaceable>,
- <replaceable>C</replaceable> are taken from any data types in the family.
- The transitive laws are the trickiest to ensure, as in cross-type
- situations they represent statements that the behaviors of two or three
- different operators are consistent.
- As an example, it would not work to put <type>float8</type>
- and <type>numeric</type> into the same operator family, at least not with
- the current semantics that <type>numeric</type> values are converted
- to <type>float8</type> for comparison to a <type>float8</type>. Because
- of the limited accuracy of <type>float8</type>, this means there are
- distinct <type>numeric</type> values that will compare equal to the
- same <type>float8</type> value, and thus the transitive law would fail.
- </para>
-
- <para>
- Another requirement for a multiple-data-type family is that any implicit
- or binary-coercion casts that are defined between data types included in
- the operator family must not change the associated sort ordering.
- </para>
-
- <para>
- It should be fairly clear why a btree index requires these laws to hold
- within a single data type: without them there is no ordering to arrange
- the keys with. Also, index searches using a comparison key of a
- different data type require comparisons to behave sanely across two
- data types. The extensions to three or more data types within a family
- are not strictly required by the btree index mechanism itself, but the
- planner relies on them for optimization purposes.
- </para>
-
-</sect1>
-
-<sect1 id="btree-support-funcs">
- <title>B-Tree Support Functions</title>
-
- <para>
- As shown in <xref linkend="xindex-btree-support-table"/>, btree defines
- one required and four optional support functions. The five
- user-defined methods are:
- </para>
- <variablelist>
- <varlistentry>
- <term><function>order</function></term>
- <listitem>
- <para>
- For each combination of data types that a btree operator family
- provides comparison operators for, it must provide a comparison
- support function, registered in
- <structname>pg_amproc</structname> with support function number 1
- and
- <structfield>amproclefttype</structfield>/<structfield>amprocrighttype</structfield>
- equal to the left and right data types for the comparison (i.e.,
- the same data types that the matching operators are registered
- with in <structname>pg_amop</structname>). The comparison
- function must take two non-null values
- <replaceable>A</replaceable> and <replaceable>B</replaceable> and
- return an <type>int32</type> value that is
- <literal><</literal> <literal>0</literal>,
- <literal>0</literal>, or <literal>></literal>
- <literal>0</literal> when <replaceable>A</replaceable>
- <literal><</literal> <replaceable>B</replaceable>,
- <replaceable>A</replaceable> <literal>=</literal>
- <replaceable>B</replaceable>, or <replaceable>A</replaceable>
- <literal>></literal> <replaceable>B</replaceable>,
- respectively. A null result is disallowed: all values of the
- data type must be comparable. See
- <filename>src/backend/access/nbtree/nbtcompare.c</filename> for
- examples.
- </para>
-
- <para>
- If the compared values are of a collatable data type, the
- appropriate collation OID will be passed to the comparison
- support function, using the standard
- <function>PG_GET_COLLATION()</function> mechanism.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><function>sortsupport</function></term>
- <listitem>
- <para>
- Optionally, a btree operator family may provide <firstterm>sort
- support</firstterm> function(s), registered under support
- function number 2. These functions allow implementing
- comparisons for sorting purposes in a more efficient way than
- naively calling the comparison support function. The APIs
- involved in this are defined in
- <filename>src/include/utils/sortsupport.h</filename>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><function>in_range</function></term>
- <listitem>
- <indexterm>
- <primary>in_range support functions</primary>
- </indexterm>
-
- <indexterm>
- <primary>support functions</primary>
- <secondary>in_range</secondary>
- </indexterm>
- <para>
- Optionally, a btree operator family may provide
- <firstterm>in_range</firstterm> support function(s), registered
- under support function number 3. These are not used during btree
- index operations; rather, they extend the semantics of the
- operator family so that it can support window clauses containing
- the <literal>RANGE</literal> <replaceable>offset</replaceable>
- <literal>PRECEDING</literal> and <literal>RANGE</literal>
- <replaceable>offset</replaceable> <literal>FOLLOWING</literal>
- frame bound types (see <xref
- linkend="syntax-window-functions"/>). Fundamentally, the extra
- information provided is how to add or subtract an
- <replaceable>offset</replaceable> value in a way that is
- compatible with the family's data ordering.
- </para>
-
- <para>
- An <function>in_range</function> function must have the signature
-<synopsis>
-in_range(<replaceable>val</replaceable> type1, <replaceable>base</replaceable> type1, <replaceable>offset</replaceable> type2, <replaceable>sub</replaceable> bool, <replaceable>less</replaceable> bool)
-returns bool
-</synopsis>
- <replaceable>val</replaceable> and
- <replaceable>base</replaceable> must be of the same type, which
- is one of the types supported by the operator family (i.e., a
- type for which it provides an ordering). However,
- <replaceable>offset</replaceable> could be of a different type,
- which might be one otherwise unsupported by the family. An
- example is that the built-in <literal>time_ops</literal> family
- provides an <function>in_range</function> function that has
- <replaceable>offset</replaceable> of type <type>interval</type>.
- A family can provide <function>in_range</function> functions for
- any of its supported types and one or more
- <replaceable>offset</replaceable> types. Each
- <function>in_range</function> function should be entered in
- <structname>pg_amproc</structname> with
- <structfield>amproclefttype</structfield> equal to
- <type>type1</type> and <structfield>amprocrighttype</structfield>
- equal to <type>type2</type>.
- </para>
-
- <para>
- The essential semantics of an <function>in_range</function>
- function depend on the two Boolean flag parameters. It should
- add or subtract <replaceable>base</replaceable> and
- <replaceable>offset</replaceable>, then compare
- <replaceable>val</replaceable> to the result, as follows:
- <itemizedlist>
- <listitem>
- <para>
- if <literal>!</literal><replaceable>sub</replaceable> and
- <literal>!</literal><replaceable>less</replaceable>, return
- <replaceable>val</replaceable> <literal>>=</literal>
- (<replaceable>base</replaceable> <literal>+</literal>
- <replaceable>offset</replaceable>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <literal>!</literal><replaceable>sub</replaceable> and
- <replaceable>less</replaceable>, return
- <replaceable>val</replaceable> <literal><=</literal>
- (<replaceable>base</replaceable> <literal>+</literal>
- <replaceable>offset</replaceable>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <replaceable>sub</replaceable> and
- <literal>!</literal><replaceable>less</replaceable>, return
- <replaceable>val</replaceable> <literal>>=</literal>
- (<replaceable>base</replaceable> <literal>-</literal>
- <replaceable>offset</replaceable>)
- </para>
- </listitem>
- <listitem>
- <para>
- if <replaceable>sub</replaceable> and
- <replaceable>less</replaceable>, return
- <replaceable>val</replaceable> <literal><=</literal>
- (<replaceable>base</replaceable> <literal>-</literal>
- <replaceable>offset</replaceable>)
- </para>
- </listitem>
- </itemizedlist>
- Before doing so, the function should check the sign of
- <replaceable>offset</replaceable>: if it is less than zero, raise
- error
- <literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal>
- (22013) with error text like <quote>invalid preceding or
- following size in window function</quote>. (This is required by
- the SQL standard, although nonstandard operator families might
- perhaps choose to ignore this restriction, since there seems to
- be little semantic necessity for it.) This requirement is
- delegated to the <function>in_range</function> function so that
- the core code needn't understand what <quote>less than
- zero</quote> means for a particular data type.
- </para>
-
- <para>
- An additional expectation is that <function>in_range</function>
- functions should, if practical, avoid throwing an error if
- <replaceable>base</replaceable> <literal>+</literal>
- <replaceable>offset</replaceable> or
- <replaceable>base</replaceable> <literal>-</literal>
- <replaceable>offset</replaceable> would overflow. The correct
- comparison result can be determined even if that value would be
- out of the data type's range. Note that if the data type
- includes concepts such as <quote>infinity</quote> or
- <quote>NaN</quote>, extra care may be needed to ensure that
- <function>in_range</function>'s results agree with the normal
- sort order of the operator family.
- </para>
-
- <para>
- The results of the <function>in_range</function> function must be
- consistent with the sort ordering imposed by the operator family.
- To be precise, given any fixed values of
- <replaceable>offset</replaceable> and
- <replaceable>sub</replaceable>, then:
- <itemizedlist>
- <listitem>
- <para>
- If <function>in_range</function> with
- <replaceable>less</replaceable> = true is true for some
- <replaceable>val1</replaceable> and
- <replaceable>base</replaceable>, it must be true for every
- <replaceable>val2</replaceable> <literal><=</literal>
- <replaceable>val1</replaceable> with the same
- <replaceable>base</replaceable>.
- </para>
- </listitem>
- <listitem>
- <para>
- If <function>in_range</function> with
- <replaceable>less</replaceable> = true is false for some
- <replaceable>val1</replaceable> and
- <replaceable>base</replaceable>, it must be false for every
- <replaceable>val2</replaceable> <literal>>=</literal>
- <replaceable>val1</replaceable> with the same
- <replaceable>base</replaceable>.
- </para>
- </listitem>
- <listitem>
- <para>
- If <function>in_range</function> with
- <replaceable>less</replaceable> = true is true for some
- <replaceable>val</replaceable> and
- <replaceable>base1</replaceable>, it must be true for every
- <replaceable>base2</replaceable> <literal>>=</literal>
- <replaceable>base1</replaceable> with the same
- <replaceable>val</replaceable>.
- </para>
- </listitem>
- <listitem>
- <para>
- If <function>in_range</function> with
- <replaceable>less</replaceable> = true is false for some
- <replaceable>val</replaceable> and
- <replaceable>base1</replaceable>, it must be false for every
- <replaceable>base2</replaceable> <literal><=</literal>
- <replaceable>base1</replaceable> with the same
- <replaceable>val</replaceable>.
- </para>
- </listitem>
- </itemizedlist>
- Analogous statements with inverted conditions hold when
- <replaceable>less</replaceable> = false.
- </para>
-
- <para>
- If the type being ordered (<type>type1</type>) is collatable, the
- appropriate collation OID will be passed to the
- <function>in_range</function> function, using the standard
- PG_GET_COLLATION() mechanism.
- </para>
-
- <para>
- <function>in_range</function> functions need not handle NULL
- inputs, and typically will be marked strict.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><function>equalimage</function></term>
- <listitem>
- <para>
- Optionally, a btree operator family may provide
- <function>equalimage</function> (<quote>equality implies image
- equality</quote>) support functions, registered under support
- function number 4. These functions allow the core code to
- determine when it is safe to apply the btree deduplication
- optimization. Currently, <function>equalimage</function>
- functions are only called when building or rebuilding an index.
- </para>
- <para>
- An <function>equalimage</function> function must have the
- signature
-<synopsis>
-equalimage(<replaceable>opcintype</replaceable> <type>oid</type>) returns bool
-</synopsis>
- The return value is static information about an operator class
- and collation. Returning <literal>true</literal> indicates that
- the <function>order</function> function for the operator class is
- guaranteed to only return <literal>0</literal> (<quote>arguments
- are equal</quote>) when its <replaceable>A</replaceable> and
- <replaceable>B</replaceable> arguments are also interchangeable
- without any loss of semantic information. Not registering an
- <function>equalimage</function> function or returning
- <literal>false</literal> indicates that this condition cannot be
- assumed to hold.
- </para>
- <para>
- The <replaceable>opcintype</replaceable> argument is the
- <literal><structname>pg_type</structname>.oid</literal> of the
- data type that the operator class indexes. This is a convenience
- that allows reuse of the same underlying
- <function>equalimage</function> function across operator classes.
- If <replaceable>opcintype</replaceable> is a collatable data
- type, the appropriate collation OID will be passed to the
- <function>equalimage</function> function, using the standard
- <function>PG_GET_COLLATION()</function> mechanism.
- </para>
- <para>
- As far as the operator class is concerned, returning
- <literal>true</literal> indicates that deduplication is safe (or
- safe for the collation whose OID was passed to its
- <function>equalimage</function> function). However, the core
- code will only deem deduplication safe for an index when
- <emphasis>every</emphasis> indexed column uses an operator class
- that registers an <function>equalimage</function> function, and
- each function actually returns <literal>true</literal> when
- called.
- </para>
- <para>
- Image equality is <emphasis>almost</emphasis> the same condition
- as simple bitwise equality. There is one subtle difference: When
- indexing a varlena data type, the on-disk representation of two
- image equal datums may not be bitwise equal due to inconsistent
- application of <acronym>TOAST</acronym> compression on input.
- Formally, when an operator class's
- <function>equalimage</function> function returns
- <literal>true</literal>, it is safe to assume that the
- <literal>datum_image_eq()</literal> C function will always agree
- with the operator class's <function>order</function> function
- (provided that the same collation OID is passed to both the
- <function>equalimage</function> and <function>order</function>
- functions).
- </para>
- <para>
- The core code is fundamentally unable to deduce anything about
- the <quote>equality implies image equality</quote> status of an
- operator class within a multiple-data-type family based on
- details from other operator classes in the same family. Also, it
- is not sensible for an operator family to register a cross-type
- <function>equalimage</function> function, and attempting to do so
- will result in an error. This is because <quote>equality implies
- image equality</quote> status does not just depend on
- sorting/equality semantics, which are more or less defined at the
- operator family level. In general, the semantics that one
- particular data type implements must be considered separately.
- </para>
- <para>
- The convention followed by the operator classes included with the
- core <productname>PostgreSQL</productname> distribution is to
- register a stock, generic <function>equalimage</function>
- function. Most operator classes register
- <function>btequalimage()</function>, which indicates that
- deduplication is safe unconditionally. Operator classes for
- collatable data types such as <type>text</type> register
- <function>btvarstrequalimage()</function>, which indicates that
- deduplication is safe with deterministic collations. Best
- practice for third-party extensions is to register their own
- custom function to retain control.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><function>options</function></term>
- <listitem>
- <para>
- Optionally, a B-tree operator family may provide
- <function>options</function> (<quote>operator class specific
- options</quote>) support functions, registered under support
- function number 5. These functions define a set of user-visible
- parameters that control operator class behavior.
- </para>
- <para>
- An <function>options</function> support function must have the
- signature
-<synopsis>
-options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns void
-</synopsis>
- The function is passed a pointer to a <structname>local_relopts</structname>
- struct, which needs to be filled with a set of operator class
- specific options. The options can be accessed from other support
- functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
- <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
- </para>
- <para>
- Currently, no B-Tree operator class has an <function>options</function>
- support function. B-tree doesn't allow flexible representation of keys
- like GiST, SP-GiST, GIN and BRIN do. So, <function>options</function>
- probably doesn't have much application in the current B-tree index
- access method. Nevertheless, this support function was added to B-tree
- for uniformity, and will probably find uses during further
- evolution of B-tree in <productname>PostgreSQL</productname>.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
-</sect1>
-
-<sect1 id="btree-implementation">
- <title>Implementation</title>
-
- <para>
- This section covers B-Tree index implementation details that may be
- of use to advanced users. See
- <filename>src/backend/access/nbtree/README</filename> in the source
- distribution for a much more detailed, internals-focused description
- of the B-Tree implementation.
- </para>
- <sect2 id="btree-structure">
- <title>B-Tree Structure</title>
- <para>
- <productname>PostgreSQL</productname> B-Tree indexes are
- multi-level tree structures, where each level of the tree can be
- used as a doubly-linked list of pages. A single metapage is stored
- in a fixed position at the start of the first segment file of the
- index. All other pages are either leaf pages or internal pages.
- Leaf pages are the pages on the lowest level of the tree. All
- other levels consist of internal pages. Each leaf page contains
- tuples that point to table rows. Each internal page contains
- tuples that point to the next level down in the tree. Typically,
- over 99% of all pages are leaf pages. Both internal pages and leaf
- pages use the standard page format described in <xref
- linkend="storage-page-layout"/>.
- </para>
- <para>
- New leaf pages are added to a B-Tree index when an existing leaf
- page cannot fit an incoming tuple. A <firstterm>page
- split</firstterm> operation makes room for items that originally
- belonged on the overflowing page by moving a portion of the items
- to a new page. Page splits must also insert a new
- <firstterm>downlink</firstterm> to the new page in the parent page,
- which may cause the parent to split in turn. Page splits
- <quote>cascade upwards</quote> in a recursive fashion. When the
- root page finally cannot fit a new downlink, a <firstterm>root page
- split</firstterm> operation takes place. This adds a new level to
- the tree structure by creating a new root page that is one level
- above the original root page.
- </para>
- </sect2>
-
- <sect2 id="btree-deletion">
- <title>Bottom-up Index Deletion</title>
- <para>
- B-Tree indexes are not directly aware that under MVCC, there might
- be multiple extant versions of the same logical table row; to an
- index, each tuple is an independent object that needs its own index
- entry. <quote>Version churn</quote> tuples may sometimes
- accumulate and adversely affect query latency and throughput. This
- typically occurs with <command>UPDATE</command>-heavy workloads
- where most individual updates cannot apply the
- <link linkend="storage-hot"><acronym>HOT</acronym> optimization.</link>
- Changing the value of only
- one column covered by one index during an <command>UPDATE</command>
- <emphasis>always</emphasis> necessitates a new set of index tuples
- — one for <emphasis>each and every</emphasis> index on the
- table. Note in particular that this includes indexes that were not
- <quote>logically modified</quote> by the <command>UPDATE</command>.
- All indexes will need a successor physical index tuple that points
- to the latest version in the table. Each new tuple within each
- index will generally need to coexist with the original
- <quote>updated</quote> tuple for a short period of time (typically
- until shortly after the <command>UPDATE</command> transaction
- commits).
- </para>
- <para>
- B-Tree indexes incrementally delete version churn index tuples by
- performing <firstterm>bottom-up index deletion</firstterm> passes.
- Each deletion pass is triggered in reaction to an anticipated
- <quote>version churn page split</quote>. This only happens with
- indexes that are not logically modified by
- <command>UPDATE</command> statements, where concentrated build up
- of obsolete versions in particular pages would occur otherwise. A
- page split will usually be avoided, though it's possible that
- certain implementation-level heuristics will fail to identify and
- delete even one garbage index tuple (in which case a page split or
- deduplication pass resolves the issue of an incoming new tuple not
- fitting on a leaf page). The worst-case number of versions that
- any index scan must traverse (for any single logical row) is an
- important contributor to overall system responsiveness and
- throughput. A bottom-up index deletion pass targets suspected
- garbage tuples in a single leaf page based on
- <emphasis>qualitative</emphasis> distinctions involving logical
- rows and versions. This contrasts with the <quote>top-down</quote>
- index cleanup performed by autovacuum workers, which is triggered
- when certain <emphasis>quantitative</emphasis> table-level
- thresholds are exceeded (see <xref linkend="autovacuum"/>).
- </para>
- <note>
- <para>
- Not all deletion operations that are performed within B-Tree
- indexes are bottom-up deletion operations. There is a distinct
- category of index tuple deletion: <firstterm>simple index tuple
- deletion</firstterm>. This is a deferred maintenance operation
- that deletes index tuples that are known to be safe to delete
- (those whose item identifier's <literal>LP_DEAD</literal> bit is
- already set). Like bottom-up index deletion, simple index
- deletion takes place at the point that a page split is anticipated
- as a way of avoiding the split.
- </para>
- <para>
- Simple deletion is opportunistic in the sense that it can only
- take place when recent index scans set the
- <literal>LP_DEAD</literal> bits of affected items in passing.
- Prior to <productname>PostgreSQL</productname> 14, the only
- category of B-Tree deletion was simple deletion. The main
- differences between it and bottom-up deletion are that only the
- former is opportunistically driven by the activity of passing
- index scans, while only the latter specifically targets version
- churn from <command>UPDATE</command>s that do not logically modify
- indexed columns.
- </para>
- </note>
- <para>
- Bottom-up index deletion performs the vast majority of all garbage
- index tuple cleanup for particular indexes with certain workloads.
- This is expected with any B-Tree index that is subject to
- significant version churn from <command>UPDATE</command>s that
- rarely or never logically modify the columns that the index covers.
- The average and worst-case number of versions per logical row can
- be kept low purely through targeted incremental deletion passes.
- It's quite possible that the on-disk size of certain indexes will
- never increase by even one single page/block despite
- <emphasis>constant</emphasis> version churn from
- <command>UPDATE</command>s. Even then, an exhaustive <quote>clean
- sweep</quote> by a <command>VACUUM</command> operation (typically
- run in an autovacuum worker process) will eventually be required as
- a part of <emphasis>collective</emphasis> cleanup of the table and
- each of its indexes.
- </para>
- <para>
- Unlike <command>VACUUM</command>, bottom-up index deletion does not
- provide any strong guarantees about how old the oldest garbage
- index tuple may be. No index can be permitted to retain
- <quote>floating garbage</quote> index tuples that became dead prior
- to a conservative cutoff point shared by the table and all of its
- indexes collectively. This fundamental table-level invariant makes
- it safe to recycle table <acronym>TID</acronym>s. This is how it
- is possible for distinct logical rows to reuse the same table
- <acronym>TID</acronym> over time (though this can never happen with
- two logical rows whose lifetimes span the same
- <command>VACUUM</command> cycle).
- </para>
- </sect2>
-
- <sect2 id="btree-deduplication">
- <title>Deduplication</title>
- <para>
- A duplicate is a leaf page tuple (a tuple that points to a table
- row) where <emphasis>all</emphasis> indexed key columns have values
- that match corresponding column values from at least one other leaf
- page tuple in the same index. Duplicate tuples are quite common in
- practice. B-Tree indexes can use a special, space-efficient
- representation for duplicates when an optional technique is
- enabled: <firstterm>deduplication</firstterm>.
- </para>
- <para>
- Deduplication works by periodically merging groups of duplicate
- tuples together, forming a single <firstterm>posting list</firstterm> tuple for each
- group. The column key value(s) only appear once in this
- representation. This is followed by a sorted array of
- <acronym>TID</acronym>s that point to rows in the table. This
- significantly reduces the storage size of indexes where each value
- (or each distinct combination of column values) appears several
- times on average. The latency of queries can be reduced
- significantly. Overall query throughput may increase
- significantly. The overhead of routine index vacuuming may also be
- reduced significantly.
- </para>
- <note>
- <para>
- B-Tree deduplication is just as effective with
- <quote>duplicates</quote> that contain a NULL value, even though
- NULL values are never equal to each other according to the
- <literal>=</literal> member of any B-Tree operator class. As far
- as any part of the implementation that understands the on-disk
- B-Tree structure is concerned, NULL is just another value from the
- domain of indexed values.
- </para>
- </note>
- <para>
- The deduplication process occurs lazily, when a new item is
- inserted that cannot fit on an existing leaf page, though only when
- index tuple deletion could not free sufficient space for the new
- item (typically deletion is briefly considered and then skipped
- over). Unlike GIN posting list tuples, B-Tree posting list tuples
- do not need to expand every time a new duplicate is inserted; they
- are merely an alternative physical representation of the original
- logical contents of the leaf page. This design prioritizes
- consistent performance with mixed read-write workloads. Most
- client applications will at least see a moderate performance
- benefit from using deduplication. Deduplication is enabled by
- default.
- </para>
- <para>
- <command>CREATE INDEX</command> and <command>REINDEX</command>
- apply deduplication to create posting list tuples, though the
- strategy they use is slightly different. Each group of duplicate
- ordinary tuples encountered in the sorted input taken from the
- table is merged into a posting list tuple
- <emphasis>before</emphasis> being added to the current pending leaf
- page. Individual posting list tuples are packed with as many
- <acronym>TID</acronym>s as possible. Leaf pages are written out in
- the usual way, without any separate deduplication pass. This
- strategy is well-suited to <command>CREATE INDEX</command> and
- <command>REINDEX</command> because they are once-off batch
- operations.
- </para>
- <para>
- Write-heavy workloads that don't benefit from deduplication due to
- having few or no duplicate values in indexes will incur a small,
- fixed performance penalty (unless deduplication is explicitly
- disabled). The <literal>deduplicate_items</literal> storage
- parameter can be used to disable deduplication within individual
- indexes. There is never any performance penalty with read-only
- workloads, since reading posting list tuples is at least as
- efficient as reading the standard tuple representation. Disabling
- deduplication isn't usually helpful.
- </para>
- <para>
- It is sometimes possible for unique indexes (as well as unique
- constraints) to use deduplication. This allows leaf pages to
- temporarily <quote>absorb</quote> extra version churn duplicates.
- Deduplication in unique indexes augments bottom-up index deletion,
- especially in cases where a long-running transaction holds a
- snapshot that blocks garbage collection. The goal is to buy time
- for the bottom-up index deletion strategy to become effective
- again. Delaying page splits until a single long-running
- transaction naturally goes away can allow a bottom-up deletion pass
- to succeed where an earlier deletion pass failed.
- </para>
- <tip>
- <para>
- A special heuristic is applied to determine whether a
- deduplication pass in a unique index should take place. It can
- often skip straight to splitting a leaf page, avoiding a
- performance penalty from wasting cycles on unhelpful deduplication
- passes. If you're concerned about the overhead of deduplication,
- consider setting <literal>deduplicate_items = off</literal>
- selectively. Leaving deduplication enabled in unique indexes has
- little downside.
- </para>
- </tip>
- <para>
- Deduplication cannot be used in all cases due to
- implementation-level restrictions. Deduplication safety is
- determined when <command>CREATE INDEX</command> or
- <command>REINDEX</command> is run.
- </para>
- <para>
- Note that deduplication is deemed unsafe and cannot be used in the
- following cases involving semantically significant differences
- among equal datums:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <type>text</type>, <type>varchar</type>, and <type>char</type>
- cannot use deduplication when a
- <emphasis>nondeterministic</emphasis> collation is used. Case
- and accent differences must be preserved among equal datums.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <type>numeric</type> cannot use deduplication. Numeric display
- scale must be preserved among equal datums.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <type>jsonb</type> cannot use deduplication, since the
- <type>jsonb</type> B-Tree operator class uses
- <type>numeric</type> internally.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <type>float4</type> and <type>float8</type> cannot use
- deduplication. These types have distinct representations for
- <literal>-0</literal> and <literal>0</literal>, which are
- nevertheless considered equal. This difference must be
- preserved.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- There is one further implementation-level restriction that may be
- lifted in a future version of
- <productname>PostgreSQL</productname>:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- Container types (such as composite types, arrays, or range
- types) cannot use deduplication.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- There is one further implementation-level restriction that applies
- regardless of the operator class or collation used:
- </para>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <literal>INCLUDE</literal> indexes can never use deduplication.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- </sect2>
-</sect1>
-
-</chapter>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index f39b4efe38..de683e3400 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -84,12 +84,7 @@
<!ENTITY catalogs SYSTEM "catalogs.sgml">
<!ENTITY system-views SYSTEM "system-views.sgml">
<!ENTITY geqo SYSTEM "geqo.sgml">
-<!ENTITY btree SYSTEM "btree.sgml">
-<!ENTITY gist SYSTEM "gist.sgml">
-<!ENTITY spgist SYSTEM "spgist.sgml">
-<!ENTITY gin SYSTEM "gin.sgml">
-<!ENTITY brin SYSTEM "brin.sgml">
-<!ENTITY hash SYSTEM "hash.sgml">
+<!ENTITY indextypes SYSTEM "indextypes.sgml">
<!ENTITY planstats SYSTEM "planstats.sgml">
<!ENTITY tableam SYSTEM "tableam.sgml">
<!ENTITY indexam SYSTEM "indexam.sgml">
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
deleted file mode 100644
index 5bd1efae92..0000000000
--- a/doc/src/sgml/gin.sgml
+++ /dev/null
@@ -1,714 +0,0 @@
-<!-- doc/src/sgml/gin.sgml -->
-
-<chapter id="gin">
-<title>GIN Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>GIN</secondary>
- </indexterm>
-
-<sect1 id="gin-intro">
- <title>Introduction</title>
-
- <para>
- <acronym>GIN</acronym> stands for Generalized Inverted Index.
- <acronym>GIN</acronym> is designed for handling cases where the items
- to be indexed are composite values, and the queries to be handled by
- the index need to search for element values that appear within
- the composite items. For example, the items could be documents,
- and the queries could be searches for documents containing specific words.
- </para>
-
- <para>
- We use the word <firstterm>item</firstterm> to refer to a composite value that
- is to be indexed, and the word <firstterm>key</firstterm> to refer to an element
- value. <acronym>GIN</acronym> always stores and searches for keys,
- not item values per se.
- </para>
-
- <para>
- A <acronym>GIN</acronym> index stores a set of (key, posting list) pairs,
- where a <firstterm>posting list</firstterm> is a set of row IDs in which the key
- occurs. The same row ID can appear in multiple posting lists, since
- an item can contain more than one key. Each key value is stored only
- once, so a <acronym>GIN</acronym> index is very compact for cases
- where the same key appears many times.
- </para>
-
- <para>
- <acronym>GIN</acronym> is generalized in the sense that the
- <acronym>GIN</acronym> access method code does not need to know the
- specific operations that it accelerates.
- Instead, it uses custom strategies defined for particular data types.
- The strategy defines how keys are extracted from indexed items and
- query conditions, and how to determine whether a row that contains
- some of the key values in a query actually satisfies the query.
- </para>
-
- <para>
- One advantage of <acronym>GIN</acronym> is that it allows the development
- of custom data types with the appropriate access methods, by
- an expert in the domain of the data type, rather than a database expert.
- This is much the same advantage as using <acronym>GiST</acronym>.
- </para>
-
- <para>
- The <acronym>GIN</acronym>
- implementation in <productname>PostgreSQL</productname> is primarily
- maintained by Teodor Sigaev and Oleg Bartunov. There is more
- information about <acronym>GIN</acronym> on their
- <ulink url="http://www.sai.msu.su/~megera/wiki/Gin">website</ulink>.
- </para>
-</sect1>
-
-<sect1 id="gin-builtin-opclasses">
- <title>Built-in Operator Classes</title>
-
- <para>
- The core <productname>PostgreSQL</productname> distribution
- includes the <acronym>GIN</acronym> operator classes shown in
- <xref linkend="gin-builtin-opclasses-table"/>.
- (Some of the optional modules described in <xref linkend="contrib"/>
- provide additional <acronym>GIN</acronym> operator classes.)
- </para>
-
- <table id="gin-builtin-opclasses-table">
- <title>Built-in <acronym>GIN</acronym> Operator Classes</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Name</entry>
- <entry>Indexable Operators</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry morerows="3" valign="middle"><literal>array_ops</literal></entry>
- <entry><literal>&& (anyarray,anyarray)</literal></entry>
- </row>
- <row>
- <entry><literal>@> (anyarray,anyarray)</literal></entry>
- </row>
- <row>
- <entry><literal><@ (anyarray,anyarray)</literal></entry>
- </row>
- <row>
- <entry><literal>= (anyarray,anyarray)</literal></entry>
- </row>
- <row>
- <entry morerows="5" valign="middle"><literal>jsonb_ops</literal></entry>
- <entry><literal>@> (jsonb,jsonb)</literal></entry>
- </row>
- <row>
- <entry><literal>@? (jsonb,jsonpath)</literal></entry>
- </row>
- <row>
- <entry><literal>@@ (jsonb,jsonpath)</literal></entry>
- </row>
- <row>
- <entry><literal>? (jsonb,text)</literal></entry>
- </row>
- <row>
- <entry><literal>?| (jsonb,text[])</literal></entry>
- </row>
- <row>
- <entry><literal>?& (jsonb,text[])</literal></entry>
- </row>
- <row>
- <entry morerows="2" valign="middle"><literal>jsonb_path_ops</literal></entry>
- <entry><literal>@> (jsonb,jsonb)</literal></entry>
- </row>
- <row>
- <entry><literal>@? (jsonb,jsonpath)</literal></entry>
- </row>
- <row>
- <entry><literal>@@ (jsonb,jsonpath)</literal></entry>
- </row>
- <row>
- <entry valign="middle"><literal>tsvector_ops</literal></entry>
- <entry><literal>@@ (tsvector,tsquery)</literal></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Of the two operator classes for type <type>jsonb</type>, <literal>jsonb_ops</literal>
- is the default. <literal>jsonb_path_ops</literal> supports fewer operators but
- offers better performance for those operators.
- See <xref linkend="json-indexing"/> for details.
- </para>
-
-</sect1>
-
-<sect1 id="gin-extensibility">
- <title>Extensibility</title>
-
- <para>
- The <acronym>GIN</acronym> interface has a high level of abstraction,
- requiring the access method implementer only to implement the semantics of
- the data type being accessed. The <acronym>GIN</acronym> layer itself
- takes care of concurrency, logging and searching the tree structure.
- </para>
-
- <para>
- All it takes to get a <acronym>GIN</acronym> access method working is to
- implement a few user-defined methods, which define the behavior of
- keys in the tree and the relationships between keys, indexed items,
- and indexable queries. In short, <acronym>GIN</acronym> combines
- extensibility with generality, code reuse, and a clean interface.
- </para>
-
- <para>
- There are two methods that an operator class for
- <acronym>GIN</acronym> must provide:
-
- <variablelist>
- <varlistentry>
- <term><function>Datum *extractValue(Datum itemValue, int32 *nkeys,
- bool **nullFlags)</function></term>
- <listitem>
- <para>
- Returns a palloc'd array of keys given an item to be indexed. The
- number of returned keys must be stored into <literal>*nkeys</literal>.
- If any of the keys can be null, also palloc an array of
- <literal>*nkeys</literal> <type>bool</type> fields, store its address at
- <literal>*nullFlags</literal>, and set these null flags as needed.
- <literal>*nullFlags</literal> can be left <symbol>NULL</symbol> (its initial value)
- if all keys are non-null.
- The return value can be <symbol>NULL</symbol> if the item contains no keys.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>Datum *extractQuery(Datum query, int32 *nkeys,
- StrategyNumber n, bool **pmatch, Pointer **extra_data,
- bool **nullFlags, int32 *searchMode)</function></term>
- <listitem>
- <para>
- Returns a palloc'd array of keys given a value to be queried; that is,
- <literal>query</literal> is the value on the right-hand side of an
- indexable operator whose left-hand side is the indexed column.
- <literal>n</literal> is the strategy number of the operator within the
- operator class (see <xref linkend="xindex-strategies"/>).
- Often, <function>extractQuery</function> will need
- to consult <literal>n</literal> to determine the data type of
- <literal>query</literal> and the method it should use to extract key values.
- The number of returned keys must be stored into <literal>*nkeys</literal>.
- If any of the keys can be null, also palloc an array of
- <literal>*nkeys</literal> <type>bool</type> fields, store its address at
- <literal>*nullFlags</literal>, and set these null flags as needed.
- <literal>*nullFlags</literal> can be left <symbol>NULL</symbol> (its initial value)
- if all keys are non-null.
- The return value can be <symbol>NULL</symbol> if the <literal>query</literal> contains no keys.
- </para>
-
- <para>
- <literal>searchMode</literal> is an output argument that allows
- <function>extractQuery</function> to specify details about how the search
- will be done.
- If <literal>*searchMode</literal> is set to
- <literal>GIN_SEARCH_MODE_DEFAULT</literal> (which is the value it is
- initialized to before call), only items that match at least one of
- the returned keys are considered candidate matches.
- If <literal>*searchMode</literal> is set to
- <literal>GIN_SEARCH_MODE_INCLUDE_EMPTY</literal>, then in addition to items
- containing at least one matching key, items that contain no keys at
- all are considered candidate matches. (This mode is useful for
- implementing is-subset-of operators, for example.)
- If <literal>*searchMode</literal> is set to <literal>GIN_SEARCH_MODE_ALL</literal>,
- then all non-null items in the index are considered candidate
- matches, whether they match any of the returned keys or not. (This
- mode is much slower than the other two choices, since it requires
- scanning essentially the entire index, but it may be necessary to
- implement corner cases correctly. An operator that needs this mode
- in most cases is probably not a good candidate for a GIN operator
- class.)
- The symbols to use for setting this mode are defined in
- <filename>access/gin.h</filename>.
- </para>
-
- <para>
- <literal>pmatch</literal> is an output argument for use when partial match
- is supported. To use it, <function>extractQuery</function> must allocate
- an array of <literal>*nkeys</literal> <type>bool</type>s and store its address at
- <literal>*pmatch</literal>. Each element of the array should be set to true
- if the corresponding key requires partial match, false if not.
- If <literal>*pmatch</literal> is set to <symbol>NULL</symbol> then GIN assumes partial match
- is not required. The variable is initialized to <symbol>NULL</symbol> before call,
- so this argument can simply be ignored by operator classes that do
- not support partial match.
- </para>
-
- <para>
- <literal>extra_data</literal> is an output argument that allows
- <function>extractQuery</function> to pass additional data to the
- <function>consistent</function> and <function>comparePartial</function> methods.
- To use it, <function>extractQuery</function> must allocate
- an array of <literal>*nkeys</literal> pointers and store its address at
- <literal>*extra_data</literal>, then store whatever it wants to into the
- individual pointers. The variable is initialized to <symbol>NULL</symbol> before
- call, so this argument can simply be ignored by operator classes that
- do not require extra data. If <literal>*extra_data</literal> is set, the
- whole array is passed to the <function>consistent</function> method, and
- the appropriate element to the <function>comparePartial</function> method.
- </para>
-
- </listitem>
- </varlistentry>
- </variablelist>
-
- An operator class must also provide a function to check if an indexed item
- matches the query. It comes in two flavors, a Boolean <function>consistent</function>
- function, and a ternary <function>triConsistent</function> function.
- <function>triConsistent</function> covers the functionality of both, so providing
- <function>triConsistent</function> alone is sufficient. However, if the Boolean
- variant is significantly cheaper to calculate, it can be advantageous to
- provide both. If only the Boolean variant is provided, some optimizations
- that depend on refuting index items before fetching all the keys are
- disabled.
-
- <variablelist>
- <varlistentry>
- <term><function>bool consistent(bool check[], StrategyNumber n, Datum query,
- int32 nkeys, Pointer extra_data[], bool *recheck,
- Datum queryKeys[], bool nullFlags[])</function></term>
- <listitem>
- <para>
- Returns true if an indexed item satisfies the query operator with
- strategy number <literal>n</literal> (or might satisfy it, if the recheck
- indication is returned). This function does not have direct access
- to the indexed item's value, since <acronym>GIN</acronym> does not
- store items explicitly. Rather, what is available is knowledge
- about which key values extracted from the query appear in a given
- indexed item. The <literal>check</literal> array has length
- <literal>nkeys</literal>, which is the same as the number of keys previously
- returned by <function>extractQuery</function> for this <literal>query</literal> datum.
- Each element of the
- <literal>check</literal> array is true if the indexed item contains the
- corresponding query key, i.e., if (check[i] == true) the i-th key of the
- <function>extractQuery</function> result array is present in the indexed item.
- The original <literal>query</literal> datum is
- passed in case the <function>consistent</function> method needs to consult it,
- and so are the <literal>queryKeys[]</literal> and <literal>nullFlags[]</literal>
- arrays previously returned by <function>extractQuery</function>.
- <literal>extra_data</literal> is the extra-data array returned by
- <function>extractQuery</function>, or <symbol>NULL</symbol> if none.
- </para>
-
- <para>
- When <function>extractQuery</function> returns a null key in
- <literal>queryKeys[]</literal>, the corresponding <literal>check[]</literal> element
- is true if the indexed item contains a null key; that is, the
- semantics of <literal>check[]</literal> are like <literal>IS NOT DISTINCT
- FROM</literal>. The <function>consistent</function> function can examine the
- corresponding <literal>nullFlags[]</literal> element if it needs to tell
- the difference between a regular value match and a null match.
- </para>
-
- <para>
- On success, <literal>*recheck</literal> should be set to true if the heap
- tuple needs to be rechecked against the query operator, or false if
- the index test is exact. That is, a false return value guarantees
- that the heap tuple does not match the query; a true return value with
- <literal>*recheck</literal> set to false guarantees that the heap tuple does
- match the query; and a true return value with
- <literal>*recheck</literal> set to true means that the heap tuple might match
- the query, so it needs to be fetched and rechecked by evaluating the
- query operator directly against the originally indexed item.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>GinTernaryValue triConsistent(GinTernaryValue check[], StrategyNumber n, Datum query,
- int32 nkeys, Pointer extra_data[],
- Datum queryKeys[], bool nullFlags[])</function></term>
- <listitem>
- <para>
- <function>triConsistent</function> is similar to <function>consistent</function>,
- but instead of Booleans in the <literal>check</literal> vector, there are
- three possible values for each
- key: <literal>GIN_TRUE</literal>, <literal>GIN_FALSE</literal> and
- <literal>GIN_MAYBE</literal>. <literal>GIN_FALSE</literal> and <literal>GIN_TRUE</literal>
- have the same meaning as regular Boolean values, while
- <literal>GIN_MAYBE</literal> means that the presence of that key is not known.
- When <literal>GIN_MAYBE</literal> values are present, the function should only
- return <literal>GIN_TRUE</literal> if the item certainly matches whether or
- not the index item contains the corresponding query keys. Likewise, the
- function must return <literal>GIN_FALSE</literal> only if the item certainly
- does not match, whether or not it contains the <literal>GIN_MAYBE</literal>
- keys. If the result depends on the <literal>GIN_MAYBE</literal> entries, i.e.,
- the match cannot be confirmed or refuted based on the known query keys,
- the function must return <literal>GIN_MAYBE</literal>.
- </para>
- <para>
- When there are no <literal>GIN_MAYBE</literal> values in the <literal>check</literal>
- vector, a <literal>GIN_MAYBE</literal> return value is the equivalent of
- setting the <literal>recheck</literal> flag in the
- Boolean <function>consistent</function> function.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>
- In addition, GIN must have a way to sort the key values stored in the index.
- The operator class can define the sort ordering by specifying a comparison
- method:
-
- <variablelist>
- <varlistentry>
- <term><function>int compare(Datum a, Datum b)</function></term>
- <listitem>
- <para>
- Compares two keys (not indexed items!) and returns an integer less than
- zero, zero, or greater than zero, indicating whether the first key is
- less than, equal to, or greater than the second. Null keys are never
- passed to this function.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- Alternatively, if the operator class does not provide a <function>compare</function>
- method, GIN will look up the default btree operator class for the index
- key data type, and use its comparison function. It is recommended to
- specify the comparison function in a GIN operator class that is meant for
- just one data type, as looking up the btree operator class costs a few
- cycles. However, polymorphic GIN operator classes (such
- as <literal>array_ops</literal>) typically cannot specify a single comparison
- function.
- </para>
-
- <para>
- An operator class for <acronym>GIN</acronym> can optionally supply the
- following methods:
-
- <variablelist>
- <varlistentry>
- <term><function>int comparePartial(Datum partial_key, Datum key, StrategyNumber n,
- Pointer extra_data)</function></term>
- <listitem>
- <para>
- Compare a partial-match query key to an index key. Returns an integer
- whose sign indicates the result: less than zero means the index key
- does not match the query, but the index scan should continue; zero
- means that the index key does match the query; greater than zero
- indicates that the index scan should stop because no more matches
- are possible. The strategy number <literal>n</literal> of the operator
- that generated the partial match query is provided, in case its
- semantics are needed to determine when to end the scan. Also,
- <literal>extra_data</literal> is the corresponding element of the extra-data
- array made by <function>extractQuery</function>, or <symbol>NULL</symbol> if none.
- Null keys are never passed to this function.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><function>void options(local_relopts *relopts)</function></term>
- <listitem>
- <para>
- Defines a set of user-visible parameters that control operator class
- behavior.
- </para>
-
- <para>
- The <function>options</function> function is passed a pointer to a
- <structname>local_relopts</structname> struct, which needs to be
- filled with a set of operator class specific options. The options
- can be accessed from other support functions using the
- <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
- <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
- </para>
-
- <para>
- Since both key extraction of indexed values and representation of the
- key in <acronym>GIN</acronym> are flexible, they may depend on
- user-specified parameters.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>
- To support <quote>partial match</quote> queries, an operator class must
- provide the <function>comparePartial</function> method, and its
- <function>extractQuery</function> method must set the <literal>pmatch</literal>
- parameter when a partial-match query is encountered. See
- <xref linkend="gin-partial-match"/> for details.
- </para>
-
- <para>
- The actual data types of the various <literal>Datum</literal> values mentioned
- above vary depending on the operator class. The item values passed to
- <function>extractValue</function> are always of the operator class's input type, and
- all key values must be of the class's <literal>STORAGE</literal> type. The type of
- the <literal>query</literal> argument passed to <function>extractQuery</function>,
- <function>consistent</function> and <function>triConsistent</function> is whatever is the
- right-hand input type of the class member operator identified by the
- strategy number. This need not be the same as the indexed type, so long as
- key values of the correct type can be extracted from it. However, it is
- recommended that the SQL declarations of these three support functions use
- the opclass's indexed data type for the <literal>query</literal> argument, even
- though the actual type might be something else depending on the operator.
- </para>
-
-</sect1>
-
-<sect1 id="gin-implementation">
- <title>Implementation</title>
-
- <para>
- Internally, a <acronym>GIN</acronym> index contains a B-tree index
- constructed over keys, where each key is an element of one or more indexed
- items (a member of an array, for example) and where each tuple in a leaf
- page contains either a pointer to a B-tree of heap pointers (a
- <quote>posting tree</quote>), or a simple list of heap pointers (a <quote>posting
- list</quote>) when the list is small enough to fit into a single index tuple along
- with the key value. <xref linkend="gin-internals-figure"/> illustrates
- these components of a GIN index.
- </para>
-
- <para>
- As of <productname>PostgreSQL</productname> 9.1, null key values can be
- included in the index. Also, placeholder nulls are included in the index
- for indexed items that are null or contain no keys according to
- <function>extractValue</function>. This allows searches that should find empty
- items to do so.
- </para>
-
- <para>
- Multicolumn <acronym>GIN</acronym> indexes are implemented by building
- a single B-tree over composite values (column number, key value). The
- key values for different columns can be of different types.
- </para>
-
- <figure id="gin-internals-figure">
- <title>GIN Internals</title>
- <mediaobject>
- <imageobject>
- <imagedata fileref="images/gin.svg" format="SVG" width="100%"/>
- </imageobject>
- </mediaobject>
- </figure>
-
- <sect2 id="gin-fast-update">
- <title>GIN Fast Update Technique</title>
-
- <para>
- Updating a <acronym>GIN</acronym> index tends to be slow because of the
- intrinsic nature of inverted indexes: inserting or updating one heap row
- can cause many inserts into the index (one for each key extracted
- from the indexed item).
- <acronym>GIN</acronym> is capable of postponing much of this work by inserting
- new tuples into a temporary, unsorted list of pending entries.
- When the table is vacuumed or autoanalyzed, or when
- <function>gin_clean_pending_list</function> function is called, or if the
- pending list becomes larger than
- <xref linkend="guc-gin-pending-list-limit"/>, the entries are moved to the
- main <acronym>GIN</acronym> data structure using the same bulk insert
- techniques used during initial index creation. This greatly improves
- <acronym>GIN</acronym> index update speed, even counting the additional
- vacuum overhead. Moreover the overhead work can be done by a background
- process instead of in foreground query processing.
- </para>
-
- <para>
- The main disadvantage of this approach is that searches must scan the list
- of pending entries in addition to searching the regular index, and so
- a large list of pending entries will slow searches significantly.
- Another disadvantage is that, while most updates are fast, an update
- that causes the pending list to become <quote>too large</quote> will incur an
- immediate cleanup cycle and thus be much slower than other updates.
- Proper use of autovacuum can minimize both of these problems.
- </para>
-
- <para>
- If consistent response time is more important than update speed,
- use of pending entries can be disabled by turning off the
- <literal>fastupdate</literal> storage parameter for a
- <acronym>GIN</acronym> index. See <xref linkend="sql-createindex"/>
- for details.
- </para>
- </sect2>
-
- <sect2 id="gin-partial-match">
- <title>Partial Match Algorithm</title>
-
- <para>
- GIN can support <quote>partial match</quote> queries, in which the query
- does not determine an exact match for one or more keys, but the possible
- matches fall within a reasonably narrow range of key values (within the
- key sorting order determined by the <function>compare</function> support method).
- The <function>extractQuery</function> method, instead of returning a key value
- to be matched exactly, returns a key value that is the lower bound of
- the range to be searched, and sets the <literal>pmatch</literal> flag true.
- The key range is then scanned using the <function>comparePartial</function>
- method. <function>comparePartial</function> must return zero for a matching
- index key, less than zero for a non-match that is still within the range
- to be searched, or greater than zero if the index key is past the range
- that could match.
- </para>
- </sect2>
-
-</sect1>
-
-<sect1 id="gin-tips">
-<title>GIN Tips and Tricks</title>
-
- <variablelist>
- <varlistentry>
- <term>Create vs. insert</term>
- <listitem>
- <para>
- Insertion into a <acronym>GIN</acronym> index can be slow
- due to the likelihood of many keys being inserted for each item.
- So, for bulk insertions into a table it is advisable to drop the GIN
- index and recreate it after finishing bulk insertion.
- </para>
-
- <para>
- When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
- (see <xref linkend="gin-fast-update"/> for details), the penalty is
- less than when it is not. But for very large updates it may still be
- best to drop and recreate the index.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="guc-maintenance-work-mem"/></term>
- <listitem>
- <para>
- Build time for a <acronym>GIN</acronym> index is very sensitive to
- the <varname>maintenance_work_mem</varname> setting; it doesn't pay to
- skimp on work memory during index creation.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="guc-gin-pending-list-limit"/></term>
- <listitem>
- <para>
- During a series of insertions into an existing <acronym>GIN</acronym>
- index that has <literal>fastupdate</literal> enabled, the system will clean up
- the pending-entry list whenever the list grows larger than
- <varname>gin_pending_list_limit</varname>. To avoid fluctuations in observed
- response time, it's desirable to have pending-list cleanup occur in the
- background (i.e., via autovacuum). Foreground cleanup operations
- can be avoided by increasing <varname>gin_pending_list_limit</varname>
- or making autovacuum more aggressive.
- However, enlarging the threshold of the cleanup operation means that
- if a foreground cleanup does occur, it will take even longer.
- </para>
- <para>
- <varname>gin_pending_list_limit</varname> can be overridden for individual
- GIN indexes by changing storage parameters, which allows each
- GIN index to have its own cleanup threshold.
- For example, it's possible to increase the threshold only for the GIN
- index which can be updated heavily, and decrease it otherwise.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="guc-gin-fuzzy-search-limit"/></term>
- <listitem>
- <para>
- The primary goal of developing <acronym>GIN</acronym> indexes was
- to create support for highly scalable full-text search in
- <productname>PostgreSQL</productname>, and there are often situations when
- a full-text search returns a very large set of results. Moreover, this
- often happens when the query contains very frequent words, so that the
- large result set is not even useful. Since reading many
- tuples from the disk and sorting them could take a lot of time, this is
- unacceptable for production. (Note that the index search itself is very
- fast.)
- </para>
- <para>
- To facilitate controlled execution of such queries,
- <acronym>GIN</acronym> has a configurable soft upper limit on the
- number of rows returned: the
- <varname>gin_fuzzy_search_limit</varname> configuration parameter.
- It is set to 0 (meaning no limit) by default.
- If a non-zero limit is set, then the returned set is a subset of
- the whole result set, chosen at random.
- </para>
- <para>
- <quote>Soft</quote> means that the actual number of returned results
- could differ somewhat from the specified limit, depending on the query
- and the quality of the system's random number generator.
- </para>
- <para>
- From experience, values in the thousands (e.g., 5000 — 20000)
- work well.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
-</sect1>
-
-<sect1 id="gin-limit">
- <title>Limitations</title>
-
- <para>
- <acronym>GIN</acronym> assumes that indexable operators are strict. This
- means that <function>extractValue</function> will not be called at all on a null
- item value (instead, a placeholder index entry is created automatically),
- and <function>extractQuery</function> will not be called on a null query
- value either (instead, the query is presumed to be unsatisfiable). Note
- however that null key values contained within a non-null composite item
- or query value are supported.
- </para>
-</sect1>
-
-<sect1 id="gin-examples">
- <title>Examples</title>
-
- <para>
- The core <productname>PostgreSQL</productname> distribution
- includes the <acronym>GIN</acronym> operator classes previously shown in
- <xref linkend="gin-builtin-opclasses-table"/>.
- The following <filename>contrib</filename> modules also contain
- <acronym>GIN</acronym> operator classes:
-
- <variablelist>
- <varlistentry>
- <term><filename>btree_gin</filename></term>
- <listitem>
- <para>B-tree equivalent functionality for several data types</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>hstore</filename></term>
- <listitem>
- <para>Module for storing (key, value) pairs</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>intarray</filename></term>
- <listitem>
- <para>Enhanced support for <type>int[]</type></para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>pg_trgm</filename></term>
- <listitem>
- <para>Text similarity using trigram matching</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-</sect1>
-
-</chapter>
diff --git a/doc/src/sgml/gist.sgml b/doc/src/sgml/gist.sgml
deleted file mode 100644
index 8a19f156d8..0000000000
--- a/doc/src/sgml/gist.sgml
+++ /dev/null
@@ -1,1387 +0,0 @@
-<!-- doc/src/sgml/gist.sgml -->
-
-<chapter id="gist">
-<title>GiST Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>GiST</secondary>
- </indexterm>
-
-<sect1 id="gist-intro">
- <title>Introduction</title>
-
- <para>
- <acronym>GiST</acronym> stands for Generalized Search Tree. It is a
- balanced, tree-structured access method, that acts as a base template in
- which to implement arbitrary indexing schemes. B-trees, R-trees and many
- other indexing schemes can be implemented in <acronym>GiST</acronym>.
- </para>
-
- <para>
- One advantage of <acronym>GiST</acronym> is that it allows the development
- of custom data types with the appropriate access methods, by
- an expert in the domain of the data type, rather than a database expert.
- </para>
-
- <para>
- Some of the information here is derived from the University of California
- at Berkeley's GiST Indexing Project
- <ulink url="http://gist.cs.berkeley.edu/">web site</ulink> and
- Marcel Kornacker's thesis,
- <ulink url="http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/access-methods-for-next-generation.pdf.gz">
- Access Methods for Next-Generation Database Systems</ulink>.
- The <acronym>GiST</acronym>
- implementation in <productname>PostgreSQL</productname> is primarily
- maintained by Teodor Sigaev and Oleg Bartunov, and there is more
- information on their
- <ulink url="http://www.sai.msu.su/~megera/postgres/gist/">web site</ulink>.
- </para>
-
-</sect1>
-
-<sect1 id="gist-builtin-opclasses">
- <title>Built-in Operator Classes</title>
-
- <para>
- The core <productname>PostgreSQL</productname> distribution
- includes the <acronym>GiST</acronym> operator classes shown in
- <xref linkend="gist-builtin-opclasses-table"/>.
- (Some of the optional modules described in <xref linkend="contrib"/>
- provide additional <acronym>GiST</acronym> operator classes.)
- </para>
-
- <table id="gist-builtin-opclasses-table">
- <title>Built-in <acronym>GiST</acronym> Operator Classes</title>
- <tgroup cols="3">
- <colspec colname="col1" colwidth="2*"/>
- <colspec colname="col2" colwidth="3*"/>
- <colspec colname="col3" colwidth="2*"/>
- <thead>
- <row>
- <entry>Name</entry>
- <entry>Indexable Operators</entry>
- <entry>Ordering Operators</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry valign="middle" morerows="13"><literal>box_ops</literal></entry>
- <entry><literal><< (box, box)</literal></entry>
- <entry valign="middle" morerows="13"><literal><-> (box, point)</literal></entry>
- </row>
- <row><entry><literal>&< (box, box)</literal></entry></row>
- <row><entry><literal>&& (box, box)</literal></entry></row>
- <row><entry><literal>&> (box, box)</literal></entry></row>
- <row><entry><literal>>> (box, box)</literal></entry></row>
- <row><entry><literal>~= (box, box)</literal></entry></row>
- <row><entry><literal>@> (box, box)</literal></entry></row>
- <row><entry><literal><@ (box, box)</literal></entry></row>
- <row><entry><literal>&<| (box, box)</literal></entry></row>
- <row><entry><literal><<| (box, box)</literal></entry></row>
- <row><entry><literal>|>> (box, box)</literal></entry></row>
- <row><entry><literal>|&> (box, box)</literal></entry></row>
- <row><entry><literal>~ (box, box)</literal></entry></row>
- <row><entry><literal>@ (box, box)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="13"><literal>circle_ops</literal></entry>
- <entry><literal><< (circle, circle)</literal></entry>
- <entry valign="middle" morerows="13"><literal><-> (circle, point)</literal></entry>
- </row>
- <row><entry><literal>&< (circle, circle)</literal></entry></row>
- <row><entry><literal>&> (circle, circle)</literal></entry></row>
- <row><entry><literal>>> (circle, circle)</literal></entry></row>
- <row><entry><literal><@ (circle, circle)</literal></entry></row>
- <row><entry><literal>@> (circle, circle)</literal></entry></row>
- <row><entry><literal>~= (circle, circle)</literal></entry></row>
- <row><entry><literal>&& (circle, circle)</literal></entry></row>
- <row><entry><literal>|>> (circle, circle)</literal></entry></row>
- <row><entry><literal><<| (circle, circle)</literal></entry></row>
- <row><entry><literal>&<| (circle, circle)</literal></entry></row>
- <row><entry><literal>|&> (circle, circle)</literal></entry></row>
- <row><entry><literal>@ (circle, circle)</literal></entry></row>
- <row><entry><literal>~ (circle, circle)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="10"><literal>inet_ops</literal></entry>
- <entry><literal><< (inet, inet)</literal></entry>
- <entry valign="middle" morerows="10"></entry>
- </row>
- <row><entry><literal><<= (inet, inet)</literal></entry></row>
- <row><entry><literal>>> (inet, inet)</literal></entry></row>
- <row><entry><literal>>>= (inet, inet)</literal></entry></row>
- <row><entry><literal>= (inet, inet)</literal></entry></row>
- <row><entry><literal><> (inet, inet)</literal></entry></row>
- <row><entry><literal>< (inet, inet)</literal></entry></row>
- <row><entry><literal><= (inet, inet)</literal></entry></row>
- <row><entry><literal>> (inet, inet)</literal></entry></row>
- <row><entry><literal>>= (inet, inet)</literal></entry></row>
- <row><entry><literal>&& (inet, inet)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="17"><literal>multirange_ops</literal></entry>
- <entry><literal>= (anymultirange, anymultirange)</literal></entry>
- <entry valign="middle" morerows="17"></entry>
- </row>
- <row><entry><literal>&& (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>&& (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal>@> (anymultirange, anyelement)</literal></entry></row>
- <row><entry><literal>@> (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>@> (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal><@ (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal><@ (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal><< (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal><< (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal>>> (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>>> (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal>&< (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>&< (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal>&> (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>&> (anymultirange, anyrange)</literal></entry></row>
- <row><entry><literal>-|- (anymultirange, anymultirange)</literal></entry></row>
- <row><entry><literal>-|- (anymultirange, anyrange)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="7"><literal>point_ops</literal></entry>
- <entry><literal>|>> (point, point)</literal></entry>
- <entry valign="middle" morerows="7"><literal><-> (point, point)</literal></entry>
- </row>
- <row><entry><literal><< (point, point)</literal></entry></row>
- <row><entry><literal>>> (point, point)</literal></entry></row>
- <row><entry><literal><<| (point, point)</literal></entry></row>
- <row><entry><literal>~= (point, point)</literal></entry></row>
- <row><entry><literal><@ (point, box)</literal></entry></row>
- <row><entry><literal><@ (point, polygon)</literal></entry></row>
- <row><entry><literal><@ (point, circle)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="13"><literal>poly_ops</literal></entry>
- <entry><literal><< (polygon, polygon)</literal></entry>
- <entry valign="middle" morerows="13"><literal><-> (polygon, point)</literal></entry>
- </row>
- <row><entry><literal>&< (polygon, polygon)</literal></entry></row>
- <row><entry><literal>&> (polygon, polygon)</literal></entry></row>
- <row><entry><literal>>> (polygon, polygon)</literal></entry></row>
- <row><entry><literal><@ (polygon, polygon)</literal></entry></row>
- <row><entry><literal>@> (polygon, polygon)</literal></entry></row>
- <row><entry><literal>~= (polygon, polygon)</literal></entry></row>
- <row><entry><literal>&& (polygon, polygon)</literal></entry></row>
- <row><entry><literal><<| (polygon, polygon)</literal></entry></row>
- <row><entry><literal>&<| (polygon, polygon)</literal></entry></row>
- <row><entry><literal>|&> (polygon, polygon)</literal></entry></row>
- <row><entry><literal>|>> (polygon, polygon)</literal></entry></row>
- <row><entry><literal>@ (polygon, polygon)</literal></entry></row>
- <row><entry><literal>~ (polygon, polygon)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="17"><literal>range_ops</literal></entry>
- <entry><literal>= (anyrange, anyrange)</literal></entry>
- <entry valign="middle" morerows="17"></entry>
- </row>
- <row><entry><literal>&& (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>&& (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal>@> (anyrange, anyelement)</literal></entry></row>
- <row><entry><literal>@> (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>@> (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal><@ (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal><@ (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal><< (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal><< (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal>>> (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>>> (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal>&< (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>&< (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal>&> (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>&> (anyrange, anymultirange)</literal></entry></row>
- <row><entry><literal>-|- (anyrange, anyrange)</literal></entry></row>
- <row><entry><literal>-|- (anyrange, anymultirange)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="1"><literal>tsquery_ops</literal></entry>
- <entry><literal><@ (tsquery, tsquery)</literal></entry>
- <entry valign="middle" morerows="1"></entry>
- </row>
- <row><entry><literal>@> (tsquery, tsquery)</literal></entry></row>
- <row>
- <entry valign="middle"><literal>tsvector_ops</literal></entry>
- <entry><literal>@@ (tsvector, tsquery)</literal></entry>
- <entry></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- For historical reasons, the <literal>inet_ops</literal> operator class is
- not the default class for types <type>inet</type> and <type>cidr</type>.
- To use it, mention the class name in <command>CREATE INDEX</command>,
- for example
-<programlisting>
-CREATE INDEX ON my_table USING GIST (my_inet_column inet_ops);
-</programlisting>
- </para>
-
-</sect1>
-
-<sect1 id="gist-extensibility">
- <title>Extensibility</title>
-
- <para>
- Traditionally, implementing a new index access method meant a lot of
- difficult work. It was necessary to understand the inner workings of the
- database, such as the lock manager and Write-Ahead Log. The
- <acronym>GiST</acronym> interface has a high level of abstraction,
- requiring the access method implementer only to implement the semantics of
- the data type being accessed. The <acronym>GiST</acronym> layer itself
- takes care of concurrency, logging and searching the tree structure.
- </para>
-
- <para>
- This extensibility should not be confused with the extensibility of the
- other standard search trees in terms of the data they can handle. For
- example, <productname>PostgreSQL</productname> supports extensible B-trees
- and hash indexes. That means that you can use
- <productname>PostgreSQL</productname> to build a B-tree or hash over any
- data type you want. But B-trees only support range predicates
- (<literal><</literal>, <literal>=</literal>, <literal>></literal>),
- and hash indexes only support equality queries.
- </para>
-
- <para>
- So if you index, say, an image collection with a
- <productname>PostgreSQL</productname> B-tree, you can only issue queries
- such as <quote>is imagex equal to imagey</quote>, <quote>is imagex less
- than imagey</quote> and <quote>is imagex greater than imagey</quote>.
- Depending on how you define <quote>equals</quote>, <quote>less than</quote>
- and <quote>greater than</quote> in this context, this could be useful.
- However, by using a <acronym>GiST</acronym> based index, you could create
- ways to ask domain-specific questions, perhaps <quote>find all images of
- horses</quote> or <quote>find all over-exposed images</quote>.
- </para>
-
- <para>
- All it takes to get a <acronym>GiST</acronym> access method up and running
- is to implement several user-defined methods, which define the behavior of
- keys in the tree. Of course these methods have to be pretty fancy to
- support fancy queries, but for all the standard queries (B-trees,
- R-trees, etc.) they're relatively straightforward. In short,
- <acronym>GiST</acronym> combines extensibility along with generality, code
- reuse, and a clean interface.
- </para>
-
- <para>
- There are five methods that an index operator class for
- <acronym>GiST</acronym> must provide, and seven that are optional.
- Correctness of the index is ensured
- by proper implementation of the <function>same</function>, <function>consistent</function>
- and <function>union</function> methods, while efficiency (size and speed) of the
- index will depend on the <function>penalty</function> and <function>picksplit</function>
- methods.
- Two optional methods are <function>compress</function> and
- <function>decompress</function>, which allow an index to have internal tree data of
- a different type than the data it indexes. The leaves are to be of the
- indexed data type, while the other tree nodes can be of any C struct (but
- you still have to follow <productname>PostgreSQL</productname> data type rules here,
- see about <literal>varlena</literal> for variable sized data). If the tree's
- internal data type exists at the SQL level, the <literal>STORAGE</literal> option
- of the <command>CREATE OPERATOR CLASS</command> command can be used.
- The optional eighth method is <function>distance</function>, which is needed
- if the operator class wishes to support ordered scans (nearest-neighbor
- searches). The optional ninth method <function>fetch</function> is needed if the
- operator class wishes to support index-only scans, except when the
- <function>compress</function> method is omitted. The optional tenth method
- <function>options</function> is needed if the operator class has
- user-specified parameters.
- The optional eleventh method <function>sortsupport</function> is used to
- speed up building a <acronym>GiST</acronym> index.
- The optional twelfth method <function>stratnum</function> is used to
- translate well-known <literal>RT*StrategyNumber</literal>s (from
- <filename>src/include/access/stratnum.h</filename>) into strategy numbers
- used by the operator class. This lets the core code look up operators for
- temporal constraint indexes.
- </para>
-
- <variablelist>
- <varlistentry>
- <term><function>consistent</function></term>
- <listitem>
- <para>
- Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
- this function determines whether the index entry is
- <quote>consistent</quote> with the query; that is, could the predicate
- <quote><replaceable>indexed_column</replaceable>
- <replaceable>indexable_operator</replaceable> <literal>q</literal></quote> be true for
- any row represented by the index entry? For a leaf index entry this is
- equivalent to testing the indexable condition, while for an internal
- tree node this determines whether it is necessary to scan the subtree
- of the index represented by the tree node. When the result is
- <literal>true</literal>, a <literal>recheck</literal> flag must also be returned.
- This indicates whether the predicate is certainly true or only possibly
- true. If <literal>recheck</literal> = <literal>false</literal> then the index has
- tested the predicate condition exactly, whereas if <literal>recheck</literal>
- = <literal>true</literal> the row is only a candidate match. In that case the
- system will automatically evaluate the
- <replaceable>indexable_operator</replaceable> against the actual row value to see
- if it is really a match. This convention allows
- <acronym>GiST</acronym> to support both lossless and lossy index
- structures.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_consistent(internal, data_type, smallint, oid, internal)
-RETURNS bool
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_consistent);
-
-Datum
-my_consistent(PG_FUNCTION_ARGS)
-{
- GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
- data_type *query = PG_GETARG_DATA_TYPE_P(1);
- StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
- /* Oid subtype = PG_GETARG_OID(3); */
- bool *recheck = (bool *) PG_GETARG_POINTER(4);
- data_type *key = DatumGetDataType(entry->key);
- bool retval;
-
- /*
- * determine return value as a function of strategy, key and query.
- *
- * Use GIST_LEAF(entry) to know where you're called in the index tree,
- * which comes handy when supporting the = operator for example (you could
- * check for non empty union() in non-leaf nodes and equality in leaf
- * nodes).
- */
-
- *recheck = true; /* or false if check is exact */
-
- PG_RETURN_BOOL(retval);
-}
-</programlisting>
-
- Here, <varname>key</varname> is an element in the index and <varname>query</varname>
- the value being looked up in the index. The <literal>StrategyNumber</literal>
- parameter indicates which operator of your operator class is being
- applied — it matches one of the operator numbers in the
- <command>CREATE OPERATOR CLASS</command> command.
- </para>
-
- <para>
- Depending on which operators you have included in the class, the data
- type of <varname>query</varname> could vary with the operator, since it will
- be whatever type is on the right-hand side of the operator, which might
- be different from the indexed data type appearing on the left-hand side.
- (The above code skeleton assumes that only one type is possible; if
- not, fetching the <varname>query</varname> argument value would have to depend
- on the operator.) It is recommended that the SQL declaration of
- the <function>consistent</function> function use the opclass's indexed data
- type for the <varname>query</varname> argument, even though the actual type
- might be something else depending on the operator.
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>union</function></term>
- <listitem>
- <para>
- This method consolidates information in the tree. Given a set of
- entries, this function generates a new index entry that represents
- all the given entries.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_union(internal, internal)
-RETURNS storage_type
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_union);
-
-Datum
-my_union(PG_FUNCTION_ARGS)
-{
- GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
- GISTENTRY *ent = entryvec->vector;
- data_type *out,
- *tmp,
- *old;
- int numranges,
- i = 0;
-
- numranges = entryvec->n;
- tmp = DatumGetDataType(ent[0].key);
- out = tmp;
-
- if (numranges == 1)
- {
- out = data_type_deep_copy(tmp);
-
- PG_RETURN_DATA_TYPE_P(out);
- }
-
- for (i = 1; i < numranges; i++)
- {
- old = out;
- tmp = DatumGetDataType(ent[i].key);
- out = my_union_implementation(out, tmp);
- }
-
- PG_RETURN_DATA_TYPE_P(out);
-}
-</programlisting>
- </para>
-
- <para>
- As you can see, in this skeleton we're dealing with a data type
- where <literal>union(X, Y, Z) = union(union(X, Y), Z)</literal>. It's easy
- enough to support data types where this is not the case, by
- implementing the proper union algorithm in this
- <acronym>GiST</acronym> support method.
- </para>
-
- <para>
- The result of the <function>union</function> function must be a value of the
- index's storage type, whatever that is (it might or might not be
- different from the indexed column's type). The <function>union</function>
- function should return a pointer to newly <function>palloc()</function>ed
- memory. You can't just return the input value as-is, even if there is
- no type change.
- </para>
-
- <para>
- As shown above, the <function>union</function> function's
- first <type>internal</type> argument is actually
- a <structname>GistEntryVector</structname> pointer. The second argument is a
- pointer to an integer variable, which can be ignored. (It used to be
- required that the <function>union</function> function store the size of its
- result value into that variable, but this is no longer necessary.)
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>compress</function></term>
- <listitem>
- <para>
- Converts a data item into a format suitable for physical storage in
- an index page.
- If the <function>compress</function> method is omitted, data items are stored
- in the index without modification.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_compress(internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_compress);
-
-Datum
-my_compress(PG_FUNCTION_ARGS)
-{
- GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
- GISTENTRY *retval;
-
- if (entry->leafkey)
- {
- /* replace entry->key with a compressed version */
- compressed_data_type *compressed_data = palloc(sizeof(compressed_data_type));
-
- /* fill *compressed_data from entry->key ... */
-
- retval = palloc(sizeof(GISTENTRY));
- gistentryinit(*retval, PointerGetDatum(compressed_data),
- entry->rel, entry->page, entry->offset, FALSE);
- }
- else
- {
- /* typically we needn't do anything with non-leaf entries */
- retval = entry;
- }
-
- PG_RETURN_POINTER(retval);
-}
-</programlisting>
- </para>
-
- <para>
- You have to adapt <replaceable>compressed_data_type</replaceable> to the specific
- type you're converting to in order to compress your leaf nodes, of
- course.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>decompress</function></term>
- <listitem>
- <para>
- Converts the stored representation of a data item into a format that
- can be manipulated by the other GiST methods in the operator class.
- If the <function>decompress</function> method is omitted, it is assumed that
- the other GiST methods can work directly on the stored data format.
- (<function>decompress</function> is not necessarily the reverse of
- the <function>compress</function> method; in particular,
- if <function>compress</function> is lossy then it's impossible
- for <function>decompress</function> to exactly reconstruct the original
- data. <function>decompress</function> is not necessarily equivalent
- to <function>fetch</function>, either, since the other GiST methods might not
- require full reconstruction of the data.)
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_decompress(internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_decompress);
-
-Datum
-my_decompress(PG_FUNCTION_ARGS)
-{
- PG_RETURN_POINTER(PG_GETARG_POINTER(0));
-}
-</programlisting>
-
- The above skeleton is suitable for the case where no decompression
- is needed. (But, of course, omitting the method altogether is even
- easier, and is recommended in such cases.)
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>penalty</function></term>
- <listitem>
- <para>
- Returns a value indicating the <quote>cost</quote> of inserting the new
- entry into a particular branch of the tree. Items will be inserted
- down the path of least <function>penalty</function> in the tree.
- Values returned by <function>penalty</function> should be non-negative.
- If a negative value is returned, it will be treated as zero.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_penalty(internal, internal, internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT; -- in some cases penalty functions need not be strict
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_penalty);
-
-Datum
-my_penalty(PG_FUNCTION_ARGS)
-{
- GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
- GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
- float *penalty = (float *) PG_GETARG_POINTER(2);
- data_type *orig = DatumGetDataType(origentry->key);
- data_type *new = DatumGetDataType(newentry->key);
-
- *penalty = my_penalty_implementation(orig, new);
- PG_RETURN_POINTER(penalty);
-}
-</programlisting>
-
- For historical reasons, the <function>penalty</function> function doesn't
- just return a <type>float</type> result; instead it has to store the value
- at the location indicated by the third argument. The return
- value per se is ignored, though it's conventional to pass back the
- address of that argument.
- </para>
-
- <para>
- The <function>penalty</function> function is crucial to good performance of
- the index. It'll get used at insertion time to determine which branch
- to follow when choosing where to add the new entry in the tree. At
- query time, the more balanced the index, the quicker the lookup.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>picksplit</function></term>
- <listitem>
- <para>
- When an index page split is necessary, this function decides which
- entries on the page are to stay on the old page, and which are to move
- to the new page.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_picksplit(internal, internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_picksplit);
-
-Datum
-my_picksplit(PG_FUNCTION_ARGS)
-{
- GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
- GIST_SPLITVEC *v = (GIST_SPLITVEC *) PG_GETARG_POINTER(1);
- OffsetNumber maxoff = entryvec->n - 1;
- GISTENTRY *ent = entryvec->vector;
- int i,
- nbytes;
- OffsetNumber *left,
- *right;
- data_type *tmp_union;
- data_type *unionL;
- data_type *unionR;
- GISTENTRY **raw_entryvec;
-
- maxoff = entryvec->n - 1;
- nbytes = (maxoff + 1) * sizeof(OffsetNumber);
-
- v->spl_left = (OffsetNumber *) palloc(nbytes);
- left = v->spl_left;
- v->spl_nleft = 0;
-
- v->spl_right = (OffsetNumber *) palloc(nbytes);
- right = v->spl_right;
- v->spl_nright = 0;
-
- unionL = NULL;
- unionR = NULL;
-
- /* Initialize the raw entry vector. */
- raw_entryvec = (GISTENTRY **) malloc(entryvec->n * sizeof(void *));
- for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
- raw_entryvec[i] = &(entryvec->vector[i]);
-
- for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
- {
- int real_index = raw_entryvec[i] - entryvec->vector;
-
- tmp_union = DatumGetDataType(entryvec->vector[real_index].key);
- Assert(tmp_union != NULL);
-
- /*
- * Choose where to put the index entries and update unionL and unionR
- * accordingly. Append the entries to either v->spl_left or
- * v->spl_right, and care about the counters.
- */
-
- if (my_choice_is_left(unionL, curl, unionR, curr))
- {
- if (unionL == NULL)
- unionL = tmp_union;
- else
- unionL = my_union_implementation(unionL, tmp_union);
-
- *left = real_index;
- ++left;
- ++(v->spl_nleft);
- }
- else
- {
- /*
- * Same on the right
- */
- }
- }
-
- v->spl_ldatum = DataTypeGetDatum(unionL);
- v->spl_rdatum = DataTypeGetDatum(unionR);
- PG_RETURN_POINTER(v);
-}
-</programlisting>
-
- Notice that the <function>picksplit</function> function's result is delivered
- by modifying the passed-in <structname>v</structname> structure. The return
- value per se is ignored, though it's conventional to pass back the
- address of <structname>v</structname>.
- </para>
-
- <para>
- Like <function>penalty</function>, the <function>picksplit</function> function
- is crucial to good performance of the index. Designing suitable
- <function>penalty</function> and <function>picksplit</function> implementations
- is where the challenge of implementing well-performing
- <acronym>GiST</acronym> indexes lies.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>same</function></term>
- <listitem>
- <para>
- Returns true if two index entries are identical, false otherwise.
- (An <quote>index entry</quote> is a value of the index's storage type,
- not necessarily the original indexed column's type.)
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_same(storage_type, storage_type, internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_same);
-
-Datum
-my_same(PG_FUNCTION_ARGS)
-{
- prefix_range *v1 = PG_GETARG_PREFIX_RANGE_P(0);
- prefix_range *v2 = PG_GETARG_PREFIX_RANGE_P(1);
- bool *result = (bool *) PG_GETARG_POINTER(2);
-
- *result = my_eq(v1, v2);
- PG_RETURN_POINTER(result);
-}
-</programlisting>
-
- For historical reasons, the <function>same</function> function doesn't
- just return a Boolean result; instead it has to store the flag
- at the location indicated by the third argument. The return
- value per se is ignored, though it's conventional to pass back the
- address of that argument.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>distance</function></term>
- <listitem>
- <para>
- Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
- this function determines the index entry's
- <quote>distance</quote> from the query value. This function must be
- supplied if the operator class contains any ordering operators.
- A query using the ordering operator will be implemented by returning
- index entries with the smallest <quote>distance</quote> values first,
- so the results must be consistent with the operator's semantics.
- For a leaf index entry the result just represents the distance to
- the index entry; for an internal tree node, the result must be the
- smallest distance that any child entry could have.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_distance(internal, data_type, smallint, oid, internal)
-RETURNS float8
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- And the matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_distance);
-
-Datum
-my_distance(PG_FUNCTION_ARGS)
-{
- GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
- data_type *query = PG_GETARG_DATA_TYPE_P(1);
- StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
- /* Oid subtype = PG_GETARG_OID(3); */
- /* bool *recheck = (bool *) PG_GETARG_POINTER(4); */
- data_type *key = DatumGetDataType(entry->key);
- double retval;
-
- /*
- * determine return value as a function of strategy, key and query.
- */
-
- PG_RETURN_FLOAT8(retval);
-}
-</programlisting>
-
- The arguments to the <function>distance</function> function are identical to
- the arguments of the <function>consistent</function> function.
- </para>
-
- <para>
- Some approximation is allowed when determining the distance, so long
- as the result is never greater than the entry's actual distance. Thus,
- for example, distance to a bounding box is usually sufficient in
- geometric applications. For an internal tree node, the distance
- returned must not be greater than the distance to any of the child
- nodes. If the returned distance is not exact, the function must set
- <literal>*recheck</literal> to true. (This is not necessary for internal tree
- nodes; for them, the calculation is always assumed to be inexact.) In
- this case the executor will calculate the accurate distance after
- fetching the tuple from the heap, and reorder the tuples if necessary.
- </para>
-
- <para>
- If the distance function returns <literal>*recheck = true</literal> for any
- leaf node, the original ordering operator's return type must
- be <type>float8</type> or <type>float4</type>, and the distance function's
- result values must be comparable to those of the original ordering
- operator, since the executor will sort using both distance function
- results and recalculated ordering-operator results. Otherwise, the
- distance function's result values can be any finite <type>float8</type>
- values, so long as the relative order of the result values matches the
- order returned by the ordering operator. (Infinity and minus infinity
- are used internally to handle cases such as nulls, so it is not
- recommended that <function>distance</function> functions return these values.)
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>fetch</function></term>
- <listitem>
- <para>
- Converts the compressed index representation of a data item into the
- original data type, for index-only scans. The returned data must be an
- exact, non-lossy copy of the originally indexed value.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_fetch(internal)
-RETURNS internal
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- The argument is a pointer to a <structname>GISTENTRY</structname> struct. On
- entry, its <structfield>key</structfield> field contains a non-NULL leaf datum in
- compressed form. The return value is another <structname>GISTENTRY</structname>
- struct, whose <structfield>key</structfield> field contains the same datum in its
- original, uncompressed form. If the opclass's compress function does
- nothing for leaf entries, the <function>fetch</function> method can return the
- argument as-is. Or, if the opclass does not have a compress function,
- the <function>fetch</function> method can be omitted as well, since it would
- necessarily be a no-op.
- </para>
-
- <para>
- The matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_fetch);
-
-Datum
-my_fetch(PG_FUNCTION_ARGS)
-{
- GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
- input_data_type *in = DatumGetPointer(entry->key);
- fetched_data_type *fetched_data;
- GISTENTRY *retval;
-
- retval = palloc(sizeof(GISTENTRY));
- fetched_data = palloc(sizeof(fetched_data_type));
-
- /*
- * Convert 'fetched_data' into the a Datum of the original datatype.
- */
-
- /* fill *retval from fetched_data. */
- gistentryinit(*retval, PointerGetDatum(converted_datum),
- entry->rel, entry->page, entry->offset, FALSE);
-
- PG_RETURN_POINTER(retval);
-}
-</programlisting>
- </para>
-
- <para>
- If the compress method is lossy for leaf entries, the operator class
- cannot support index-only scans, and must not define
- a <function>fetch</function> function.
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>options</function></term>
- <listitem>
- <para>
- Allows definition of user-visible parameters that control operator
- class behavior.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_options(internal)
-RETURNS void
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
- </para>
-
- <para>
- The function is passed a pointer to a <structname>local_relopts</structname>
- struct, which needs to be filled with a set of operator class
- specific options. The options can be accessed from other support
- functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
- <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
- </para>
-
- <para>
- An example implementation of my_options() and parameters use
- from other support functions are given below:
-
-<programlisting>
-typedef enum MyEnumType
-{
- MY_ENUM_ON,
- MY_ENUM_OFF,
- MY_ENUM_AUTO
-} MyEnumType;
-
-typedef struct
-{
- int32 vl_len_; /* varlena header (do not touch directly!) */
- int int_param; /* integer parameter */
- double real_param; /* real parameter */
- MyEnumType enum_param; /* enum parameter */
- int str_param; /* string parameter */
-} MyOptionsStruct;
-
-/* String representation of enum values */
-static relopt_enum_elt_def myEnumValues[] =
-{
- {"on", MY_ENUM_ON},
- {"off", MY_ENUM_OFF},
- {"auto", MY_ENUM_AUTO},
- {(const char *) NULL} /* list terminator */
-};
-
-static char *str_param_default = "default";
-
-/*
- * Sample validator: checks that string is not longer than 8 bytes.
- */
-static void
-validate_my_string_relopt(const char *value)
-{
- if (strlen(value) > 8)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("str_param must be at most 8 bytes")));
-}
-
-/*
- * Sample filler: switches characters to lower case.
- */
-static Size
-fill_my_string_relopt(const char *value, void *ptr)
-{
- char *tmp = str_tolower(value, strlen(value), DEFAULT_COLLATION_OID);
- int len = strlen(tmp);
-
- if (ptr)
- strcpy((char *) ptr, tmp);
-
- pfree(tmp);
- return len + 1;
-}
-
-PG_FUNCTION_INFO_V1(my_options);
-
-Datum
-my_options(PG_FUNCTION_ARGS)
-{
- local_relopts *relopts = (local_relopts *) PG_GETARG_POINTER(0);
-
- init_local_reloptions(relopts, sizeof(MyOptionsStruct));
- add_local_int_reloption(relopts, "int_param", "integer parameter",
- 100, 0, 1000000,
- offsetof(MyOptionsStruct, int_param));
- add_local_real_reloption(relopts, "real_param", "real parameter",
- 1.0, 0.0, 1000000.0,
- offsetof(MyOptionsStruct, real_param));
- add_local_enum_reloption(relopts, "enum_param", "enum parameter",
- myEnumValues, MY_ENUM_ON,
- "Valid values are: \"on\", \"off\" and \"auto\".",
- offsetof(MyOptionsStruct, enum_param));
- add_local_string_reloption(relopts, "str_param", "string parameter",
- str_param_default,
- &validate_my_string_relopt,
- &fill_my_string_relopt,
- offsetof(MyOptionsStruct, str_param));
-
- PG_RETURN_VOID();
-}
-
-PG_FUNCTION_INFO_V1(my_compress);
-
-Datum
-my_compress(PG_FUNCTION_ARGS)
-{
- int int_param = 100;
- double real_param = 1.0;
- MyEnumType enum_param = MY_ENUM_ON;
- char *str_param = str_param_default;
-
- /*
- * Normally, when opclass contains 'options' method, then options are always
- * passed to support functions. However, if you add 'options' method to
- * existing opclass, previously defined indexes have no options, so the
- * check is required.
- */
- if (PG_HAS_OPCLASS_OPTIONS())
- {
- MyOptionsStruct *options = (MyOptionsStruct *) PG_GET_OPCLASS_OPTIONS();
-
- int_param = options->int_param;
- real_param = options->real_param;
- enum_param = options->enum_param;
- str_param = GET_STRING_RELOPTION(options, str_param);
- }
-
- /* the rest implementation of support function */
-}
-
-</programlisting>
- </para>
-
- <para>
- Since the representation of the key in <acronym>GiST</acronym> is
- flexible, it may depend on user-specified parameters. For instance,
- the length of key signature may be specified. See
- <literal>gtsvector_options()</literal> for example.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>sortsupport</function></term>
- <listitem>
- <para>
- Returns a comparator function to sort data in a way that preserves
- locality. It is used by <command>CREATE INDEX</command> and
- <command>REINDEX</command> commands. The quality of the created index
- depends on how well the sort order determined by the comparator function
- preserves locality of the inputs.
- </para>
- <para>
- The <function>sortsupport</function> method is optional. If it is not
- provided, <command>CREATE INDEX</command> builds the index by inserting
- each tuple to the tree using the <function>penalty</function> and
- <function>picksplit</function> functions, which is much slower.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like
- this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_sortsupport(internal)
-RETURNS void
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
-
- The argument is a pointer to a <structname>SortSupport</structname>
- struct. At a minimum, the function must fill in its comparator field.
- The comparator takes three arguments: two Datums to compare, and
- a pointer to the <structname>SortSupport</structname> struct. The
- Datums are the two indexed values in the format that they are stored
- in the index; that is, in the format returned by the
- <function>compress</function> method. The full API is defined in
- <filename>src/include/utils/sortsupport.h</filename>.
- </para>
-
- <para>
- The matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_sortsupport);
-
-static int
-my_fastcmp(Datum x, Datum y, SortSupport ssup)
-{
- /* establish order between x and y by computing some sorting value z */
-
- int z1 = ComputeSpatialCode(x);
- int z2 = ComputeSpatialCode(y);
-
- return z1 == z2 ? 0 : z1 > z2 ? 1 : -1;
-}
-
-Datum
-my_sortsupport(PG_FUNCTION_ARGS)
-{
- SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
-
- ssup->comparator = my_fastcmp;
- PG_RETURN_VOID();
-}
-</programlisting>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>stratnum</function></term>
- <listitem>
- <para>
- Given an <literal>RT*StrategyNumber</literal> value from
- <filename>src/include/access/stratnum.h</filename>, returns a strategy
- number used by this operator class for matching functionality. The
- function should return <literal>InvalidStrategy</literal> if the
- operator class has no matching strategy.
- </para>
-
- <para>
- This is used for temporal index constraints (i.e., <literal>PRIMARY
- KEY</literal> and <literal>UNIQUE</literal>). If the operator class
- provides this function and it returns results for
- <literal>RTEqualStrategyNumber</literal>, it can be used in the
- non-<literal>WITHOUT OVERLAPS</literal> part(s) of an index constraint.
- If it returns results for <literal>RTOverlapStrategyNumber</literal>,
- the operator class can be used in the <literal>WITHOUT
- OVERLAPS</literal> part of an index constraint.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like
- this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_stratnum(integer)
-RETURNS integer
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
- </para>
-
- <para>
- The matching code in the C module could then follow this skeleton:
-
-<programlisting>
-PG_FUNCTION_INFO_V1(my_stratnum);
-
-Datum
-my_stratnum(PG_FUNCTION_ARGS)
-{
- StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(1);
- StrategyNumber ret = InvalidStrategy;
-
- switch (strategy)
- {
- case RTEqualStrategyNumber:
- ret = BTEqualStrategyNumber;
- }
-
- PG_RETURN_UINT16(ret);
-}
-</programlisting>
- </para>
-
- <para>
- One translation function is provided by
- <productname>PostgreSQL</productname>:
- <literal>gist_stratnum_identity</literal> is for operator classes that
- already use the <literal>RT*StrategyNumber</literal> constants. It
- returns whatever is passed to it. The <literal>btree_gist</literal>
- extension defines a second translation function,
- <literal>gist_stratnum_btree</literal>, for operator classes that use
- the <literal>BT*StrategyNumber</literal> constants.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- All the GiST support methods are normally called in short-lived memory
- contexts; that is, <varname>CurrentMemoryContext</varname> will get reset after
- each tuple is processed. It is therefore not very important to worry about
- pfree'ing everything you palloc. However, in some cases it's useful for a
- support method to cache data across repeated calls. To do that, allocate
- the longer-lived data in <literal>fcinfo->flinfo->fn_mcxt</literal>, and
- keep a pointer to it in <literal>fcinfo->flinfo->fn_extra</literal>. Such
- data will survive for the life of the index operation (e.g., a single GiST
- index scan, index build, or index tuple insertion). Be careful to pfree
- the previous value when replacing a <literal>fn_extra</literal> value, or the leak
- will accumulate for the duration of the operation.
- </para>
-
-</sect1>
-
-<sect1 id="gist-implementation">
- <title>Implementation</title>
-
- <sect2 id="gist-buffering-build">
- <title>GiST Index Build Methods</title>
-
- <para>
- The simplest way to build a GiST index is just to insert all the entries,
- one by one. This tends to be slow for large indexes, because if the
- index tuples are scattered across the index and the index is large enough
- to not fit in cache, a lot of random I/O will be
- needed. <productname>PostgreSQL</productname> supports two alternative
- methods for initial build of a GiST index: <firstterm>sorted</firstterm>
- and <firstterm>buffered</firstterm> modes.
- </para>
-
- <para>
- The sorted method is only available if each of the opclasses used by the
- index provides a <function>sortsupport</function> function, as described
- in <xref linkend="gist-extensibility"/>. If they do, this method is
- usually the best, so it is used by default.
- </para>
-
- <para>
- The buffered method works by not inserting tuples directly into the index
- right away. It can dramatically reduce the amount of random I/O needed
- for non-ordered data sets. For well-ordered data sets the benefit is
- smaller or non-existent, because only a small number of pages receive new
- tuples at a time, and those pages fit in cache even if the index as a
- whole does not.
- </para>
-
- <para>
- The buffered method needs to call the <function>penalty</function>
- function more often than the simple method does, which consumes some
- extra CPU resources. Also, the buffers need temporary disk space, up to
- the size of the resulting index. Buffering can also influence the quality
- of the resulting index, in both positive and negative directions. That
- influence depends on various factors, like the distribution of the input
- data and the operator class implementation.
- </para>
-
- <para>
- If sorting is not possible, then by default a GiST index build switches
- to the buffering method when the index size reaches
- <xref linkend="guc-effective-cache-size"/>. Buffering can be manually
- forced or prevented by the <literal>buffering</literal> parameter to the
- CREATE INDEX command. The default behavior is good for most cases, but
- turning buffering off might speed up the build somewhat if the input data
- is ordered.
- </para>
-
- </sect2>
-</sect1>
-
-<sect1 id="gist-examples">
- <title>Examples</title>
-
- <para>
- The <productname>PostgreSQL</productname> source distribution includes
- several examples of index methods implemented using
- <acronym>GiST</acronym>. The core system currently provides text search
- support (indexing for <type>tsvector</type> and <type>tsquery</type>) as well as
- R-Tree equivalent functionality for some of the built-in geometric data types
- (see <filename>src/backend/access/gist/gistproc.c</filename>). The following
- <filename>contrib</filename> modules also contain <acronym>GiST</acronym>
- operator classes:
-
- <variablelist>
- <varlistentry>
- <term><filename>btree_gist</filename></term>
- <listitem>
- <para>B-tree equivalent functionality for several data types</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>cube</filename></term>
- <listitem>
- <para>Indexing for multidimensional cubes</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>hstore</filename></term>
- <listitem>
- <para>Module for storing (key, value) pairs</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>intarray</filename></term>
- <listitem>
- <para>RD-Tree for one-dimensional array of int4 values</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>ltree</filename></term>
- <listitem>
- <para>Indexing for tree-like structures</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>pg_trgm</filename></term>
- <listitem>
- <para>Text similarity using trigram matching</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>seg</filename></term>
- <listitem>
- <para>Indexing for <quote>float ranges</quote></para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
-</sect1>
-
-</chapter>
diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml
deleted file mode 100644
index e35911ebf8..0000000000
--- a/doc/src/sgml/hash.sgml
+++ /dev/null
@@ -1,162 +0,0 @@
-<!-- doc/src/sgml/hash.sgml -->
-
-<chapter id="hash-index">
-<title>Hash Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>Hash</secondary>
- </indexterm>
-
-<sect1 id="hash-intro">
- <title>Overview</title>
-
- <para>
- <productname>PostgreSQL</productname>
- includes an implementation of persistent on-disk hash indexes,
- which are fully crash recoverable. Any data type can be indexed by a
- hash index, including data types that do not have a well-defined linear
- ordering. Hash indexes store only the hash value of the data being
- indexed, thus there are no restrictions on the size of the data column
- being indexed.
- </para>
-
- <para>
- Hash indexes support only single-column indexes and do not allow
- uniqueness checking.
- </para>
-
- <para>
- Hash indexes support only the <literal>=</literal> operator,
- so WHERE clauses that specify range operations will not be able to take
- advantage of hash indexes.
- </para>
-
- <para>
- Each hash index tuple stores just the 4-byte hash value, not the actual
- column value. As a result, hash indexes may be much smaller than B-trees
- when indexing longer data items such as UUIDs, URLs, etc. The absence of
- the column value also makes all hash index scans lossy. Hash indexes may
- take part in bitmap index scans and backward scans.
- </para>
-
- <para>
- Hash indexes are best optimized for SELECT and UPDATE-heavy workloads
- that use equality scans on larger tables. In a B-tree index, searches must
- descend through the tree until the leaf page is found. In tables with
- millions of rows, this descent can increase access time to data. The
- equivalent of a leaf page in a hash index is referred to as a bucket page. In
- contrast, a hash index allows accessing the bucket pages directly,
- thereby potentially reducing index access time in larger tables. This
- reduction in "logical I/O" becomes even more pronounced on indexes/data
- larger than shared_buffers/RAM.
- </para>
-
- <para>
- Hash indexes have been designed to cope with uneven distributions of
- hash values. Direct access to the bucket pages works well if the hash
- values are evenly distributed. When inserts mean that the bucket page
- becomes full, additional overflow pages are chained to that specific
- bucket page, locally expanding the storage for index tuples that match
- that hash value. When scanning a hash bucket during queries, we need to
- scan through all of the overflow pages. Thus an unbalanced hash index
- might actually be worse than a B-tree in terms of number of block
- accesses required, for some data.
- </para>
-
- <para>
- As a result of the overflow cases, we can say that hash indexes are
- most suitable for unique, nearly unique data or data with a low number
- of rows per hash bucket.
- One possible way to avoid problems is to exclude highly non-unique
- values from the index using a partial index condition, but this may
- not be suitable in many cases.
- </para>
-
- <para>
- Like B-Trees, hash indexes perform simple index tuple deletion. This
- is a deferred maintenance operation that deletes index tuples that are
- known to be safe to delete (those whose item identifier's LP_DEAD bit
- is already set). If an insert finds no space is available on a page we
- try to avoid creating a new overflow page by attempting to remove dead
- index tuples. Removal cannot occur if the page is pinned at that time.
- Deletion of dead index pointers also occurs during VACUUM.
- </para>
-
- <para>
- If it can, VACUUM will also try to squeeze the index tuples onto as
- few overflow pages as possible, minimizing the overflow chain. If an
- overflow page becomes empty, overflow pages can be recycled for reuse
- in other buckets, though we never return them to the operating system.
- There is currently no provision to shrink a hash index, other than by
- rebuilding it with REINDEX.
- There is no provision for reducing the number of buckets, either.
- </para>
-
- <para>
- Hash indexes may expand the number of bucket pages as the number of
- rows indexed grows. The hash key-to-bucket-number mapping is chosen so that
- the index can be incrementally expanded. When a new bucket is to be added to
- the index, exactly one existing bucket will need to be "split", with some of
- its tuples being transferred to the new bucket according to the updated
- key-to-bucket-number mapping.
- </para>
-
- <para>
- The expansion occurs in the foreground, which could increase execution
- time for user inserts. Thus, hash indexes may not be suitable for tables
- with rapidly increasing number of rows.
- </para>
-
-</sect1>
-
-<sect1 id="hash-implementation">
- <title>Implementation</title>
-
- <para>
- There are four kinds of pages in a hash index: the meta page (page zero),
- which contains statically allocated control information; primary bucket
- pages; overflow pages; and bitmap pages, which keep track of overflow
- pages that have been freed and are available for re-use. For addressing
- purposes, bitmap pages are regarded as a subset of the overflow pages.
- </para>
-
- <para>
- Both scanning the index and inserting tuples require locating the bucket
- where a given tuple ought to be located. To do this, we need the bucket
- count, highmask, and lowmask from the metapage; however, it's undesirable
- for performance reasons to have to have to lock and pin the metapage for
- every such operation. Instead, we retain a cached copy of the metapage
- in each backend's relcache entry. This will produce the correct bucket
- mapping as long as the target bucket hasn't been split since the last
- cache refresh.
- </para>
-
- <para>
- Primary bucket pages and overflow pages are allocated independently since
- any given index might need more or fewer overflow pages relative to its
- number of buckets. The hash code uses an interesting set of addressing
- rules to support a variable number of overflow pages while not having to
- move primary bucket pages around after they are created.
- </para>
-
- <para>
- Each row in the table indexed is represented by a single index tuple in
- the hash index. Hash index tuples are stored in bucket pages, and if
- they exist, overflow pages. We speed up searches by keeping the index entries
- in any one index page sorted by hash code, thus allowing binary search to be
- used within an index page. Note however that there is *no* assumption about
- the relative ordering of hash codes across different index pages of a bucket.
- </para>
-
- <para>
- The bucket splitting algorithms to expand the hash index are too complex to
- be worthy of mention here, though are described in more detail in
- <filename>src/backend/access/hash/README</filename>.
- The split algorithm is crash safe and can be restarted if not completed
- successfully.
- </para>
-
-</sect1>
-
-</chapter>
diff --git a/doc/src/sgml/indextypes.sgml b/doc/src/sgml/indextypes.sgml
new file mode 100644
index 0000000000..7aad8d94ed
--- /dev/null
+++ b/doc/src/sgml/indextypes.sgml
@@ -0,0 +1,5597 @@
+ <!-- doc/src/sgml/indextypes.sgml -->
+
+<chapter id="indextypes">
+<title>Built-in Index Access Methods</title>
+
+ <sect1 id="btree">
+ <title>B-Tree Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>B-Tree</secondary>
+ </indexterm>
+
+ <sect2 id="btree-intro">
+ <title>Introduction</title>
+
+ <para>
+ <productname>PostgreSQL</productname> includes an implementation of the
+ standard <acronym>btree</acronym> (multi-way balanced tree) index data
+ structure. Any data type that can be sorted into a well-defined linear
+ order can be indexed by a btree index. The only limitation is that an
+ index entry cannot exceed approximately one-third of a page (after TOAST
+ compression, if applicable).
+ </para>
+
+ <para>
+ Because each btree operator class imposes a sort order on its data type,
+ btree operator classes (or, really, operator families) have come to be
+ used as <productname>PostgreSQL</productname>'s general representation
+ and understanding of sorting semantics. Therefore, they've acquired
+ some features that go beyond what would be needed just to support btree
+ indexes, and parts of the system that are quite distant from the
+ btree <acronym>AM</acronym> make use of them.
+ </para>
+
+ </sect2>
+
+ <sect2 id="btree-behavior">
+ <title>Behavior of B-Tree Operator Classes</title>
+
+ <para>
+ As shown in <xref linkend="xindex-btree-strat-table"/>, a btree operator
+ class must provide five comparison operators,
+ <literal><</literal>,
+ <literal><=</literal>,
+ <literal>=</literal>,
+ <literal>>=</literal> and
+ <literal>></literal>.
+ One might expect that <literal><></literal> should also be part of
+ the operator class, but it is not, because it would almost never be
+ useful to use a <literal><></literal> WHERE clause in an index
+ search. (For some purposes, the planner treats <literal><></literal>
+ as associated with a btree operator class; but it finds that operator via
+ the <literal>=</literal> operator's negator link, rather than
+ from <structname>pg_amop</structname>.)
+ </para>
+
+ <para>
+ When several data types share near-identical sorting semantics, their
+ operator classes can be grouped into an operator family. Doing so is
+ advantageous because it allows the planner to make deductions about
+ cross-type comparisons. Each operator class within the family should
+ contain the single-type operators (and associated support functions)
+ for its input data type, while cross-type comparison operators and
+ support functions are <quote>loose</quote> in the family. It is
+ recommendable that a complete set of cross-type operators be included
+ in the family, thus ensuring that the planner can represent any
+ comparison conditions that it deduces from transitivity.
+ </para>
+
+ <para>
+ There are some basic assumptions that a btree operator family must
+ satisfy:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ An <literal>=</literal> operator must be an equivalence relation; that
+ is, for all non-null values <replaceable>A</replaceable>,
+ <replaceable>B</replaceable>, <replaceable>C</replaceable> of the
+ data type:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <replaceable>A</replaceable> <literal>=</literal>
+ <replaceable>A</replaceable> is true
+ (<firstterm>reflexive law</firstterm>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <replaceable>A</replaceable> <literal>=</literal>
+ <replaceable>B</replaceable>,
+ then <replaceable>B</replaceable> <literal>=</literal>
+ <replaceable>A</replaceable>
+ (<firstterm>symmetric law</firstterm>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <replaceable>A</replaceable> <literal>=</literal>
+ <replaceable>B</replaceable> and <replaceable>B</replaceable>
+ <literal>=</literal> <replaceable>C</replaceable>,
+ then <replaceable>A</replaceable> <literal>=</literal>
+ <replaceable>C</replaceable>
+ (<firstterm>transitive law</firstterm>)
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A <literal><</literal> operator must be a strong ordering relation;
+ that is, for all non-null values <replaceable>A</replaceable>,
+ <replaceable>B</replaceable>, <replaceable>C</replaceable>:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <replaceable>A</replaceable> <literal><</literal>
+ <replaceable>A</replaceable> is false
+ (<firstterm>irreflexive law</firstterm>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <replaceable>A</replaceable> <literal><</literal>
+ <replaceable>B</replaceable>
+ and <replaceable>B</replaceable> <literal><</literal>
+ <replaceable>C</replaceable>,
+ then <replaceable>A</replaceable> <literal><</literal>
+ <replaceable>C</replaceable>
+ (<firstterm>transitive law</firstterm>)
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Furthermore, the ordering is total; that is, for all non-null
+ values <replaceable>A</replaceable>, <replaceable>B</replaceable>:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ exactly one of <replaceable>A</replaceable> <literal><</literal>
+ <replaceable>B</replaceable>, <replaceable>A</replaceable>
+ <literal>=</literal> <replaceable>B</replaceable>, and
+ <replaceable>B</replaceable> <literal><</literal>
+ <replaceable>A</replaceable> is true
+ (<firstterm>trichotomy law</firstterm>)
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ (The trichotomy law justifies the definition of the comparison support
+ function, of course.)
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The other three operators are defined in terms of <literal>=</literal>
+ and <literal><</literal> in the obvious way, and must act consistently
+ with them.
+ </para>
+
+ <para>
+ For an operator family supporting multiple data types, the above laws must
+ hold when <replaceable>A</replaceable>, <replaceable>B</replaceable>,
+ <replaceable>C</replaceable> are taken from any data types in the family.
+ The transitive laws are the trickiest to ensure, as in cross-type
+ situations they represent statements that the behaviors of two or three
+ different operators are consistent.
+ As an example, it would not work to put <type>float8</type>
+ and <type>numeric</type> into the same operator family, at least not with
+ the current semantics that <type>numeric</type> values are converted
+ to <type>float8</type> for comparison to a <type>float8</type>. Because
+ of the limited accuracy of <type>float8</type>, this means there are
+ distinct <type>numeric</type> values that will compare equal to the
+ same <type>float8</type> value, and thus the transitive law would fail.
+ </para>
+
+ <para>
+ Another requirement for a multiple-data-type family is that any implicit
+ or binary-coercion casts that are defined between data types included in
+ the operator family must not change the associated sort ordering.
+ </para>
+
+ <para>
+ It should be fairly clear why a btree index requires these laws to hold
+ within a single data type: without them there is no ordering to arrange
+ the keys with. Also, index searches using a comparison key of a
+ different data type require comparisons to behave sanely across two
+ data types. The extensions to three or more data types within a family
+ are not strictly required by the btree index mechanism itself, but the
+ planner relies on them for optimization purposes.
+ </para>
+
+ </sect2>
+
+ <sect2 id="btree-support-funcs">
+ <title>B-Tree Support Functions</title>
+
+ <para>
+ As shown in <xref linkend="xindex-btree-support-table"/>, btree defines
+ one required and four optional support functions. The five
+ user-defined methods are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term><function>order</function></term>
+ <listitem>
+ <para>
+ For each combination of data types that a btree operator family
+ provides comparison operators for, it must provide a comparison
+ support function, registered in
+ <structname>pg_amproc</structname> with support function number 1
+ and
+ <structfield>amproclefttype</structfield>/<structfield>amprocrighttype</structfield>
+ equal to the left and right data types for the comparison (i.e.,
+ the same data types that the matching operators are registered
+ with in <structname>pg_amop</structname>). The comparison
+ function must take two non-null values
+ <replaceable>A</replaceable> and <replaceable>B</replaceable> and
+ return an <type>int32</type> value that is
+ <literal><</literal> <literal>0</literal>,
+ <literal>0</literal>, or <literal>></literal>
+ <literal>0</literal> when <replaceable>A</replaceable>
+ <literal><</literal> <replaceable>B</replaceable>,
+ <replaceable>A</replaceable> <literal>=</literal>
+ <replaceable>B</replaceable>, or <replaceable>A</replaceable>
+ <literal>></literal> <replaceable>B</replaceable>,
+ respectively. A null result is disallowed: all values of the
+ data type must be comparable. See
+ <filename>src/backend/access/nbtree/nbtcompare.c</filename> for
+ examples.
+ </para>
+
+ <para>
+ If the compared values are of a collatable data type, the
+ appropriate collation OID will be passed to the comparison
+ support function, using the standard
+ <function>PG_GET_COLLATION()</function> mechanism.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><function>sortsupport</function></term>
+ <listitem>
+ <para>
+ Optionally, a btree operator family may provide <firstterm>sort
+ support</firstterm> function(s), registered under support
+ function number 2. These functions allow implementing
+ comparisons for sorting purposes in a more efficient way than
+ naively calling the comparison support function. The APIs
+ involved in this are defined in
+ <filename>src/include/utils/sortsupport.h</filename>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><function>in_range</function></term>
+ <listitem>
+ <indexterm>
+ <primary>in_range support functions</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>support functions</primary>
+ <secondary>in_range</secondary>
+ </indexterm>
+ <para>
+ Optionally, a btree operator family may provide
+ <firstterm>in_range</firstterm> support function(s), registered
+ under support function number 3. These are not used during btree
+ index operations; rather, they extend the semantics of the
+ operator family so that it can support window clauses containing
+ the <literal>RANGE</literal> <replaceable>offset</replaceable>
+ <literal>PRECEDING</literal> and <literal>RANGE</literal>
+ <replaceable>offset</replaceable> <literal>FOLLOWING</literal>
+ frame bound types (see <xref
+ linkend="syntax-window-functions"/>). Fundamentally, the extra
+ information provided is how to add or subtract an
+ <replaceable>offset</replaceable> value in a way that is
+ compatible with the family's data ordering.
+ </para>
+
+ <para>
+ An <function>in_range</function> function must have the signature
+ <synopsis>
+ in_range(<replaceable>val</replaceable> type1, <replaceable>base</replaceable> type1, <replaceable>offset</replaceable> type2, <replaceable>sub</replaceable> bool, <replaceable>less</replaceable> bool)
+ returns bool
+ </synopsis>
+ <replaceable>val</replaceable> and
+ <replaceable>base</replaceable> must be of the same type, which
+ is one of the types supported by the operator family (i.e., a
+ type for which it provides an ordering). However,
+ <replaceable>offset</replaceable> could be of a different type,
+ which might be one otherwise unsupported by the family. An
+ example is that the built-in <literal>time_ops</literal> family
+ provides an <function>in_range</function> function that has
+ <replaceable>offset</replaceable> of type <type>interval</type>.
+ A family can provide <function>in_range</function> functions for
+ any of its supported types and one or more
+ <replaceable>offset</replaceable> types. Each
+ <function>in_range</function> function should be entered in
+ <structname>pg_amproc</structname> with
+ <structfield>amproclefttype</structfield> equal to
+ <type>type1</type> and <structfield>amprocrighttype</structfield>
+ equal to <type>type2</type>.
+ </para>
+
+ <para>
+ The essential semantics of an <function>in_range</function>
+ function depend on the two Boolean flag parameters. It should
+ add or subtract <replaceable>base</replaceable> and
+ <replaceable>offset</replaceable>, then compare
+ <replaceable>val</replaceable> to the result, as follows:
+ <itemizedlist>
+ <listitem>
+ <para>
+ if <literal>!</literal><replaceable>sub</replaceable> and
+ <literal>!</literal><replaceable>less</replaceable>, return
+ <replaceable>val</replaceable> <literal>>=</literal>
+ (<replaceable>base</replaceable> <literal>+</literal>
+ <replaceable>offset</replaceable>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <literal>!</literal><replaceable>sub</replaceable> and
+ <replaceable>less</replaceable>, return
+ <replaceable>val</replaceable> <literal><=</literal>
+ (<replaceable>base</replaceable> <literal>+</literal>
+ <replaceable>offset</replaceable>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <replaceable>sub</replaceable> and
+ <literal>!</literal><replaceable>less</replaceable>, return
+ <replaceable>val</replaceable> <literal>>=</literal>
+ (<replaceable>base</replaceable> <literal>-</literal>
+ <replaceable>offset</replaceable>)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ if <replaceable>sub</replaceable> and
+ <replaceable>less</replaceable>, return
+ <replaceable>val</replaceable> <literal><=</literal>
+ (<replaceable>base</replaceable> <literal>-</literal>
+ <replaceable>offset</replaceable>)
+ </para>
+ </listitem>
+ </itemizedlist>
+ Before doing so, the function should check the sign of
+ <replaceable>offset</replaceable>: if it is less than zero, raise
+ error
+ <literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal>
+ (22013) with error text like <quote>invalid preceding or
+ following size in window function</quote>. (This is required by
+ the SQL standard, although nonstandard operator families might
+ perhaps choose to ignore this restriction, since there seems to
+ be little semantic necessity for it.) This requirement is
+ delegated to the <function>in_range</function> function so that
+ the core code needn't understand what <quote>less than
+ zero</quote> means for a particular data type.
+ </para>
+
+ <para>
+ An additional expectation is that <function>in_range</function>
+ functions should, if practical, avoid throwing an error if
+ <replaceable>base</replaceable> <literal>+</literal>
+ <replaceable>offset</replaceable> or
+ <replaceable>base</replaceable> <literal>-</literal>
+ <replaceable>offset</replaceable> would overflow. The correct
+ comparison result can be determined even if that value would be
+ out of the data type's range. Note that if the data type
+ includes concepts such as <quote>infinity</quote> or
+ <quote>NaN</quote>, extra care may be needed to ensure that
+ <function>in_range</function>'s results agree with the normal
+ sort order of the operator family.
+ </para>
+
+ <para>
+ The results of the <function>in_range</function> function must be
+ consistent with the sort ordering imposed by the operator family.
+ To be precise, given any fixed values of
+ <replaceable>offset</replaceable> and
+ <replaceable>sub</replaceable>, then:
+ <itemizedlist>
+ <listitem>
+ <para>
+ If <function>in_range</function> with
+ <replaceable>less</replaceable> = true is true for some
+ <replaceable>val1</replaceable> and
+ <replaceable>base</replaceable>, it must be true for every
+ <replaceable>val2</replaceable> <literal><=</literal>
+ <replaceable>val1</replaceable> with the same
+ <replaceable>base</replaceable>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If <function>in_range</function> with
+ <replaceable>less</replaceable> = true is false for some
+ <replaceable>val1</replaceable> and
+ <replaceable>base</replaceable>, it must be false for every
+ <replaceable>val2</replaceable> <literal>>=</literal>
+ <replaceable>val1</replaceable> with the same
+ <replaceable>base</replaceable>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If <function>in_range</function> with
+ <replaceable>less</replaceable> = true is true for some
+ <replaceable>val</replaceable> and
+ <replaceable>base1</replaceable>, it must be true for every
+ <replaceable>base2</replaceable> <literal>>=</literal>
+ <replaceable>base1</replaceable> with the same
+ <replaceable>val</replaceable>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If <function>in_range</function> with
+ <replaceable>less</replaceable> = true is false for some
+ <replaceable>val</replaceable> and
+ <replaceable>base1</replaceable>, it must be false for every
+ <replaceable>base2</replaceable> <literal><=</literal>
+ <replaceable>base1</replaceable> with the same
+ <replaceable>val</replaceable>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ Analogous statements with inverted conditions hold when
+ <replaceable>less</replaceable> = false.
+ </para>
+
+ <para>
+ If the type being ordered (<type>type1</type>) is collatable, the
+ appropriate collation OID will be passed to the
+ <function>in_range</function> function, using the standard
+ PG_GET_COLLATION() mechanism.
+ </para>
+
+ <para>
+ <function>in_range</function> functions need not handle NULL
+ inputs, and typically will be marked strict.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><function>equalimage</function></term>
+ <listitem>
+ <para>
+ Optionally, a btree operator family may provide
+ <function>equalimage</function> (<quote>equality implies image
+ equality</quote>) support functions, registered under support
+ function number 4. These functions allow the core code to
+ determine when it is safe to apply the btree deduplication
+ optimization. Currently, <function>equalimage</function>
+ functions are only called when building or rebuilding an index.
+ </para>
+ <para>
+ An <function>equalimage</function> function must have the
+ signature
+ <synopsis>
+ equalimage(<replaceable>opcintype</replaceable> <type>oid</type>) returns bool
+ </synopsis>
+ The return value is static information about an operator class
+ and collation. Returning <literal>true</literal> indicates that
+ the <function>order</function> function for the operator class is
+ guaranteed to only return <literal>0</literal> (<quote>arguments
+ are equal</quote>) when its <replaceable>A</replaceable> and
+ <replaceable>B</replaceable> arguments are also interchangeable
+ without any loss of semantic information. Not registering an
+ <function>equalimage</function> function or returning
+ <literal>false</literal> indicates that this condition cannot be
+ assumed to hold.
+ </para>
+ <para>
+ The <replaceable>opcintype</replaceable> argument is the
+ <literal><structname>pg_type</structname>.oid</literal> of the
+ data type that the operator class indexes. This is a convenience
+ that allows reuse of the same underlying
+ <function>equalimage</function> function across operator classes.
+ If <replaceable>opcintype</replaceable> is a collatable data
+ type, the appropriate collation OID will be passed to the
+ <function>equalimage</function> function, using the standard
+ <function>PG_GET_COLLATION()</function> mechanism.
+ </para>
+ <para>
+ As far as the operator class is concerned, returning
+ <literal>true</literal> indicates that deduplication is safe (or
+ safe for the collation whose OID was passed to its
+ <function>equalimage</function> function). However, the core
+ code will only deem deduplication safe for an index when
+ <emphasis>every</emphasis> indexed column uses an operator class
+ that registers an <function>equalimage</function> function, and
+ each function actually returns <literal>true</literal> when
+ called.
+ </para>
+ <para>
+ Image equality is <emphasis>almost</emphasis> the same condition
+ as simple bitwise equality. There is one subtle difference: When
+ indexing a varlena data type, the on-disk representation of two
+ image equal datums may not be bitwise equal due to inconsistent
+ application of <acronym>TOAST</acronym> compression on input.
+ Formally, when an operator class's
+ <function>equalimage</function> function returns
+ <literal>true</literal>, it is safe to assume that the
+ <literal>datum_image_eq()</literal> C function will always agree
+ with the operator class's <function>order</function> function
+ (provided that the same collation OID is passed to both the
+ <function>equalimage</function> and <function>order</function>
+ functions).
+ </para>
+ <para>
+ The core code is fundamentally unable to deduce anything about
+ the <quote>equality implies image equality</quote> status of an
+ operator class within a multiple-data-type family based on
+ details from other operator classes in the same family. Also, it
+ is not sensible for an operator family to register a cross-type
+ <function>equalimage</function> function, and attempting to do so
+ will result in an error. This is because <quote>equality implies
+ image equality</quote> status does not just depend on
+ sorting/equality semantics, which are more or less defined at the
+ operator family level. In general, the semantics that one
+ particular data type implements must be considered separately.
+ </para>
+ <para>
+ The convention followed by the operator classes included with the
+ core <productname>PostgreSQL</productname> distribution is to
+ register a stock, generic <function>equalimage</function>
+ function. Most operator classes register
+ <function>btequalimage()</function>, which indicates that
+ deduplication is safe unconditionally. Operator classes for
+ collatable data types such as <type>text</type> register
+ <function>btvarstrequalimage()</function>, which indicates that
+ deduplication is safe with deterministic collations. Best
+ practice for third-party extensions is to register their own
+ custom function to retain control.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><function>options</function></term>
+ <listitem>
+ <para>
+ Optionally, a B-tree operator family may provide
+ <function>options</function> (<quote>operator class specific
+ options</quote>) support functions, registered under support
+ function number 5. These functions define a set of user-visible
+ parameters that control operator class behavior.
+ </para>
+ <para>
+ An <function>options</function> support function must have the
+ signature
+ <synopsis>
+ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns void
+ </synopsis>
+ The function is passed a pointer to a <structname>local_relopts</structname>
+ struct, which needs to be filled with a set of operator class
+ specific options. The options can be accessed from other support
+ functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
+ <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
+ </para>
+ <para>
+ Currently, no B-Tree operator class has an <function>options</function>
+ support function. B-tree doesn't allow flexible representation of keys
+ like GiST, SP-GiST, GIN and BRIN do. So, <function>options</function>
+ probably doesn't have much application in the current B-tree index
+ access method. Nevertheless, this support function was added to B-tree
+ for uniformity, and will probably find uses during further
+ evolution of B-tree in <productname>PostgreSQL</productname>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="btree-implementation">
+ <title>Implementation</title>
+
+ <para>
+ This section covers B-Tree index implementation details that may be
+ of use to advanced users. See
+ <filename>src/backend/access/nbtree/README</filename> in the source
+ distribution for a much more detailed, internals-focused description
+ of the B-Tree implementation.
+ </para>
+ <sect3 id="btree-structure">
+ <title>B-Tree Structure</title>
+ <para>
+ <productname>PostgreSQL</productname> B-Tree indexes are
+ multi-level tree structures, where each level of the tree can be
+ used as a doubly-linked list of pages. A single metapage is stored
+ in a fixed position at the start of the first segment file of the
+ index. All other pages are either leaf pages or internal pages.
+ Leaf pages are the pages on the lowest level of the tree. All
+ other levels consist of internal pages. Each leaf page contains
+ tuples that point to table rows. Each internal page contains
+ tuples that point to the next level down in the tree. Typically,
+ over 99% of all pages are leaf pages. Both internal pages and leaf
+ pages use the standard page format described in <xref
+ linkend="storage-page-layout"/>.
+ </para>
+ <para>
+ New leaf pages are added to a B-Tree index when an existing leaf
+ page cannot fit an incoming tuple. A <firstterm>page
+ split</firstterm> operation makes room for items that originally
+ belonged on the overflowing page by moving a portion of the items
+ to a new page. Page splits must also insert a new
+ <firstterm>downlink</firstterm> to the new page in the parent page,
+ which may cause the parent to split in turn. Page splits
+ <quote>cascade upwards</quote> in a recursive fashion. When the
+ root page finally cannot fit a new downlink, a <firstterm>root page
+ split</firstterm> operation takes place. This adds a new level to
+ the tree structure by creating a new root page that is one level
+ above the original root page.
+ </para>
+ </sect3>
+
+ <sect3 id="btree-deletion">
+ <title>Bottom-up Index Deletion</title>
+ <para>
+ B-Tree indexes are not directly aware that under MVCC, there might
+ be multiple extant versions of the same logical table row; to an
+ index, each tuple is an independent object that needs its own index
+ entry. <quote>Version churn</quote> tuples may sometimes
+ accumulate and adversely affect query latency and throughput. This
+ typically occurs with <command>UPDATE</command>-heavy workloads
+ where most individual updates cannot apply the
+ <link linkend="storage-hot"><acronym>HOT</acronym> optimization.</link>
+ Changing the value of only
+ one column covered by one index during an <command>UPDATE</command>
+ <emphasis>always</emphasis> necessitates a new set of index tuples
+ — one for <emphasis>each and every</emphasis> index on the
+ table. Note in particular that this includes indexes that were not
+ <quote>logically modified</quote> by the <command>UPDATE</command>.
+ All indexes will need a successor physical index tuple that points
+ to the latest version in the table. Each new tuple within each
+ index will generally need to coexist with the original
+ <quote>updated</quote> tuple for a short period of time (typically
+ until shortly after the <command>UPDATE</command> transaction
+ commits).
+ </para>
+ <para>
+ B-Tree indexes incrementally delete version churn index tuples by
+ performing <firstterm>bottom-up index deletion</firstterm> passes.
+ Each deletion pass is triggered in reaction to an anticipated
+ <quote>version churn page split</quote>. This only happens with
+ indexes that are not logically modified by
+ <command>UPDATE</command> statements, where concentrated build up
+ of obsolete versions in particular pages would occur otherwise. A
+ page split will usually be avoided, though it's possible that
+ certain implementation-level heuristics will fail to identify and
+ delete even one garbage index tuple (in which case a page split or
+ deduplication pass resolves the issue of an incoming new tuple not
+ fitting on a leaf page). The worst-case number of versions that
+ any index scan must traverse (for any single logical row) is an
+ important contributor to overall system responsiveness and
+ throughput. A bottom-up index deletion pass targets suspected
+ garbage tuples in a single leaf page based on
+ <emphasis>qualitative</emphasis> distinctions involving logical
+ rows and versions. This contrasts with the <quote>top-down</quote>
+ index cleanup performed by autovacuum workers, which is triggered
+ when certain <emphasis>quantitative</emphasis> table-level
+ thresholds are exceeded (see <xref linkend="autovacuum"/>).
+ </para>
+ <note>
+ <para>
+ Not all deletion operations that are performed within B-Tree
+ indexes are bottom-up deletion operations. There is a distinct
+ category of index tuple deletion: <firstterm>simple index tuple
+ deletion</firstterm>. This is a deferred maintenance operation
+ that deletes index tuples that are known to be safe to delete
+ (those whose item identifier's <literal>LP_DEAD</literal> bit is
+ already set). Like bottom-up index deletion, simple index
+ deletion takes place at the point that a page split is anticipated
+ as a way of avoiding the split.
+ </para>
+ <para>
+ Simple deletion is opportunistic in the sense that it can only
+ take place when recent index scans set the
+ <literal>LP_DEAD</literal> bits of affected items in passing.
+ Prior to <productname>PostgreSQL</productname> 14, the only
+ category of B-Tree deletion was simple deletion. The main
+ differences between it and bottom-up deletion are that only the
+ former is opportunistically driven by the activity of passing
+ index scans, while only the latter specifically targets version
+ churn from <command>UPDATE</command>s that do not logically modify
+ indexed columns.
+ </para>
+ </note>
+ <para>
+ Bottom-up index deletion performs the vast majority of all garbage
+ index tuple cleanup for particular indexes with certain workloads.
+ This is expected with any B-Tree index that is subject to
+ significant version churn from <command>UPDATE</command>s that
+ rarely or never logically modify the columns that the index covers.
+ The average and worst-case number of versions per logical row can
+ be kept low purely through targeted incremental deletion passes.
+ It's quite possible that the on-disk size of certain indexes will
+ never increase by even one single page/block despite
+ <emphasis>constant</emphasis> version churn from
+ <command>UPDATE</command>s. Even then, an exhaustive <quote>clean
+ sweep</quote> by a <command>VACUUM</command> operation (typically
+ run in an autovacuum worker process) will eventually be required as
+ a part of <emphasis>collective</emphasis> cleanup of the table and
+ each of its indexes.
+ </para>
+ <para>
+ Unlike <command>VACUUM</command>, bottom-up index deletion does not
+ provide any strong guarantees about how old the oldest garbage
+ index tuple may be. No index can be permitted to retain
+ <quote>floating garbage</quote> index tuples that became dead prior
+ to a conservative cutoff point shared by the table and all of its
+ indexes collectively. This fundamental table-level invariant makes
+ it safe to recycle table <acronym>TID</acronym>s. This is how it
+ is possible for distinct logical rows to reuse the same table
+ <acronym>TID</acronym> over time (though this can never happen with
+ two logical rows whose lifetimes span the same
+ <command>VACUUM</command> cycle).
+ </para>
+ </sect3>
+
+ <sect3 id="btree-deduplication">
+ <title>Deduplication</title>
+ <para>
+ A duplicate is a leaf page tuple (a tuple that points to a table
+ row) where <emphasis>all</emphasis> indexed key columns have values
+ that match corresponding column values from at least one other leaf
+ page tuple in the same index. Duplicate tuples are quite common in
+ practice. B-Tree indexes can use a special, space-efficient
+ representation for duplicates when an optional technique is
+ enabled: <firstterm>deduplication</firstterm>.
+ </para>
+ <para>
+ Deduplication works by periodically merging groups of duplicate
+ tuples together, forming a single <firstterm>posting list</firstterm> tuple for each
+ group. The column key value(s) only appear once in this
+ representation. This is followed by a sorted array of
+ <acronym>TID</acronym>s that point to rows in the table. This
+ significantly reduces the storage size of indexes where each value
+ (or each distinct combination of column values) appears several
+ times on average. The latency of queries can be reduced
+ significantly. Overall query throughput may increase
+ significantly. The overhead of routine index vacuuming may also be
+ reduced significantly.
+ </para>
+ <note>
+ <para>
+ B-Tree deduplication is just as effective with
+ <quote>duplicates</quote> that contain a NULL value, even though
+ NULL values are never equal to each other according to the
+ <literal>=</literal> member of any B-Tree operator class. As far
+ as any part of the implementation that understands the on-disk
+ B-Tree structure is concerned, NULL is just another value from the
+ domain of indexed values.
+ </para>
+ </note>
+ <para>
+ The deduplication process occurs lazily, when a new item is
+ inserted that cannot fit on an existing leaf page, though only when
+ index tuple deletion could not free sufficient space for the new
+ item (typically deletion is briefly considered and then skipped
+ over). Unlike GIN posting list tuples, B-Tree posting list tuples
+ do not need to expand every time a new duplicate is inserted; they
+ are merely an alternative physical representation of the original
+ logical contents of the leaf page. This design prioritizes
+ consistent performance with mixed read-write workloads. Most
+ client applications will at least see a moderate performance
+ benefit from using deduplication. Deduplication is enabled by
+ default.
+ </para>
+ <para>
+ <command>CREATE INDEX</command> and <command>REINDEX</command>
+ apply deduplication to create posting list tuples, though the
+ strategy they use is slightly different. Each group of duplicate
+ ordinary tuples encountered in the sorted input taken from the
+ table is merged into a posting list tuple
+ <emphasis>before</emphasis> being added to the current pending leaf
+ page. Individual posting list tuples are packed with as many
+ <acronym>TID</acronym>s as possible. Leaf pages are written out in
+ the usual way, without any separate deduplication pass. This
+ strategy is well-suited to <command>CREATE INDEX</command> and
+ <command>REINDEX</command> because they are once-off batch
+ operations.
+ </para>
+ <para>
+ Write-heavy workloads that don't benefit from deduplication due to
+ having few or no duplicate values in indexes will incur a small,
+ fixed performance penalty (unless deduplication is explicitly
+ disabled). The <literal>deduplicate_items</literal> storage
+ parameter can be used to disable deduplication within individual
+ indexes. There is never any performance penalty with read-only
+ workloads, since reading posting list tuples is at least as
+ efficient as reading the standard tuple representation. Disabling
+ deduplication isn't usually helpful.
+ </para>
+ <para>
+ It is sometimes possible for unique indexes (as well as unique
+ constraints) to use deduplication. This allows leaf pages to
+ temporarily <quote>absorb</quote> extra version churn duplicates.
+ Deduplication in unique indexes augments bottom-up index deletion,
+ especially in cases where a long-running transaction holds a
+ snapshot that blocks garbage collection. The goal is to buy time
+ for the bottom-up index deletion strategy to become effective
+ again. Delaying page splits until a single long-running
+ transaction naturally goes away can allow a bottom-up deletion pass
+ to succeed where an earlier deletion pass failed.
+ </para>
+ <tip>
+ <para>
+ A special heuristic is applied to determine whether a
+ deduplication pass in a unique index should take place. It can
+ often skip straight to splitting a leaf page, avoiding a
+ performance penalty from wasting cycles on unhelpful deduplication
+ passes. If you're concerned about the overhead of deduplication,
+ consider setting <literal>deduplicate_items = off</literal>
+ selectively. Leaving deduplication enabled in unique indexes has
+ little downside.
+ </para>
+ </tip>
+ <para>
+ Deduplication cannot be used in all cases due to
+ implementation-level restrictions. Deduplication safety is
+ determined when <command>CREATE INDEX</command> or
+ <command>REINDEX</command> is run.
+ </para>
+ <para>
+ Note that deduplication is deemed unsafe and cannot be used in the
+ following cases involving semantically significant differences
+ among equal datums:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <type>text</type>, <type>varchar</type>, and <type>char</type>
+ cannot use deduplication when a
+ <emphasis>nondeterministic</emphasis> collation is used. Case
+ and accent differences must be preserved among equal datums.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <type>numeric</type> cannot use deduplication. Numeric display
+ scale must be preserved among equal datums.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <type>jsonb</type> cannot use deduplication, since the
+ <type>jsonb</type> B-Tree operator class uses
+ <type>numeric</type> internally.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <type>float4</type> and <type>float8</type> cannot use
+ deduplication. These types have distinct representations for
+ <literal>-0</literal> and <literal>0</literal>, which are
+ nevertheless considered equal. This difference must be
+ preserved.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ There is one further implementation-level restriction that may be
+ lifted in a future version of
+ <productname>PostgreSQL</productname>:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Container types (such as composite types, arrays, or range
+ types) cannot use deduplication.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ There is one further implementation-level restriction that applies
+ regardless of the operator class or collation used:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>INCLUDE</literal> indexes can never use deduplication.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ </sect3>
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="gist">
+ <title>GiST Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>GiST</secondary>
+ </indexterm>
+
+ <sect2 id="gist-intro">
+ <title>Introduction</title>
+
+ <para>
+ <acronym>GiST</acronym> stands for Generalized Search Tree. It is a
+ balanced, tree-structured access method, that acts as a base template in
+ which to implement arbitrary indexing schemes. B-trees, R-trees and many
+ other indexing schemes can be implemented in <acronym>GiST</acronym>.
+ </para>
+
+ <para>
+ One advantage of <acronym>GiST</acronym> is that it allows the development
+ of custom data types with the appropriate access methods, by
+ an expert in the domain of the data type, rather than a database expert.
+ </para>
+
+ <para>
+ Some of the information here is derived from the University of California
+ at Berkeley's GiST Indexing Project
+ <ulink url="http://gist.cs.berkeley.edu/">web site</ulink> and
+ Marcel Kornacker's thesis,
+ <ulink url="http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/access-methods-for-next-generation.pdf.gz">
+ Access Methods for Next-Generation Database Systems</ulink>.
+ The <acronym>GiST</acronym>
+ implementation in <productname>PostgreSQL</productname> is primarily
+ maintained by Teodor Sigaev and Oleg Bartunov, and there is more
+ information on their
+ <ulink url="http://www.sai.msu.su/~megera/postgres/gist/">web site</ulink>.
+ </para>
+
+ </sect2>
+
+ <sect2 id="gist-builtin-opclasses">
+ <title>Built-in Operator Classes</title>
+
+ <para>
+ The core <productname>PostgreSQL</productname> distribution
+ includes the <acronym>GiST</acronym> operator classes shown in
+ <xref linkend="gist-builtin-opclasses-table"/>.
+ (Some of the optional modules described in <xref linkend="contrib"/>
+ provide additional <acronym>GiST</acronym> operator classes.)
+ </para>
+
+ <table id="gist-builtin-opclasses-table">
+ <title>Built-in <acronym>GiST</acronym> Operator Classes</title>
+ <tgroup cols="3">
+ <colspec colname="col1" colwidth="2*"/>
+ <colspec colname="col2" colwidth="3*"/>
+ <colspec colname="col3" colwidth="2*"/>
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Indexable Operators</entry>
+ <entry>Ordering Operators</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry valign="middle" morerows="13"><literal>box_ops</literal></entry>
+ <entry><literal><< (box, box)</literal></entry>
+ <entry valign="middle" morerows="13"><literal><-> (box, point)</literal></entry>
+ </row>
+ <row><entry><literal>&< (box, box)</literal></entry></row>
+ <row><entry><literal>&& (box, box)</literal></entry></row>
+ <row><entry><literal>&> (box, box)</literal></entry></row>
+ <row><entry><literal>>> (box, box)</literal></entry></row>
+ <row><entry><literal>~= (box, box)</literal></entry></row>
+ <row><entry><literal>@> (box, box)</literal></entry></row>
+ <row><entry><literal><@ (box, box)</literal></entry></row>
+ <row><entry><literal>&<| (box, box)</literal></entry></row>
+ <row><entry><literal><<| (box, box)</literal></entry></row>
+ <row><entry><literal>|>> (box, box)</literal></entry></row>
+ <row><entry><literal>|&> (box, box)</literal></entry></row>
+ <row><entry><literal>~ (box, box)</literal></entry></row>
+ <row><entry><literal>@ (box, box)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="13"><literal>circle_ops</literal></entry>
+ <entry><literal><< (circle, circle)</literal></entry>
+ <entry valign="middle" morerows="13"><literal><-> (circle, point)</literal></entry>
+ </row>
+ <row><entry><literal>&< (circle, circle)</literal></entry></row>
+ <row><entry><literal>&> (circle, circle)</literal></entry></row>
+ <row><entry><literal>>> (circle, circle)</literal></entry></row>
+ <row><entry><literal><@ (circle, circle)</literal></entry></row>
+ <row><entry><literal>@> (circle, circle)</literal></entry></row>
+ <row><entry><literal>~= (circle, circle)</literal></entry></row>
+ <row><entry><literal>&& (circle, circle)</literal></entry></row>
+ <row><entry><literal>|>> (circle, circle)</literal></entry></row>
+ <row><entry><literal><<| (circle, circle)</literal></entry></row>
+ <row><entry><literal>&<| (circle, circle)</literal></entry></row>
+ <row><entry><literal>|&> (circle, circle)</literal></entry></row>
+ <row><entry><literal>@ (circle, circle)</literal></entry></row>
+ <row><entry><literal>~ (circle, circle)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="10"><literal>inet_ops</literal></entry>
+ <entry><literal><< (inet, inet)</literal></entry>
+ <entry valign="middle" morerows="10"></entry>
+ </row>
+ <row><entry><literal><<= (inet, inet)</literal></entry></row>
+ <row><entry><literal>>> (inet, inet)</literal></entry></row>
+ <row><entry><literal>>>= (inet, inet)</literal></entry></row>
+ <row><entry><literal>= (inet, inet)</literal></entry></row>
+ <row><entry><literal><> (inet, inet)</literal></entry></row>
+ <row><entry><literal>< (inet, inet)</literal></entry></row>
+ <row><entry><literal><= (inet, inet)</literal></entry></row>
+ <row><entry><literal>> (inet, inet)</literal></entry></row>
+ <row><entry><literal>>= (inet, inet)</literal></entry></row>
+ <row><entry><literal>&& (inet, inet)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="17"><literal>multirange_ops</literal></entry>
+ <entry><literal>= (anymultirange, anymultirange)</literal></entry>
+ <entry valign="middle" morerows="17"></entry>
+ </row>
+ <row><entry><literal>&& (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>&& (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal>@> (anymultirange, anyelement)</literal></entry></row>
+ <row><entry><literal>@> (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>@> (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal><@ (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal><@ (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal><< (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal><< (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal>>> (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>>> (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal>&< (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>&< (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal>&> (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>&> (anymultirange, anyrange)</literal></entry></row>
+ <row><entry><literal>-|- (anymultirange, anymultirange)</literal></entry></row>
+ <row><entry><literal>-|- (anymultirange, anyrange)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="7"><literal>point_ops</literal></entry>
+ <entry><literal>|>> (point, point)</literal></entry>
+ <entry valign="middle" morerows="7"><literal><-> (point, point)</literal></entry>
+ </row>
+ <row><entry><literal><< (point, point)</literal></entry></row>
+ <row><entry><literal>>> (point, point)</literal></entry></row>
+ <row><entry><literal><<| (point, point)</literal></entry></row>
+ <row><entry><literal>~= (point, point)</literal></entry></row>
+ <row><entry><literal><@ (point, box)</literal></entry></row>
+ <row><entry><literal><@ (point, polygon)</literal></entry></row>
+ <row><entry><literal><@ (point, circle)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="13"><literal>poly_ops</literal></entry>
+ <entry><literal><< (polygon, polygon)</literal></entry>
+ <entry valign="middle" morerows="13"><literal><-> (polygon, point)</literal></entry>
+ </row>
+ <row><entry><literal>&< (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>&> (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>>> (polygon, polygon)</literal></entry></row>
+ <row><entry><literal><@ (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>@> (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>~= (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>&& (polygon, polygon)</literal></entry></row>
+ <row><entry><literal><<| (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>&<| (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>|&> (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>|>> (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>@ (polygon, polygon)</literal></entry></row>
+ <row><entry><literal>~ (polygon, polygon)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="17"><literal>range_ops</literal></entry>
+ <entry><literal>= (anyrange, anyrange)</literal></entry>
+ <entry valign="middle" morerows="17"></entry>
+ </row>
+ <row><entry><literal>&& (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>&& (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal>@> (anyrange, anyelement)</literal></entry></row>
+ <row><entry><literal>@> (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>@> (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal><@ (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal><@ (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal><< (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal><< (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal>>> (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>>> (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal>&< (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>&< (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal>&> (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>&> (anyrange, anymultirange)</literal></entry></row>
+ <row><entry><literal>-|- (anyrange, anyrange)</literal></entry></row>
+ <row><entry><literal>-|- (anyrange, anymultirange)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="1"><literal>tsquery_ops</literal></entry>
+ <entry><literal><@ (tsquery, tsquery)</literal></entry>
+ <entry valign="middle" morerows="1"></entry>
+ </row>
+ <row><entry><literal>@> (tsquery, tsquery)</literal></entry></row>
+ <row>
+ <entry valign="middle"><literal>tsvector_ops</literal></entry>
+ <entry><literal>@@ (tsvector, tsquery)</literal></entry>
+ <entry></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ For historical reasons, the <literal>inet_ops</literal> operator class is
+ not the default class for types <type>inet</type> and <type>cidr</type>.
+ To use it, mention the class name in <command>CREATE INDEX</command>,
+ for example
+<programlisting>
+CREATE INDEX ON my_table USING GIST (my_inet_column inet_ops);
+</programlisting>
+ </para>
+
+ </sect2>
+
+ <sect2 id="gist-extensibility">
+ <title>Extensibility</title>
+
+ <para>
+ Traditionally, implementing a new index access method meant a lot of
+ difficult work. It was necessary to understand the inner workings of the
+ database, such as the lock manager and Write-Ahead Log. The
+ <acronym>GiST</acronym> interface has a high level of abstraction,
+ requiring the access method implementer only to implement the semantics of
+ the data type being accessed. The <acronym>GiST</acronym> layer itself
+ takes care of concurrency, logging and searching the tree structure.
+ </para>
+
+ <para>
+ This extensibility should not be confused with the extensibility of the
+ other standard search trees in terms of the data they can handle. For
+ example, <productname>PostgreSQL</productname> supports extensible B-trees
+ and hash indexes. That means that you can use
+ <productname>PostgreSQL</productname> to build a B-tree or hash over any
+ data type you want. But B-trees only support range predicates
+ (<literal><</literal>, <literal>=</literal>, <literal>></literal>),
+ and hash indexes only support equality queries.
+ </para>
+
+ <para>
+ So if you index, say, an image collection with a
+ <productname>PostgreSQL</productname> B-tree, you can only issue queries
+ such as <quote>is imagex equal to imagey</quote>, <quote>is imagex less
+ than imagey</quote> and <quote>is imagex greater than imagey</quote>.
+ Depending on how you define <quote>equals</quote>, <quote>less than</quote>
+ and <quote>greater than</quote> in this context, this could be useful.
+ However, by using a <acronym>GiST</acronym> based index, you could create
+ ways to ask domain-specific questions, perhaps <quote>find all images of
+ horses</quote> or <quote>find all over-exposed images</quote>.
+ </para>
+
+ <para>
+ All it takes to get a <acronym>GiST</acronym> access method up and running
+ is to implement several user-defined methods, which define the behavior of
+ keys in the tree. Of course these methods have to be pretty fancy to
+ support fancy queries, but for all the standard queries (B-trees,
+ R-trees, etc.) they're relatively straightforward. In short,
+ <acronym>GiST</acronym> combines extensibility along with generality, code
+ reuse, and a clean interface.
+ </para>
+
+ <para>
+ There are five methods that an index operator class for
+ <acronym>GiST</acronym> must provide, and seven that are optional.
+ Correctness of the index is ensured
+ by proper implementation of the <function>same</function>, <function>consistent</function>
+ and <function>union</function> methods, while efficiency (size and speed) of the
+ index will depend on the <function>penalty</function> and <function>picksplit</function>
+ methods.
+ Two optional methods are <function>compress</function> and
+ <function>decompress</function>, which allow an index to have internal tree data of
+ a different type than the data it indexes. The leaves are to be of the
+ indexed data type, while the other tree nodes can be of any C struct (but
+ you still have to follow <productname>PostgreSQL</productname> data type rules here,
+ see about <literal>varlena</literal> for variable sized data). If the tree's
+ internal data type exists at the SQL level, the <literal>STORAGE</literal> option
+ of the <command>CREATE OPERATOR CLASS</command> command can be used.
+ The optional eighth method is <function>distance</function>, which is needed
+ if the operator class wishes to support ordered scans (nearest-neighbor
+ searches). The optional ninth method <function>fetch</function> is needed if the
+ operator class wishes to support index-only scans, except when the
+ <function>compress</function> method is omitted. The optional tenth method
+ <function>options</function> is needed if the operator class has
+ user-specified parameters.
+ The optional eleventh method <function>sortsupport</function> is used to
+ speed up building a <acronym>GiST</acronym> index.
+ The optional twelfth method <function>stratnum</function> is used to
+ translate well-known <literal>RT*StrategyNumber</literal>s (from
+ <filename>src/include/access/stratnum.h</filename>) into strategy numbers
+ used by the operator class. This lets the core code look up operators for
+ temporal constraint indexes.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><function>consistent</function></term>
+ <listitem>
+ <para>
+ Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
+ this function determines whether the index entry is
+ <quote>consistent</quote> with the query; that is, could the predicate
+ <quote><replaceable>indexed_column</replaceable>
+ <replaceable>indexable_operator</replaceable> <literal>q</literal></quote> be true for
+ any row represented by the index entry? For a leaf index entry this is
+ equivalent to testing the indexable condition, while for an internal
+ tree node this determines whether it is necessary to scan the subtree
+ of the index represented by the tree node. When the result is
+ <literal>true</literal>, a <literal>recheck</literal> flag must also be returned.
+ This indicates whether the predicate is certainly true or only possibly
+ true. If <literal>recheck</literal> = <literal>false</literal> then the index has
+ tested the predicate condition exactly, whereas if <literal>recheck</literal>
+ = <literal>true</literal> the row is only a candidate match. In that case the
+ system will automatically evaluate the
+ <replaceable>indexable_operator</replaceable> against the actual row value to see
+ if it is really a match. This convention allows
+ <acronym>GiST</acronym> to support both lossless and lossy index
+ structures.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_consistent(internal, data_type, smallint, oid, internal)
+RETURNS bool
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_consistent);
+
+Datum
+my_consistent(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ data_type *query = PG_GETARG_DATA_TYPE_P(1);
+ StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
+ /* Oid subtype = PG_GETARG_OID(3); */
+ bool *recheck = (bool *) PG_GETARG_POINTER(4);
+ data_type *key = DatumGetDataType(entry->key);
+ bool retval;
+
+ /*
+ * determine return value as a function of strategy, key and query.
+ *
+ * Use GIST_LEAF(entry) to know where you're called in the index tree,
+ * which comes handy when supporting the = operator for example (you could
+ * check for non empty union() in non-leaf nodes and equality in leaf
+ * nodes).
+ */
+
+ *recheck = true; /* or false if check is exact */
+
+ PG_RETURN_BOOL(retval);
+}
+</programlisting>
+
+ Here, <varname>key</varname> is an element in the index and <varname>query</varname>
+ the value being looked up in the index. The <literal>StrategyNumber</literal>
+ parameter indicates which operator of your operator class is being
+ applied — it matches one of the operator numbers in the
+ <command>CREATE OPERATOR CLASS</command> command.
+ </para>
+
+ <para>
+ Depending on which operators you have included in the class, the data
+ type of <varname>query</varname> could vary with the operator, since it will
+ be whatever type is on the right-hand side of the operator, which might
+ be different from the indexed data type appearing on the left-hand side.
+ (The above code skeleton assumes that only one type is possible; if
+ not, fetching the <varname>query</varname> argument value would have to depend
+ on the operator.) It is recommended that the SQL declaration of
+ the <function>consistent</function> function use the opclass's indexed data
+ type for the <varname>query</varname> argument, even though the actual type
+ might be something else depending on the operator.
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>union</function></term>
+ <listitem>
+ <para>
+ This method consolidates information in the tree. Given a set of
+ entries, this function generates a new index entry that represents
+ all the given entries.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_union(internal, internal)
+RETURNS storage_type
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_union);
+
+Datum
+my_union(PG_FUNCTION_ARGS)
+{
+ GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
+ GISTENTRY *ent = entryvec->vector;
+ data_type *out,
+ *tmp,
+ *old;
+ int numranges,
+ i = 0;
+
+ numranges = entryvec->n;
+ tmp = DatumGetDataType(ent[0].key);
+ out = tmp;
+
+ if (numranges == 1)
+ {
+ out = data_type_deep_copy(tmp);
+
+ PG_RETURN_DATA_TYPE_P(out);
+ }
+
+ for (i = 1; i < numranges; i++)
+ {
+ old = out;
+ tmp = DatumGetDataType(ent[i].key);
+ out = my_union_implementation(out, tmp);
+ }
+
+ PG_RETURN_DATA_TYPE_P(out);
+}
+</programlisting>
+ </para>
+
+ <para>
+ As you can see, in this skeleton we're dealing with a data type
+ where <literal>union(X, Y, Z) = union(union(X, Y), Z)</literal>. It's easy
+ enough to support data types where this is not the case, by
+ implementing the proper union algorithm in this
+ <acronym>GiST</acronym> support method.
+ </para>
+
+ <para>
+ The result of the <function>union</function> function must be a value of the
+ index's storage type, whatever that is (it might or might not be
+ different from the indexed column's type). The <function>union</function>
+ function should return a pointer to newly <function>palloc()</function>ed
+ memory. You can't just return the input value as-is, even if there is
+ no type change.
+ </para>
+
+ <para>
+ As shown above, the <function>union</function> function's
+ first <type>internal</type> argument is actually
+ a <structname>GistEntryVector</structname> pointer. The second argument is a
+ pointer to an integer variable, which can be ignored. (It used to be
+ required that the <function>union</function> function store the size of its
+ result value into that variable, but this is no longer necessary.)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>compress</function></term>
+ <listitem>
+ <para>
+ Converts a data item into a format suitable for physical storage in
+ an index page.
+ If the <function>compress</function> method is omitted, data items are stored
+ in the index without modification.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_compress(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_compress);
+
+Datum
+my_compress(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ GISTENTRY *retval;
+
+ if (entry->leafkey)
+ {
+ /* replace entry->key with a compressed version */
+ compressed_data_type *compressed_data = palloc(sizeof(compressed_data_type));
+
+ /* fill *compressed_data from entry->key ... */
+
+ retval = palloc(sizeof(GISTENTRY));
+ gistentryinit(*retval, PointerGetDatum(compressed_data),
+ entry->rel, entry->page, entry->offset, FALSE);
+ }
+ else
+ {
+ /* typically we needn't do anything with non-leaf entries */
+ retval = entry;
+ }
+
+ PG_RETURN_POINTER(retval);
+}
+</programlisting>
+ </para>
+
+ <para>
+ You have to adapt <replaceable>compressed_data_type</replaceable> to the specific
+ type you're converting to in order to compress your leaf nodes, of
+ course.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>decompress</function></term>
+ <listitem>
+ <para>
+ Converts the stored representation of a data item into a format that
+ can be manipulated by the other GiST methods in the operator class.
+ If the <function>decompress</function> method is omitted, it is assumed that
+ the other GiST methods can work directly on the stored data format.
+ (<function>decompress</function> is not necessarily the reverse of
+ the <function>compress</function> method; in particular,
+ if <function>compress</function> is lossy then it's impossible
+ for <function>decompress</function> to exactly reconstruct the original
+ data. <function>decompress</function> is not necessarily equivalent
+ to <function>fetch</function>, either, since the other GiST methods might not
+ require full reconstruction of the data.)
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_decompress(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_decompress);
+
+Datum
+my_decompress(PG_FUNCTION_ARGS)
+{
+ PG_RETURN_POINTER(PG_GETARG_POINTER(0));
+}
+</programlisting>
+
+ The above skeleton is suitable for the case where no decompression
+ is needed. (But, of course, omitting the method altogether is even
+ easier, and is recommended in such cases.)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>penalty</function></term>
+ <listitem>
+ <para>
+ Returns a value indicating the <quote>cost</quote> of inserting the new
+ entry into a particular branch of the tree. Items will be inserted
+ down the path of least <function>penalty</function> in the tree.
+ Values returned by <function>penalty</function> should be non-negative.
+ If a negative value is returned, it will be treated as zero.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_penalty(internal, internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT; -- in some cases penalty functions need not be strict
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_penalty);
+
+Datum
+my_penalty(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *origentry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ GISTENTRY *newentry = (GISTENTRY *) PG_GETARG_POINTER(1);
+ float *penalty = (float *) PG_GETARG_POINTER(2);
+ data_type *orig = DatumGetDataType(origentry->key);
+ data_type *new = DatumGetDataType(newentry->key);
+
+ *penalty = my_penalty_implementation(orig, new);
+ PG_RETURN_POINTER(penalty);
+}
+</programlisting>
+
+ For historical reasons, the <function>penalty</function> function doesn't
+ just return a <type>float</type> result; instead it has to store the value
+ at the location indicated by the third argument. The return
+ value per se is ignored, though it's conventional to pass back the
+ address of that argument.
+ </para>
+
+ <para>
+ The <function>penalty</function> function is crucial to good performance of
+ the index. It'll get used at insertion time to determine which branch
+ to follow when choosing where to add the new entry in the tree. At
+ query time, the more balanced the index, the quicker the lookup.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>picksplit</function></term>
+ <listitem>
+ <para>
+ When an index page split is necessary, this function decides which
+ entries on the page are to stay on the old page, and which are to move
+ to the new page.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_picksplit(internal, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_picksplit);
+
+Datum
+my_picksplit(PG_FUNCTION_ARGS)
+{
+ GistEntryVector *entryvec = (GistEntryVector *) PG_GETARG_POINTER(0);
+ GIST_SPLITVEC *v = (GIST_SPLITVEC *) PG_GETARG_POINTER(1);
+ OffsetNumber maxoff = entryvec->n - 1;
+ GISTENTRY *ent = entryvec->vector;
+ int i,
+ nbytes;
+ OffsetNumber *left,
+ *right;
+ data_type *tmp_union;
+ data_type *unionL;
+ data_type *unionR;
+ GISTENTRY **raw_entryvec;
+
+ maxoff = entryvec->n - 1;
+ nbytes = (maxoff + 1) * sizeof(OffsetNumber);
+
+ v->spl_left = (OffsetNumber *) palloc(nbytes);
+ left = v->spl_left;
+ v->spl_nleft = 0;
+
+ v->spl_right = (OffsetNumber *) palloc(nbytes);
+ right = v->spl_right;
+ v->spl_nright = 0;
+
+ unionL = NULL;
+ unionR = NULL;
+
+ /* Initialize the raw entry vector. */
+ raw_entryvec = (GISTENTRY **) malloc(entryvec->n * sizeof(void *));
+ for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
+ raw_entryvec[i] = &(entryvec->vector[i]);
+
+ for (i = FirstOffsetNumber; i <= maxoff; i = OffsetNumberNext(i))
+ {
+ int real_index = raw_entryvec[i] - entryvec->vector;
+
+ tmp_union = DatumGetDataType(entryvec->vector[real_index].key);
+ Assert(tmp_union != NULL);
+
+ /*
+ * Choose where to put the index entries and update unionL and unionR
+ * accordingly. Append the entries to either v->spl_left or
+ * v->spl_right, and care about the counters.
+ */
+
+ if (my_choice_is_left(unionL, curl, unionR, curr))
+ {
+ if (unionL == NULL)
+ unionL = tmp_union;
+ else
+ unionL = my_union_implementation(unionL, tmp_union);
+
+ *left = real_index;
+ ++left;
+ ++(v->spl_nleft);
+ }
+ else
+ {
+ /*
+ * Same on the right
+ */
+ }
+ }
+
+ v->spl_ldatum = DataTypeGetDatum(unionL);
+ v->spl_rdatum = DataTypeGetDatum(unionR);
+ PG_RETURN_POINTER(v);
+}
+</programlisting>
+
+ Notice that the <function>picksplit</function> function's result is delivered
+ by modifying the passed-in <structname>v</structname> structure. The return
+ value per se is ignored, though it's conventional to pass back the
+ address of <structname>v</structname>.
+ </para>
+
+ <para>
+ Like <function>penalty</function>, the <function>picksplit</function> function
+ is crucial to good performance of the index. Designing suitable
+ <function>penalty</function> and <function>picksplit</function> implementations
+ is where the challenge of implementing well-performing
+ <acronym>GiST</acronym> indexes lies.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>same</function></term>
+ <listitem>
+ <para>
+ Returns true if two index entries are identical, false otherwise.
+ (An <quote>index entry</quote> is a value of the index's storage type,
+ not necessarily the original indexed column's type.)
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_same(storage_type, storage_type, internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_same);
+
+Datum
+my_same(PG_FUNCTION_ARGS)
+{
+ prefix_range *v1 = PG_GETARG_PREFIX_RANGE_P(0);
+ prefix_range *v2 = PG_GETARG_PREFIX_RANGE_P(1);
+ bool *result = (bool *) PG_GETARG_POINTER(2);
+
+ *result = my_eq(v1, v2);
+ PG_RETURN_POINTER(result);
+}
+</programlisting>
+
+ For historical reasons, the <function>same</function> function doesn't
+ just return a Boolean result; instead it has to store the flag
+ at the location indicated by the third argument. The return
+ value per se is ignored, though it's conventional to pass back the
+ address of that argument.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>distance</function></term>
+ <listitem>
+ <para>
+ Given an index entry <literal>p</literal> and a query value <literal>q</literal>,
+ this function determines the index entry's
+ <quote>distance</quote> from the query value. This function must be
+ supplied if the operator class contains any ordering operators.
+ A query using the ordering operator will be implemented by returning
+ index entries with the smallest <quote>distance</quote> values first,
+ so the results must be consistent with the operator's semantics.
+ For a leaf index entry the result just represents the distance to
+ the index entry; for an internal tree node, the result must be the
+ smallest distance that any child entry could have.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_distance(internal, data_type, smallint, oid, internal)
+RETURNS float8
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ And the matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_distance);
+
+Datum
+my_distance(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ data_type *query = PG_GETARG_DATA_TYPE_P(1);
+ StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(2);
+ /* Oid subtype = PG_GETARG_OID(3); */
+ /* bool *recheck = (bool *) PG_GETARG_POINTER(4); */
+ data_type *key = DatumGetDataType(entry->key);
+ double retval;
+
+ /*
+ * determine return value as a function of strategy, key and query.
+ */
+
+ PG_RETURN_FLOAT8(retval);
+}
+</programlisting>
+
+ The arguments to the <function>distance</function> function are identical to
+ the arguments of the <function>consistent</function> function.
+ </para>
+
+ <para>
+ Some approximation is allowed when determining the distance, so long
+ as the result is never greater than the entry's actual distance. Thus,
+ for example, distance to a bounding box is usually sufficient in
+ geometric applications. For an internal tree node, the distance
+ returned must not be greater than the distance to any of the child
+ nodes. If the returned distance is not exact, the function must set
+ <literal>*recheck</literal> to true. (This is not necessary for internal tree
+ nodes; for them, the calculation is always assumed to be inexact.) In
+ this case the executor will calculate the accurate distance after
+ fetching the tuple from the heap, and reorder the tuples if necessary.
+ </para>
+
+ <para>
+ If the distance function returns <literal>*recheck = true</literal> for any
+ leaf node, the original ordering operator's return type must
+ be <type>float8</type> or <type>float4</type>, and the distance function's
+ result values must be comparable to those of the original ordering
+ operator, since the executor will sort using both distance function
+ results and recalculated ordering-operator results. Otherwise, the
+ distance function's result values can be any finite <type>float8</type>
+ values, so long as the relative order of the result values matches the
+ order returned by the ordering operator. (Infinity and minus infinity
+ are used internally to handle cases such as nulls, so it is not
+ recommended that <function>distance</function> functions return these values.)
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>fetch</function></term>
+ <listitem>
+ <para>
+ Converts the compressed index representation of a data item into the
+ original data type, for index-only scans. The returned data must be an
+ exact, non-lossy copy of the originally indexed value.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_fetch(internal)
+RETURNS internal
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ The argument is a pointer to a <structname>GISTENTRY</structname> struct. On
+ entry, its <structfield>key</structfield> field contains a non-NULL leaf datum in
+ compressed form. The return value is another <structname>GISTENTRY</structname>
+ struct, whose <structfield>key</structfield> field contains the same datum in its
+ original, uncompressed form. If the opclass's compress function does
+ nothing for leaf entries, the <function>fetch</function> method can return the
+ argument as-is. Or, if the opclass does not have a compress function,
+ the <function>fetch</function> method can be omitted as well, since it would
+ necessarily be a no-op.
+ </para>
+
+ <para>
+ The matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_fetch);
+
+Datum
+my_fetch(PG_FUNCTION_ARGS)
+{
+ GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0);
+ input_data_type *in = DatumGetPointer(entry->key);
+ fetched_data_type *fetched_data;
+ GISTENTRY *retval;
+
+ retval = palloc(sizeof(GISTENTRY));
+ fetched_data = palloc(sizeof(fetched_data_type));
+
+ /*
+ * Convert 'fetched_data' into the a Datum of the original datatype.
+ */
+
+ /* fill *retval from fetched_data. */
+ gistentryinit(*retval, PointerGetDatum(converted_datum),
+ entry->rel, entry->page, entry->offset, FALSE);
+
+ PG_RETURN_POINTER(retval);
+}
+</programlisting>
+ </para>
+
+ <para>
+ If the compress method is lossy for leaf entries, the operator class
+ cannot support index-only scans, and must not define
+ a <function>fetch</function> function.
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>options</function></term>
+ <listitem>
+ <para>
+ Allows definition of user-visible parameters that control operator
+ class behavior.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_options(internal)
+RETURNS void
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+ </para>
+
+ <para>
+ The function is passed a pointer to a <structname>local_relopts</structname>
+ struct, which needs to be filled with a set of operator class
+ specific options. The options can be accessed from other support
+ functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
+ <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
+ </para>
+
+ <para>
+ An example implementation of my_options() and parameters use
+ from other support functions are given below:
+
+<programlisting>
+typedef enum MyEnumType
+{
+ MY_ENUM_ON,
+ MY_ENUM_OFF,
+ MY_ENUM_AUTO
+} MyEnumType;
+
+typedef struct
+{
+ int32 vl_len_; /* varlena header (do not touch directly!) */
+ int int_param; /* integer parameter */
+ double real_param; /* real parameter */
+ MyEnumType enum_param; /* enum parameter */
+ int str_param; /* string parameter */
+} MyOptionsStruct;
+
+/* String representation of enum values */
+static relopt_enum_elt_def myEnumValues[] =
+{
+ {"on", MY_ENUM_ON},
+ {"off", MY_ENUM_OFF},
+ {"auto", MY_ENUM_AUTO},
+ {(const char *) NULL} /* list terminator */
+};
+
+static char *str_param_default = "default";
+
+/*
+ * Sample validator: checks that string is not longer than 8 bytes.
+ */
+static void
+validate_my_string_relopt(const char *value)
+{
+ if (strlen(value) > 8)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("str_param must be at most 8 bytes")));
+}
+
+/*
+ * Sample filler: switches characters to lower case.
+ */
+static Size
+fill_my_string_relopt(const char *value, void *ptr)
+{
+ char *tmp = str_tolower(value, strlen(value), DEFAULT_COLLATION_OID);
+ int len = strlen(tmp);
+
+ if (ptr)
+ strcpy((char *) ptr, tmp);
+
+ pfree(tmp);
+ return len + 1;
+}
+
+PG_FUNCTION_INFO_V1(my_options);
+
+Datum
+my_options(PG_FUNCTION_ARGS)
+{
+ local_relopts *relopts = (local_relopts *) PG_GETARG_POINTER(0);
+
+ init_local_reloptions(relopts, sizeof(MyOptionsStruct));
+ add_local_int_reloption(relopts, "int_param", "integer parameter",
+ 100, 0, 1000000,
+ offsetof(MyOptionsStruct, int_param));
+ add_local_real_reloption(relopts, "real_param", "real parameter",
+ 1.0, 0.0, 1000000.0,
+ offsetof(MyOptionsStruct, real_param));
+ add_local_enum_reloption(relopts, "enum_param", "enum parameter",
+ myEnumValues, MY_ENUM_ON,
+ "Valid values are: \"on\", \"off\" and \"auto\".",
+ offsetof(MyOptionsStruct, enum_param));
+ add_local_string_reloption(relopts, "str_param", "string parameter",
+ str_param_default,
+ &validate_my_string_relopt,
+ &fill_my_string_relopt,
+ offsetof(MyOptionsStruct, str_param));
+
+ PG_RETURN_VOID();
+}
+
+PG_FUNCTION_INFO_V1(my_compress);
+
+Datum
+my_compress(PG_FUNCTION_ARGS)
+{
+ int int_param = 100;
+ double real_param = 1.0;
+ MyEnumType enum_param = MY_ENUM_ON;
+ char *str_param = str_param_default;
+
+ /*
+ * Normally, when opclass contains 'options' method, then options are always
+ * passed to support functions. However, if you add 'options' method to
+ * existing opclass, previously defined indexes have no options, so the
+ * check is required.
+ */
+ if (PG_HAS_OPCLASS_OPTIONS())
+ {
+ MyOptionsStruct *options = (MyOptionsStruct *) PG_GET_OPCLASS_OPTIONS();
+
+ int_param = options->int_param;
+ real_param = options->real_param;
+ enum_param = options->enum_param;
+ str_param = GET_STRING_RELOPTION(options, str_param);
+ }
+
+ /* the rest implementation of support function */
+}
+
+</programlisting>
+ </para>
+
+ <para>
+ Since the representation of the key in <acronym>GiST</acronym> is
+ flexible, it may depend on user-specified parameters. For instance,
+ the length of key signature may be specified. See
+ <literal>gtsvector_options()</literal> for example.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>sortsupport</function></term>
+ <listitem>
+ <para>
+ Returns a comparator function to sort data in a way that preserves
+ locality. It is used by <command>CREATE INDEX</command> and
+ <command>REINDEX</command> commands. The quality of the created index
+ depends on how well the sort order determined by the comparator function
+ preserves locality of the inputs.
+ </para>
+ <para>
+ The <function>sortsupport</function> method is optional. If it is not
+ provided, <command>CREATE INDEX</command> builds the index by inserting
+ each tuple to the tree using the <function>penalty</function> and
+ <function>picksplit</function> functions, which is much slower.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like
+ this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_sortsupport(internal)
+RETURNS void
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+
+ The argument is a pointer to a <structname>SortSupport</structname>
+ struct. At a minimum, the function must fill in its comparator field.
+ The comparator takes three arguments: two Datums to compare, and
+ a pointer to the <structname>SortSupport</structname> struct. The
+ Datums are the two indexed values in the format that they are stored
+ in the index; that is, in the format returned by the
+ <function>compress</function> method. The full API is defined in
+ <filename>src/include/utils/sortsupport.h</filename>.
+ </para>
+
+ <para>
+ The matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_sortsupport);
+
+static int
+my_fastcmp(Datum x, Datum y, SortSupport ssup)
+{
+ /* establish order between x and y by computing some sorting value z */
+
+ int z1 = ComputeSpatialCode(x);
+ int z2 = ComputeSpatialCode(y);
+
+ return z1 == z2 ? 0 : z1 > z2 ? 1 : -1;
+}
+
+Datum
+my_sortsupport(PG_FUNCTION_ARGS)
+{
+ SortSupport ssup = (SortSupport) PG_GETARG_POINTER(0);
+
+ ssup->comparator = my_fastcmp;
+ PG_RETURN_VOID();
+}
+</programlisting>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>stratnum</function></term>
+ <listitem>
+ <para>
+ Given an <literal>RT*StrategyNumber</literal> value from
+ <filename>src/include/access/stratnum.h</filename>, returns a strategy
+ number used by this operator class for matching functionality. The
+ function should return <literal>InvalidStrategy</literal> if the
+ operator class has no matching strategy.
+ </para>
+
+ <para>
+ This is used for temporal index constraints (i.e., <literal>PRIMARY
+ KEY</literal> and <literal>UNIQUE</literal>). If the operator class
+ provides this function and it returns results for
+ <literal>RTEqualStrategyNumber</literal>, it can be used in the
+ non-<literal>WITHOUT OVERLAPS</literal> part(s) of an index constraint.
+ If it returns results for <literal>RTOverlapStrategyNumber</literal>,
+ the operator class can be used in the <literal>WITHOUT
+ OVERLAPS</literal> part of an index constraint.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like
+ this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_stratnum(integer)
+RETURNS integer
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+ </para>
+
+ <para>
+ The matching code in the C module could then follow this skeleton:
+
+<programlisting>
+PG_FUNCTION_INFO_V1(my_stratnum);
+
+Datum
+my_stratnum(PG_FUNCTION_ARGS)
+{
+ StrategyNumber strategy = (StrategyNumber) PG_GETARG_UINT16(1);
+ StrategyNumber ret = InvalidStrategy;
+
+ switch (strategy)
+ {
+ case RTEqualStrategyNumber:
+ ret = BTEqualStrategyNumber;
+ }
+
+ PG_RETURN_UINT16(ret);
+}
+ </programlisting>
+ </para>
+
+ <para>
+ One translation function is provided by
+ <productname>PostgreSQL</productname>:
+ <literal>gist_stratnum_identity</literal> is for operator classes that
+ already use the <literal>RT*StrategyNumber</literal> constants. It
+ returns whatever is passed to it. The <literal>btree_gist</literal>
+ extension defines a second translation function,
+ <literal>gist_stratnum_btree</literal>, for operator classes that use
+ the <literal>BT*StrategyNumber</literal> constants.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ All the GiST support methods are normally called in short-lived memory
+ contexts; that is, <varname>CurrentMemoryContext</varname> will get reset after
+ each tuple is processed. It is therefore not very important to worry about
+ pfree'ing everything you palloc. However, in some cases it's useful for a
+ support method to cache data across repeated calls. To do that, allocate
+ the longer-lived data in <literal>fcinfo->flinfo->fn_mcxt</literal>, and
+ keep a pointer to it in <literal>fcinfo->flinfo->fn_extra</literal>. Such
+ data will survive for the life of the index operation (e.g., a single GiST
+ index scan, index build, or index tuple insertion). Be careful to pfree
+ the previous value when replacing a <literal>fn_extra</literal> value, or the leak
+ will accumulate for the duration of the operation.
+ </para>
+
+ </sect2>
+
+ <sect2 id="gist-implementation">
+ <title>Implementation</title>
+
+ <sect3 id="gist-buffering-build">
+ <title>GiST Index Build Methods</title>
+
+ <para>
+ The simplest way to build a GiST index is just to insert all the entries,
+ one by one. This tends to be slow for large indexes, because if the
+ index tuples are scattered across the index and the index is large enough
+ to not fit in cache, a lot of random I/O will be
+ needed. <productname>PostgreSQL</productname> supports two alternative
+ methods for initial build of a GiST index: <firstterm>sorted</firstterm>
+ and <firstterm>buffered</firstterm> modes.
+ </para>
+
+ <para>
+ The sorted method is only available if each of the opclasses used by the
+ index provides a <function>sortsupport</function> function, as described
+ in <xref linkend="gist-extensibility"/>. If they do, this method is
+ usually the best, so it is used by default.
+ </para>
+
+ <para>
+ The buffered method works by not inserting tuples directly into the index
+ right away. It can dramatically reduce the amount of random I/O needed
+ for non-ordered data sets. For well-ordered data sets the benefit is
+ smaller or non-existent, because only a small number of pages receive new
+ tuples at a time, and those pages fit in cache even if the index as a
+ whole does not.
+ </para>
+
+ <para>
+ The buffered method needs to call the <function>penalty</function>
+ function more often than the simple method does, which consumes some
+ extra CPU resources. Also, the buffers need temporary disk space, up to
+ the size of the resulting index. Buffering can also influence the quality
+ of the resulting index, in both positive and negative directions. That
+ influence depends on various factors, like the distribution of the input
+ data and the operator class implementation.
+ </para>
+
+ <para>
+ If sorting is not possible, then by default a GiST index build switches
+ to the buffering method when the index size reaches
+ <xref linkend="guc-effective-cache-size"/>. Buffering can be manually
+ forced or prevented by the <literal>buffering</literal> parameter to the
+ CREATE INDEX command. The default behavior is good for most cases, but
+ turning buffering off might speed up the build somewhat if the input data
+ is ordered.
+ </para>
+
+ </sect3>
+ </sect2>
+
+ <sect2 id="gist-examples">
+ <title>Examples</title>
+
+ <para>
+ The <productname>PostgreSQL</productname> source distribution includes
+ several examples of index methods implemented using
+ <acronym>GiST</acronym>. The core system currently provides text search
+ support (indexing for <type>tsvector</type> and <type>tsquery</type>) as well as
+ R-Tree equivalent functionality for some of the built-in geometric data types
+ (see <filename>src/backend/access/gist/gistproc.c</filename>). The following
+ <filename>contrib</filename> modules also contain <acronym>GiST</acronym>
+ operator classes:
+
+ <variablelist>
+ <varlistentry>
+ <term><filename>btree_gist</filename></term>
+ <listitem>
+ <para>B-tree equivalent functionality for several data types</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>cube</filename></term>
+ <listitem>
+ <para>Indexing for multidimensional cubes</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>hstore</filename></term>
+ <listitem>
+ <para>Module for storing (key, value) pairs</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>intarray</filename></term>
+ <listitem>
+ <para>RD-Tree for one-dimensional array of int4 values</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>ltree</filename></term>
+ <listitem>
+ <para>Indexing for tree-like structures</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>pg_trgm</filename></term>
+ <listitem>
+ <para>Text similarity using trigram matching</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>seg</filename></term>
+ <listitem>
+ <para>Indexing for <quote>float ranges</quote></para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="spgist">
+ <title>SP-GiST Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>SP-GiST</secondary>
+ </indexterm>
+
+ <sect2 id="spgist-intro">
+ <title>Introduction</title>
+
+ <para>
+ <acronym>SP-GiST</acronym> is an abbreviation for space-partitioned
+ <acronym>GiST</acronym>. <acronym>SP-GiST</acronym> supports partitioned
+ search trees, which facilitate development of a wide range of different
+ non-balanced data structures, such as quad-trees, k-d trees, and radix
+ trees (tries). The common feature of these structures is that they
+ repeatedly divide the search space into partitions that need not be
+ of equal size. Searches that are well matched to the partitioning rule
+ can be very fast.
+ </para>
+
+ <para>
+ These popular data structures were originally developed for in-memory
+ usage. In main memory, they are usually designed as a set of dynamically
+ allocated nodes linked by pointers. This is not suitable for direct
+ storing on disk, since these chains of pointers can be rather long which
+ would require too many disk accesses. In contrast, disk-based data
+ structures should have a high fanout to minimize I/O. The challenge
+ addressed by <acronym>SP-GiST</acronym> is to map search tree nodes to
+ disk pages in such a way that a search need access only a few disk pages,
+ even if it traverses many nodes.
+ </para>
+
+ <para>
+ Like <acronym>GiST</acronym>, <acronym>SP-GiST</acronym> is meant to allow
+ the development of custom data types with the appropriate access methods,
+ by an expert in the domain of the data type, rather than a database expert.
+ </para>
+
+ <para>
+ Some of the information here is derived from Purdue University's
+ SP-GiST Indexing Project
+ <ulink url="https://www.cs.purdue.edu/spgist/">web site</ulink>.
+ The <acronym>SP-GiST</acronym> implementation in
+ <productname>PostgreSQL</productname> is primarily maintained by Teodor
+ Sigaev and Oleg Bartunov, and there is more information on their
+ <!-- URL will be changed -->
+ <ulink url="http://www.sai.msu.su/~megera/wiki/spgist_dev">web site</ulink>.
+ </para>
+
+ </sect2>
+
+ <sect2 id="spgist-builtin-opclasses">
+ <title>Built-in Operator Classes</title>
+
+ <para>
+ The core <productname>PostgreSQL</productname> distribution
+ includes the <acronym>SP-GiST</acronym> operator classes shown in
+ <xref linkend="spgist-builtin-opclasses-table"/>.
+ </para>
+
+ <table id="spgist-builtin-opclasses-table">
+ <title>Built-in <acronym>SP-GiST</acronym> Operator Classes</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Indexable Operators</entry>
+ <entry>Ordering Operators</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry valign="middle" morerows="11"><literal>box_ops</literal></entry>
+ <entry><literal><< (box,box)</literal></entry>
+ <entry valign="middle" morerows="11"><literal><-> (box,point)</literal></entry>
+ </row>
+ <row><entry><literal>&< (box,box)</literal></entry></row>
+ <row><entry><literal>&> (box,box)</literal></entry></row>
+ <row><entry><literal>>> (box,box)</literal></entry></row>
+ <row><entry><literal><@ (box,box)</literal></entry></row>
+ <row><entry><literal>@> (box,box)</literal></entry></row>
+ <row><entry><literal>~= (box,box)</literal></entry></row>
+ <row><entry><literal>&& (box,box)</literal></entry></row>
+ <row><entry><literal><<| (box,box)</literal></entry></row>
+ <row><entry><literal>&<| (box,box)</literal></entry></row>
+ <row><entry><literal>|&> (box,box)</literal></entry></row>
+ <row><entry><literal>|>> (box,box)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="10"><literal>inet_ops</literal></entry>
+ <entry><literal><< (inet,inet)</literal></entry>
+ <entry valign="middle" morerows="10"></entry>
+ </row>
+ <row><entry><literal><<= (inet,inet)</literal></entry></row>
+ <row><entry><literal>>> (inet,inet)</literal></entry></row>
+ <row><entry><literal>>>= (inet,inet)</literal></entry></row>
+ <row><entry><literal>= (inet,inet)</literal></entry></row>
+ <row><entry><literal><> (inet,inet)</literal></entry></row>
+ <row><entry><literal>< (inet,inet)</literal></entry></row>
+ <row><entry><literal><= (inet,inet)</literal></entry></row>
+ <row><entry><literal>> (inet,inet)</literal></entry></row>
+ <row><entry><literal>>= (inet,inet)</literal></entry></row>
+ <row><entry><literal>&& (inet,inet)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="5"><literal>kd_point_ops</literal></entry>
+ <entry><literal>|>> (point,point)</literal></entry>
+ <entry valign="middle" morerows="5"><literal><-> (point,point)</literal></entry>
+ </row>
+ <row><entry><literal><< (point,point)</literal></entry></row>
+ <row><entry><literal>>> (point,point)</literal></entry></row>
+ <row><entry><literal><<| (point,point)</literal></entry></row>
+ <row><entry><literal>~= (point,point)</literal></entry></row>
+ <row><entry><literal><@ (point,box)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="11"><literal>poly_ops</literal></entry>
+ <entry><literal><< (polygon,polygon)</literal></entry>
+ <entry valign="middle" morerows="11"><literal><-> (polygon,point)</literal></entry>
+ </row>
+ <row><entry><literal>&< (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>&> (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>>> (polygon,polygon)</literal></entry></row>
+ <row><entry><literal><@ (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>@> (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>~= (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>&& (polygon,polygon)</literal></entry></row>
+ <row><entry><literal><<| (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>&<| (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>|>> (polygon,polygon)</literal></entry></row>
+ <row><entry><literal>|&> (polygon,polygon)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="5"><literal>quad_point_ops</literal></entry>
+ <entry><literal>|>> (point,point)</literal></entry>
+ <entry valign="middle" morerows="5"><literal><-> (point,point)</literal></entry>
+ </row>
+ <row><entry><literal><< (point,point)</literal></entry></row>
+ <row><entry><literal>>> (point,point)</literal></entry></row>
+ <row><entry><literal><<| (point,point)</literal></entry></row>
+ <row><entry><literal>~= (point,point)</literal></entry></row>
+ <row><entry><literal><@ (point,box)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="9"><literal>range_ops</literal></entry>
+ <entry><literal>= (anyrange,anyrange)</literal></entry>
+ <entry valign="middle" morerows="9"></entry>
+ </row>
+ <row><entry><literal>&& (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>@> (anyrange,anyelement)</literal></entry></row>
+ <row><entry><literal>@> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal><@ (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal><< (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>>> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>&< (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>&> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>-|- (anyrange,anyrange)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="9"><literal>text_ops</literal></entry>
+ <entry><literal>= (text,text)</literal></entry>
+ <entry valign="middle" morerows="9"></entry>
+ </row>
+ <row><entry><literal>< (text,text)</literal></entry></row>
+ <row><entry><literal><= (text,text)</literal></entry></row>
+ <row><entry><literal>> (text,text)</literal></entry></row>
+ <row><entry><literal>>= (text,text)</literal></entry></row>
+ <row><entry><literal>~<~ (text,text)</literal></entry></row>
+ <row><entry><literal>~<=~ (text,text)</literal></entry></row>
+ <row><entry><literal>~>=~ (text,text)</literal></entry></row>
+ <row><entry><literal>~>~ (text,text)</literal></entry></row>
+ <row><entry><literal>^@ (text,text)</literal></entry></row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Of the two operator classes for type <type>point</type>,
+ <literal>quad_point_ops</literal> is the default. <literal>kd_point_ops</literal>
+ supports the same operators but uses a different index data structure that
+ may offer better performance in some applications.
+ </para>
+ <para>
+ The <literal>quad_point_ops</literal>, <literal>kd_point_ops</literal> and
+ <literal>poly_ops</literal> operator classes support the <literal><-></literal>
+ ordering operator, which enables the k-nearest neighbor (<literal>k-NN</literal>)
+ search over indexed point or polygon data sets.
+ </para>
+
+ </sect2>
+
+ <sect2 id="spgist-extensibility">
+ <title>Extensibility</title>
+
+ <para>
+ <acronym>SP-GiST</acronym> offers an interface with a high level of
+ abstraction, requiring the access method developer to implement only
+ methods specific to a given data type. The <acronym>SP-GiST</acronym> core
+ is responsible for efficient disk mapping and searching the tree structure.
+ It also takes care of concurrency and logging considerations.
+ </para>
+
+ <para>
+ Leaf tuples of an <acronym>SP-GiST</acronym> tree usually contain values
+ of the same data type as the indexed column, although it is also possible
+ for them to contain lossy representations of the indexed column.
+ Leaf tuples stored at the root level will directly represent
+ the original indexed data value, but leaf tuples at lower
+ levels might contain only a partial value, such as a suffix.
+ In that case the operator class support functions must be able to
+ reconstruct the original value using information accumulated from the
+ inner tuples that are passed through to reach the leaf level.
+ </para>
+
+ <para>
+ When an <acronym>SP-GiST</acronym> index is created with
+ <literal>INCLUDE</literal> columns, the values of those columns are also
+ stored in leaf tuples. The <literal>INCLUDE</literal> columns are of no
+ concern to the <acronym>SP-GiST</acronym> operator class, so they are
+ not discussed further here.
+ </para>
+
+ <para>
+ Inner tuples are more complex, since they are branching points in the
+ search tree. Each inner tuple contains a set of one or more
+ <firstterm>nodes</firstterm>, which represent groups of similar leaf values.
+ A node contains a downlink that leads either to another, lower-level inner
+ tuple, or to a short list of leaf tuples that all lie on the same index page.
+ Each node normally has a <firstterm>label</firstterm> that describes it; for example,
+ in a radix tree the node label could be the next character of the string
+ value. (Alternatively, an operator class can omit the node labels, if it
+ works with a fixed set of nodes for all inner tuples;
+ see <xref linkend="spgist-null-labels"/>.)
+ Optionally, an inner tuple can have a <firstterm>prefix</firstterm> value
+ that describes all its members. In a radix tree this could be the common
+ prefix of the represented strings. The prefix value is not necessarily
+ really a prefix, but can be any data needed by the operator class;
+ for example, in a quad-tree it can store the central point that the four
+ quadrants are measured with respect to. A quad-tree inner tuple would
+ then also contain four nodes corresponding to the quadrants around this
+ central point.
+ </para>
+
+ <para>
+ Some tree algorithms require knowledge of level (or depth) of the current
+ tuple, so the <acronym>SP-GiST</acronym> core provides the possibility for
+ operator classes to manage level counting while descending the tree.
+ There is also support for incrementally reconstructing the represented
+ value when that is needed, and for passing down additional data (called
+ <firstterm>traverse values</firstterm>) during a tree descent.
+ </para>
+
+ <note>
+ <para>
+ The <acronym>SP-GiST</acronym> core code takes care of null entries.
+ Although <acronym>SP-GiST</acronym> indexes do store entries for nulls
+ in indexed columns, this is hidden from the index operator class code:
+ no null index entries or search conditions will ever be passed to the
+ operator class methods. (It is assumed that <acronym>SP-GiST</acronym>
+ operators are strict and so cannot succeed for null values.) Null values
+ are therefore not discussed further here.
+ </para>
+ </note>
+
+ <para>
+ There are five user-defined methods that an index operator class for
+ <acronym>SP-GiST</acronym> must provide, and two are optional. All five
+ mandatory methods follow the convention of accepting two <type>internal</type>
+ arguments, the first of which is a pointer to a C struct containing input
+ values for the support method, while the second argument is a pointer to a
+ C struct where output values must be placed. Four of the mandatory methods just
+ return <type>void</type>, since all their results appear in the output struct; but
+ <function>leaf_consistent</function> returns a <type>boolean</type> result.
+ The methods must not modify any fields of their input structs. In all
+ cases, the output struct is initialized to zeroes before calling the
+ user-defined method. The optional sixth method <function>compress</function>
+ accepts a <type>datum</type> to be indexed as the only argument and returns a value suitable
+ for physical storage in a leaf tuple. The optional seventh method
+ <function>options</function> accepts an <type>internal</type> pointer to a C struct, where
+ opclass-specific parameters should be placed, and returns <type>void</type>.
+ </para>
+
+ <para>
+ The five mandatory user-defined methods are:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><function>config</function></term>
+ <listitem>
+ <para>
+ Returns static information about the index implementation, including
+ the data type OIDs of the prefix and node label data types.
+ </para>
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+<programlisting>
+CREATE FUNCTION my_config(internal, internal) RETURNS void ...
+</programlisting>
+ The first argument is a pointer to a <structname>spgConfigIn</structname>
+ C struct, containing input data for the function.
+ The second argument is a pointer to a <structname>spgConfigOut</structname>
+ C struct, which the function must fill with result data.
+<programlisting>
+typedef struct spgConfigIn
+{
+ Oid attType; /* Data type to be indexed */
+} spgConfigIn;
+
+typedef struct spgConfigOut
+{
+ Oid prefixType; /* Data type of inner-tuple prefixes */
+ Oid labelType; /* Data type of inner-tuple node labels */
+ Oid leafType; /* Data type of leaf-tuple values */
+ bool canReturnData; /* Opclass can reconstruct original data */
+ bool longValuesOK; /* Opclass can cope with values > 1 page */
+} spgConfigOut;
+</programlisting>
+
+ <structfield>attType</structfield> is passed in order to support polymorphic
+ index operator classes; for ordinary fixed-data-type operator classes, it
+ will always have the same value and so can be ignored.
+ </para>
+
+ <para>
+ For operator classes that do not use prefixes,
+ <structfield>prefixType</structfield> can be set to <literal>VOIDOID</literal>.
+ Likewise, for operator classes that do not use node labels,
+ <structfield>labelType</structfield> can be set to <literal>VOIDOID</literal>.
+ <structfield>canReturnData</structfield> should be set true if the operator class
+ is capable of reconstructing the originally-supplied index value.
+ <structfield>longValuesOK</structfield> should be set true only when the
+ <structfield>attType</structfield> is of variable length and the operator
+ class is capable of segmenting long values by repeated suffixing
+ (see <xref linkend="spgist-limits"/>).
+ </para>
+
+ <para>
+ <structfield>leafType</structfield> should match the index storage type
+ defined by the operator class's <structfield>opckeytype</structfield>
+ catalog entry.
+ (Note that <structfield>opckeytype</structfield> can be zero,
+ implying the storage type is the same as the operator class's input
+ type, which is the most common situation.)
+ For reasons of backward compatibility, the <function>config</function>
+ method can set <structfield>leafType</structfield> to some other value,
+ and that value will be used; but this is deprecated since the index
+ contents are then incorrectly identified in the catalogs.
+ Also, it's permissible to
+ leave <structfield>leafType</structfield> uninitialized (zero);
+ that is interpreted as meaning the index storage type derived from
+ <structfield>opckeytype</structfield>.
+ </para>
+
+ <para>
+ When <structfield>attType</structfield>
+ and <structfield>leafType</structfield> are different, the optional
+ method <function>compress</function> must be provided.
+ Method <function>compress</function> is responsible
+ for transformation of datums to be indexed from <structfield>attType</structfield>
+ to <structfield>leafType</structfield>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>choose</function></term>
+ <listitem>
+ <para>
+ Chooses a method for inserting a new value into an inner tuple.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+<programlisting>
+CREATE FUNCTION my_choose(internal, internal) RETURNS void ...
+</programlisting>
+ The first argument is a pointer to a <structname>spgChooseIn</structname>
+ C struct, containing input data for the function.
+ The second argument is a pointer to a <structname>spgChooseOut</structname>
+ C struct, which the function must fill with result data.
+<programlisting>
+typedef struct spgChooseIn
+{
+ Datum datum; /* original datum to be indexed */
+ Datum leafDatum; /* current datum to be stored at leaf */
+ int level; /* current level (counting from zero) */
+
+ /* Data from current inner tuple */
+ bool allTheSame; /* tuple is marked all-the-same? */
+ bool hasPrefix; /* tuple has a prefix? */
+ Datum prefixDatum; /* if so, the prefix value */
+ int nNodes; /* number of nodes in the inner tuple */
+ Datum *nodeLabels; /* node label values (NULL if none) */
+} spgChooseIn;
+
+typedef enum spgChooseResultType
+{
+ spgMatchNode = 1, /* descend into existing node */
+ spgAddNode, /* add a node to the inner tuple */
+ spgSplitTuple /* split inner tuple (change its prefix) */
+} spgChooseResultType;
+
+typedef struct spgChooseOut
+{
+ spgChooseResultType resultType; /* action code, see above */
+ union
+ {
+ struct /* results for spgMatchNode */
+ {
+ int nodeN; /* descend to this node (index from 0) */
+ int levelAdd; /* increment level by this much */
+ Datum restDatum; /* new leaf datum */
+ } matchNode;
+ struct /* results for spgAddNode */
+ {
+ Datum nodeLabel; /* new node's label */
+ int nodeN; /* where to insert it (index from 0) */
+ } addNode;
+ struct /* results for spgSplitTuple */
+ {
+ /* Info to form new upper-level inner tuple with one child tuple */
+ bool prefixHasPrefix; /* tuple should have a prefix? */
+ Datum prefixPrefixDatum; /* if so, its value */
+ int prefixNNodes; /* number of nodes */
+ Datum *prefixNodeLabels; /* their labels (or NULL for
+ * no labels) */
+ int childNodeN; /* which node gets child tuple */
+
+ /* Info to form new lower-level inner tuple with all old nodes */
+ bool postfixHasPrefix; /* tuple should have a prefix? */
+ Datum postfixPrefixDatum; /* if so, its value */
+ } splitTuple;
+ } result;
+} spgChooseOut;
+</programlisting>
+
+ <structfield>datum</structfield> is the original datum of
+ <structname>spgConfigIn</structname>.<structfield>attType</structfield>
+ type that was to be inserted into the index.
+ <structfield>leafDatum</structfield> is a value of
+ <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
+ type, which is initially a result of method
+ <function>compress</function> applied to <structfield>datum</structfield>
+ when method <function>compress</function> is provided, or the same value as
+ <structfield>datum</structfield> otherwise.
+ <structfield>leafDatum</structfield> can change at lower levels of the tree
+ if the <function>choose</function> or <function>picksplit</function>
+ methods change it. When the insertion search reaches a leaf page,
+ the current value of <structfield>leafDatum</structfield> is what will be stored
+ in the newly created leaf tuple.
+ <structfield>level</structfield> is the current inner tuple's level, starting at
+ zero for the root level.
+ <structfield>allTheSame</structfield> is true if the current inner tuple is
+ marked as containing multiple equivalent nodes
+ (see <xref linkend="spgist-all-the-same"/>).
+ <structfield>hasPrefix</structfield> is true if the current inner tuple contains
+ a prefix; if so,
+ <structfield>prefixDatum</structfield> is its value.
+ <structfield>nNodes</structfield> is the number of child nodes contained in the
+ inner tuple, and
+ <structfield>nodeLabels</structfield> is an array of their label values, or
+ NULL if there are no labels.
+ </para>
+
+ <para>
+ The <function>choose</function> function can determine either that
+ the new value matches one of the existing child nodes, or that a new
+ child node must be added, or that the new value is inconsistent with
+ the tuple prefix and so the inner tuple must be split to create a
+ less restrictive prefix.
+ </para>
+
+ <para>
+ If the new value matches one of the existing child nodes,
+ set <structfield>resultType</structfield> to <literal>spgMatchNode</literal>.
+ Set <structfield>nodeN</structfield> to the index (from zero) of that node in
+ the node array.
+ Set <structfield>levelAdd</structfield> to the increment in
+ <structfield>level</structfield> caused by descending through that node,
+ or leave it as zero if the operator class does not use levels.
+ Set <structfield>restDatum</structfield> to equal <structfield>leafDatum</structfield>
+ if the operator class does not modify datums from one level to the
+ next, or otherwise set it to the modified value to be used as
+ <structfield>leafDatum</structfield> at the next level.
+ </para>
+
+ <para>
+ If a new child node must be added,
+ set <structfield>resultType</structfield> to <literal>spgAddNode</literal>.
+ Set <structfield>nodeLabel</structfield> to the label to be used for the new
+ node, and set <structfield>nodeN</structfield> to the index (from zero) at which
+ to insert the node in the node array.
+ After the node has been added, the <function>choose</function>
+ function will be called again with the modified inner tuple;
+ that call should result in an <literal>spgMatchNode</literal> result.
+ </para>
+
+ <para>
+ If the new value is inconsistent with the tuple prefix,
+ set <structfield>resultType</structfield> to <literal>spgSplitTuple</literal>.
+ This action moves all the existing nodes into a new lower-level
+ inner tuple, and replaces the existing inner tuple with a tuple
+ having a single downlink pointing to the new lower-level inner tuple.
+ Set <structfield>prefixHasPrefix</structfield> to indicate whether the new
+ upper tuple should have a prefix, and if so set
+ <structfield>prefixPrefixDatum</structfield> to the prefix value. This new
+ prefix value must be sufficiently less restrictive than the original
+ to accept the new value to be indexed.
+ Set <structfield>prefixNNodes</structfield> to the number of nodes needed in the
+ new tuple, and set <structfield>prefixNodeLabels</structfield> to a palloc'd array
+ holding their labels, or to NULL if node labels are not required.
+ Note that the total size of the new upper tuple must be no more
+ than the total size of the tuple it is replacing; this constrains
+ the lengths of the new prefix and new labels.
+ Set <structfield>childNodeN</structfield> to the index (from zero) of the node
+ that will downlink to the new lower-level inner tuple.
+ Set <structfield>postfixHasPrefix</structfield> to indicate whether the new
+ lower-level inner tuple should have a prefix, and if so set
+ <structfield>postfixPrefixDatum</structfield> to the prefix value. The
+ combination of these two prefixes and the downlink node's label
+ (if any) must have the same meaning as the original prefix, because
+ there is no opportunity to alter the node labels that are moved to
+ the new lower-level tuple, nor to change any child index entries.
+ After the node has been split, the <function>choose</function>
+ function will be called again with the replacement inner tuple.
+ That call may return an <literal>spgAddNode</literal> result, if no suitable
+ node was created by the <literal>spgSplitTuple</literal> action. Eventually
+ <function>choose</function> must return <literal>spgMatchNode</literal> to
+ allow the insertion to descend to the next level.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>picksplit</function></term>
+ <listitem>
+ <para>
+ Decides how to create a new inner tuple over a set of leaf tuples.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+<programlisting>
+CREATE FUNCTION my_picksplit(internal, internal) RETURNS void ...
+</programlisting>
+ The first argument is a pointer to a <structname>spgPickSplitIn</structname>
+ C struct, containing input data for the function.
+ The second argument is a pointer to a <structname>spgPickSplitOut</structname>
+ C struct, which the function must fill with result data.
+<programlisting>
+typedef struct spgPickSplitIn
+{
+ int nTuples; /* number of leaf tuples */
+ Datum *datums; /* their datums (array of length nTuples) */
+ int level; /* current level (counting from zero) */
+} spgPickSplitIn;
+
+typedef struct spgPickSplitOut
+{
+ bool hasPrefix; /* new inner tuple should have a prefix? */
+ Datum prefixDatum; /* if so, its value */
+
+ int nNodes; /* number of nodes for new inner tuple */
+ Datum *nodeLabels; /* their labels (or NULL for no labels) */
+
+ int *mapTuplesToNodes; /* node index for each leaf tuple */
+ Datum *leafTupleDatums; /* datum to store in each new leaf tuple */
+} spgPickSplitOut;
+</programlisting>
+
+ <structfield>nTuples</structfield> is the number of leaf tuples provided.
+ <structfield>datums</structfield> is an array of their datum values of
+ <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
+ type.
+ <structfield>level</structfield> is the current level that all the leaf tuples
+ share, which will become the level of the new inner tuple.
+ </para>
+
+ <para>
+ Set <structfield>hasPrefix</structfield> to indicate whether the new inner
+ tuple should have a prefix, and if so set
+ <structfield>prefixDatum</structfield> to the prefix value.
+ Set <structfield>nNodes</structfield> to indicate the number of nodes that
+ the new inner tuple will contain, and
+ set <structfield>nodeLabels</structfield> to an array of their label values,
+ or to NULL if node labels are not required.
+ Set <structfield>mapTuplesToNodes</structfield> to an array that gives the index
+ (from zero) of the node that each leaf tuple should be assigned to.
+ Set <structfield>leafTupleDatums</structfield> to an array of the values to
+ be stored in the new leaf tuples (these will be the same as the
+ input <structfield>datums</structfield> if the operator class does not modify
+ datums from one level to the next).
+ Note that the <function>picksplit</function> function is
+ responsible for palloc'ing the
+ <structfield>nodeLabels</structfield>, <structfield>mapTuplesToNodes</structfield> and
+ <structfield>leafTupleDatums</structfield> arrays.
+ </para>
+
+ <para>
+ If more than one leaf tuple is supplied, it is expected that the
+ <function>picksplit</function> function will classify them into more than
+ one node; otherwise it is not possible to split the leaf tuples
+ across multiple pages, which is the ultimate purpose of this
+ operation. Therefore, if the <function>picksplit</function> function
+ ends up placing all the leaf tuples in the same node, the core
+ SP-GiST code will override that decision and generate an inner
+ tuple in which the leaf tuples are assigned at random to several
+ identically-labeled nodes. Such a tuple is marked
+ <literal>allTheSame</literal> to signify that this has happened. The
+ <function>choose</function> and <function>inner_consistent</function> functions
+ must take suitable care with such inner tuples.
+ See <xref linkend="spgist-all-the-same"/> for more information.
+ </para>
+
+ <para>
+ <function>picksplit</function> can be applied to a single leaf tuple only
+ in the case that the <function>config</function> function set
+ <structfield>longValuesOK</structfield> to true and a larger-than-a-page input
+ value has been supplied. In this case the point of the operation is
+ to strip off a prefix and produce a new, shorter leaf datum value.
+ The call will be repeated until a leaf datum short enough to fit on
+ a page has been produced. See <xref linkend="spgist-limits"/> for
+ more information.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>inner_consistent</function></term>
+ <listitem>
+ <para>
+ Returns set of nodes (branches) to follow during tree search.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+<programlisting>
+CREATE FUNCTION my_inner_consistent(internal, internal) RETURNS void ...
+</programlisting>
+ The first argument is a pointer to a <structname>spgInnerConsistentIn</structname>
+ C struct, containing input data for the function.
+ The second argument is a pointer to a <structname>spgInnerConsistentOut</structname>
+ C struct, which the function must fill with result data.
+
+<programlisting>
+typedef struct spgInnerConsistentIn
+{
+ ScanKey scankeys; /* array of operators and comparison values */
+ ScanKey orderbys; /* array of ordering operators and comparison
+ * values */
+ int nkeys; /* length of scankeys array */
+ int norderbys; /* length of orderbys array */
+
+ Datum reconstructedValue; /* value reconstructed at parent */
+ void *traversalValue; /* opclass-specific traverse value */
+ MemoryContext traversalMemoryContext; /* put new traverse values here */
+ int level; /* current level (counting from zero) */
+ bool returnData; /* original data must be returned? */
+
+ /* Data from current inner tuple */
+ bool allTheSame; /* tuple is marked all-the-same? */
+ bool hasPrefix; /* tuple has a prefix? */
+ Datum prefixDatum; /* if so, the prefix value */
+ int nNodes; /* number of nodes in the inner tuple */
+ Datum *nodeLabels; /* node label values (NULL if none) */
+} spgInnerConsistentIn;
+
+typedef struct spgInnerConsistentOut
+{
+ int nNodes; /* number of child nodes to be visited */
+ int *nodeNumbers; /* their indexes in the node array */
+ int *levelAdds; /* increment level by this much for each */
+ Datum *reconstructedValues; /* associated reconstructed values */
+ void **traversalValues; /* opclass-specific traverse values */
+ double **distances; /* associated distances */
+} spgInnerConsistentOut;
+</programlisting>
+
+ The array <structfield>scankeys</structfield>, of length <structfield>nkeys</structfield>,
+ describes the index search condition(s). These conditions are
+ combined with AND — only index entries that satisfy all of
+ them are interesting. (Note that <structfield>nkeys</structfield> = 0 implies
+ that all index entries satisfy the query.) Usually the consistent
+ function only cares about the <structfield>sk_strategy</structfield> and
+ <structfield>sk_argument</structfield> fields of each array entry, which
+ respectively give the indexable operator and comparison value.
+ In particular it is not necessary to check <structfield>sk_flags</structfield> to
+ see if the comparison value is NULL, because the SP-GiST core code
+ will filter out such conditions.
+ The array <structfield>orderbys</structfield>, of length <structfield>norderbys</structfield>,
+ describes ordering operators (if any) in the same manner.
+ <structfield>reconstructedValue</structfield> is the value reconstructed for the
+ parent tuple; it is <literal>(Datum) 0</literal> at the root level or if the
+ <function>inner_consistent</function> function did not provide a value at the
+ parent level.
+ <structfield>traversalValue</structfield> is a pointer to any traverse data
+ passed down from the previous call of <function>inner_consistent</function>
+ on the parent index tuple, or NULL at the root level.
+ <structfield>traversalMemoryContext</structfield> is the memory context in which
+ to store output traverse values (see below).
+ <structfield>level</structfield> is the current inner tuple's level, starting at
+ zero for the root level.
+ <structfield>returnData</structfield> is <literal>true</literal> if reconstructed data is
+ required for this query; this will only be so if the
+ <function>config</function> function asserted <structfield>canReturnData</structfield>.
+ <structfield>allTheSame</structfield> is true if the current inner tuple is
+ marked <quote>all-the-same</quote>; in this case all the nodes have the
+ same label (if any) and so either all or none of them match the query
+ (see <xref linkend="spgist-all-the-same"/>).
+ <structfield>hasPrefix</structfield> is true if the current inner tuple contains
+ a prefix; if so,
+ <structfield>prefixDatum</structfield> is its value.
+ <structfield>nNodes</structfield> is the number of child nodes contained in the
+ inner tuple, and
+ <structfield>nodeLabels</structfield> is an array of their label values, or
+ NULL if the nodes do not have labels.
+ </para>
+
+ <para>
+ <structfield>nNodes</structfield> must be set to the number of child nodes that
+ need to be visited by the search, and
+ <structfield>nodeNumbers</structfield> must be set to an array of their indexes.
+ If the operator class keeps track of levels, set
+ <structfield>levelAdds</structfield> to an array of the level increments
+ required when descending to each node to be visited. (Often these
+ increments will be the same for all the nodes, but that's not
+ necessarily so, so an array is used.)
+ If value reconstruction is needed, set
+ <structfield>reconstructedValues</structfield> to an array of the values
+ reconstructed for each child node to be visited; otherwise, leave
+ <structfield>reconstructedValues</structfield> as NULL.
+ The reconstructed values are assumed to be of type
+ <structname>spgConfigOut</structname>.<structfield>leafType</structfield>.
+ (However, since the core system will do nothing with them except
+ possibly copy them, it is sufficient for them to have the
+ same <literal>typlen</literal> and <literal>typbyval</literal>
+ properties as <structfield>leafType</structfield>.)
+ If ordered search is performed, set <structfield>distances</structfield>
+ to an array of distance values according to <structfield>orderbys</structfield>
+ array (nodes with lowest distances will be processed first). Leave it
+ NULL otherwise.
+ If it is desired to pass down additional out-of-band information
+ (<quote>traverse values</quote>) to lower levels of the tree search,
+ set <structfield>traversalValues</structfield> to an array of the appropriate
+ traverse values, one for each child node to be visited; otherwise,
+ leave <structfield>traversalValues</structfield> as NULL.
+ Note that the <function>inner_consistent</function> function is
+ responsible for palloc'ing the
+ <structfield>nodeNumbers</structfield>, <structfield>levelAdds</structfield>,
+ <structfield>distances</structfield>,
+ <structfield>reconstructedValues</structfield>, and
+ <structfield>traversalValues</structfield> arrays in the current memory context.
+ However, any output traverse values pointed to by
+ the <structfield>traversalValues</structfield> array should be allocated
+ in <structfield>traversalMemoryContext</structfield>.
+ Each traverse value must be a single palloc'd chunk.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>leaf_consistent</function></term>
+ <listitem>
+ <para>
+ Returns true if a leaf tuple satisfies a query.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+<programlisting>
+CREATE FUNCTION my_leaf_consistent(internal, internal) RETURNS bool ...
+</programlisting>
+ The first argument is a pointer to a <structname>spgLeafConsistentIn</structname>
+ C struct, containing input data for the function.
+ The second argument is a pointer to a <structname>spgLeafConsistentOut</structname>
+ C struct, which the function must fill with result data.
+<programlisting>
+typedef struct spgLeafConsistentIn
+{
+ ScanKey scankeys; /* array of operators and comparison values */
+ ScanKey orderbys; /* array of ordering operators and comparison
+ * values */
+ int nkeys; /* length of scankeys array */
+ int norderbys; /* length of orderbys array */
+
+ Datum reconstructedValue; /* value reconstructed at parent */
+ void *traversalValue; /* opclass-specific traverse value */
+ int level; /* current level (counting from zero) */
+ bool returnData; /* original data must be returned? */
+
+ Datum leafDatum; /* datum in leaf tuple */
+} spgLeafConsistentIn;
+
+typedef struct spgLeafConsistentOut
+{
+ Datum leafValue; /* reconstructed original data, if any */
+ bool recheck; /* set true if operator must be rechecked */
+ bool recheckDistances; /* set true if distances must be rechecked */
+ double *distances; /* associated distances */
+} spgLeafConsistentOut;
+</programlisting>
+
+ The array <structfield>scankeys</structfield>, of length <structfield>nkeys</structfield>,
+ describes the index search condition(s). These conditions are
+ combined with AND — only index entries that satisfy all of
+ them satisfy the query. (Note that <structfield>nkeys</structfield> = 0 implies
+ that all index entries satisfy the query.) Usually the consistent
+ function only cares about the <structfield>sk_strategy</structfield> and
+ <structfield>sk_argument</structfield> fields of each array entry, which
+ respectively give the indexable operator and comparison value.
+ In particular it is not necessary to check <structfield>sk_flags</structfield> to
+ see if the comparison value is NULL, because the SP-GiST core code
+ will filter out such conditions.
+ The array <structfield>orderbys</structfield>, of length <structfield>norderbys</structfield>,
+ describes the ordering operators in the same manner.
+ <structfield>reconstructedValue</structfield> is the value reconstructed for the
+ parent tuple; it is <literal>(Datum) 0</literal> at the root level or if the
+ <function>inner_consistent</function> function did not provide a value at the
+ parent level.
+ <structfield>traversalValue</structfield> is a pointer to any traverse data
+ passed down from the previous call of <function>inner_consistent</function>
+ on the parent index tuple, or NULL at the root level.
+ <structfield>level</structfield> is the current leaf tuple's level, starting at
+ zero for the root level.
+ <structfield>returnData</structfield> is <literal>true</literal> if reconstructed data is
+ required for this query; this will only be so if the
+ <function>config</function> function asserted <structfield>canReturnData</structfield>.
+ <structfield>leafDatum</structfield> is the key value of
+ <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
+ stored in the current leaf tuple.
+ </para>
+
+ <para>
+ The function must return <literal>true</literal> if the leaf tuple matches the
+ query, or <literal>false</literal> if not. In the <literal>true</literal> case,
+ if <structfield>returnData</structfield> is <literal>true</literal> then
+ <structfield>leafValue</structfield> must be set to the value (of type
+ <structname>spgConfigIn</structname>.<structfield>attType</structfield>)
+ originally supplied to be indexed for this leaf tuple. Also,
+ <structfield>recheck</structfield> may be set to <literal>true</literal> if the match
+ is uncertain and so the operator(s) must be re-applied to the actual
+ heap tuple to verify the match.
+ If ordered search is performed, set <structfield>distances</structfield>
+ to an array of distance values according to <structfield>orderbys</structfield>
+ array. Leave it NULL otherwise. If at least one of returned distances
+ is not exact, set <structfield>recheckDistances</structfield> to true.
+ In this case, the executor will calculate the exact distances after
+ fetching the tuple from the heap, and will reorder the tuples if needed.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ The optional user-defined methods are:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><function>Datum compress(Datum in)</function></term>
+ <listitem>
+ <para>
+ Converts a data item into a format suitable for physical storage in
+ a leaf tuple of the index. It accepts a value of type
+ <structname>spgConfigIn</structname>.<structfield>attType</structfield>
+ and returns a value of type
+ <structname>spgConfigOut</structname>.<structfield>leafType</structfield>.
+ The output value must not contain an out-of-line TOAST pointer.
+ </para>
+
+ <para>
+ Note: the <function>compress</function> method is only applied to
+ values to be stored. The consistent methods receive query
+ <structfield>scankeys</structfield> unchanged, without transformation
+ using <function>compress</function>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>options</function></term>
+ <listitem>
+ <para>
+ Defines a set of user-visible parameters that control operator class
+ behavior.
+ </para>
+
+ <para>
+ The <acronym>SQL</acronym> declaration of the function must look like this:
+
+<programlisting>
+CREATE OR REPLACE FUNCTION my_options(internal)
+RETURNS void
+AS 'MODULE_PATHNAME'
+LANGUAGE C STRICT;
+</programlisting>
+ </para>
+
+ <para>
+ The function is passed a pointer to a <structname>local_relopts</structname>
+ struct, which needs to be filled with a set of operator class
+ specific options. The options can be accessed from other support
+ functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
+ <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
+ </para>
+
+ <para>
+ Since the representation of the key in <acronym>SP-GiST</acronym> is
+ flexible, it may depend on user-specified parameters.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ All the SP-GiST support methods are normally called in a short-lived
+ memory context; that is, <varname>CurrentMemoryContext</varname> will be reset
+ after processing of each tuple. It is therefore not very important to
+ worry about pfree'ing everything you palloc. (The <function>config</function>
+ method is an exception: it should try to avoid leaking memory. But
+ usually the <function>config</function> method need do nothing but assign
+ constants into the passed parameter struct.)
+ </para>
+
+ <para>
+ If the indexed column is of a collatable data type, the index collation
+ will be passed to all the support methods, using the standard
+ <function>PG_GET_COLLATION()</function> mechanism.
+ </para>
+
+ </sect2>
+
+ <sect2 id="spgist-implementation">
+ <title>Implementation</title>
+
+ <para>
+ This section covers implementation details and other tricks that are
+ useful for implementers of <acronym>SP-GiST</acronym> operator classes to
+ know.
+ </para>
+
+ <sect3 id="spgist-limits">
+ <title>SP-GiST Limits</title>
+
+ <para>
+ Individual leaf tuples and inner tuples must fit on a single index page
+ (8kB by default). Therefore, when indexing values of variable-length
+ data types, long values can only be supported by methods such as radix
+ trees, in which each level of the tree includes a prefix that is short
+ enough to fit on a page, and the final leaf level includes a suffix also
+ short enough to fit on a page. The operator class should set
+ <structfield>longValuesOK</structfield> to true only if it is prepared to arrange for
+ this to happen. Otherwise, the <acronym>SP-GiST</acronym> core will
+ reject any request to index a value that is too large to fit
+ on an index page.
+ </para>
+
+ <para>
+ Likewise, it is the operator class's responsibility that inner tuples
+ do not grow too large to fit on an index page; this limits the number
+ of child nodes that can be used in one inner tuple, as well as the
+ maximum size of a prefix value.
+ </para>
+
+ <para>
+ Another limitation is that when an inner tuple's node points to a set
+ of leaf tuples, those tuples must all be in the same index page.
+ (This is a design decision to reduce seeking and save space in the
+ links that chain such tuples together.) If the set of leaf tuples
+ grows too large for a page, a split is performed and an intermediate
+ inner tuple is inserted. For this to fix the problem, the new inner
+ tuple <emphasis>must</emphasis> divide the set of leaf values into more than one
+ node group. If the operator class's <function>picksplit</function> function
+ fails to do that, the <acronym>SP-GiST</acronym> core resorts to
+ extraordinary measures described in <xref linkend="spgist-all-the-same"/>.
+ </para>
+
+ <para>
+ When <structfield>longValuesOK</structfield> is true, it is expected
+ that successive levels of the <acronym>SP-GiST</acronym> tree will
+ absorb more and more information into the prefixes and node labels of
+ the inner tuples, making the required leaf datum smaller and smaller,
+ so that eventually it will fit on a page.
+ To prevent bugs in operator classes from causing infinite insertion
+ loops, the <acronym>SP-GiST</acronym> core will raise an error if the
+ leaf datum does not become any smaller within ten cycles
+ of <function>choose</function> method calls.
+ </para>
+ </sect3>
+
+ <sect3 id="spgist-null-labels">
+ <title>SP-GiST Without Node Labels</title>
+
+ <para>
+ Some tree algorithms use a fixed set of nodes for each inner tuple;
+ for example, in a quad-tree there are always exactly four nodes
+ corresponding to the four quadrants around the inner tuple's centroid
+ point. In such a case the code typically works with the nodes by
+ number, and there is no need for explicit node labels. To suppress
+ node labels (and thereby save some space), the <function>picksplit</function>
+ function can return NULL for the <structfield>nodeLabels</structfield> array,
+ and likewise the <function>choose</function> function can return NULL for
+ the <structfield>prefixNodeLabels</structfield> array during
+ a <literal>spgSplitTuple</literal> action.
+ This will in turn result in <structfield>nodeLabels</structfield> being NULL during
+ subsequent calls to <function>choose</function> and <function>inner_consistent</function>.
+ In principle, node labels could be used for some inner tuples and omitted
+ for others in the same index.
+ </para>
+
+ <para>
+ When working with an inner tuple having unlabeled nodes, it is an error
+ for <function>choose</function> to return <literal>spgAddNode</literal>, since the set
+ of nodes is supposed to be fixed in such cases.
+ </para>
+ </sect3>
+
+ <sect3 id="spgist-all-the-same">
+ <title><quote>All-the-Same</quote> Inner Tuples</title>
+
+ <para>
+ The <acronym>SP-GiST</acronym> core can override the results of the
+ operator class's <function>picksplit</function> function when
+ <function>picksplit</function> fails to divide the supplied leaf values into
+ at least two node categories. When this happens, the new inner tuple
+ is created with multiple nodes that each have the same label (if any)
+ that <function>picksplit</function> gave to the one node it did use, and the
+ leaf values are divided at random among these equivalent nodes.
+ The <literal>allTheSame</literal> flag is set on the inner tuple to warn the
+ <function>choose</function> and <function>inner_consistent</function> functions that the
+ tuple does not have the node set that they might otherwise expect.
+ </para>
+
+ <para>
+ When dealing with an <literal>allTheSame</literal> tuple, a <function>choose</function>
+ result of <literal>spgMatchNode</literal> is interpreted to mean that the new
+ value can be assigned to any of the equivalent nodes; the core code will
+ ignore the supplied <structfield>nodeN</structfield> value and descend into one
+ of the nodes at random (so as to keep the tree balanced). It is an
+ error for <function>choose</function> to return <literal>spgAddNode</literal>, since
+ that would make the nodes not all equivalent; the
+ <literal>spgSplitTuple</literal> action must be used if the value to be inserted
+ doesn't match the existing nodes.
+ </para>
+
+ <para>
+ When dealing with an <literal>allTheSame</literal> tuple, the
+ <function>inner_consistent</function> function should return either all or none
+ of the nodes as targets for continuing the index search, since they are
+ all equivalent. This may or may not require any special-case code,
+ depending on how much the <function>inner_consistent</function> function normally
+ assumes about the meaning of the nodes.
+ </para>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="spgist-examples">
+ <title>Examples</title>
+
+ <para>
+ The <productname>PostgreSQL</productname> source distribution includes
+ several examples of index operator classes for <acronym>SP-GiST</acronym>,
+ as described in <xref linkend="spgist-builtin-opclasses-table"/>. Look
+ into <filename>src/backend/access/spgist/</filename>
+ and <filename>src/backend/utils/adt/</filename> to see the code.
+ </para>
+
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="gin">
+ <title>GIN Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>GIN</secondary>
+ </indexterm>
+
+ <sect2 id="gin-intro">
+ <title>Introduction</title>
+
+ <para>
+ <acronym>GIN</acronym> stands for Generalized Inverted Index.
+ <acronym>GIN</acronym> is designed for handling cases where the items
+ to be indexed are composite values, and the queries to be handled by
+ the index need to search for element values that appear within
+ the composite items. For example, the items could be documents,
+ and the queries could be searches for documents containing specific words.
+ </para>
+
+ <para>
+ We use the word <firstterm>item</firstterm> to refer to a composite value that
+ is to be indexed, and the word <firstterm>key</firstterm> to refer to an element
+ value. <acronym>GIN</acronym> always stores and searches for keys,
+ not item values per se.
+ </para>
+
+ <para>
+ A <acronym>GIN</acronym> index stores a set of (key, posting list) pairs,
+ where a <firstterm>posting list</firstterm> is a set of row IDs in which the key
+ occurs. The same row ID can appear in multiple posting lists, since
+ an item can contain more than one key. Each key value is stored only
+ once, so a <acronym>GIN</acronym> index is very compact for cases
+ where the same key appears many times.
+ </para>
+
+ <para>
+ <acronym>GIN</acronym> is generalized in the sense that the
+ <acronym>GIN</acronym> access method code does not need to know the
+ specific operations that it accelerates.
+ Instead, it uses custom strategies defined for particular data types.
+ The strategy defines how keys are extracted from indexed items and
+ query conditions, and how to determine whether a row that contains
+ some of the key values in a query actually satisfies the query.
+ </para>
+
+ <para>
+ One advantage of <acronym>GIN</acronym> is that it allows the development
+ of custom data types with the appropriate access methods, by
+ an expert in the domain of the data type, rather than a database expert.
+ This is much the same advantage as using <acronym>GiST</acronym>.
+ </para>
+
+ <para>
+ The <acronym>GIN</acronym>
+ implementation in <productname>PostgreSQL</productname> is primarily
+ maintained by Teodor Sigaev and Oleg Bartunov. There is more
+ information about <acronym>GIN</acronym> on their
+ <ulink url="http://www.sai.msu.su/~megera/wiki/Gin">website</ulink>.
+ </para>
+ </sect2>
+
+ <sect2 id="gin-builtin-opclasses">
+ <title>Built-in Operator Classes</title>
+
+ <para>
+ The core <productname>PostgreSQL</productname> distribution
+ includes the <acronym>GIN</acronym> operator classes shown in
+ <xref linkend="gin-builtin-opclasses-table"/>.
+ (Some of the optional modules described in <xref linkend="contrib"/>
+ provide additional <acronym>GIN</acronym> operator classes.)
+ </para>
+
+ <table id="gin-builtin-opclasses-table">
+ <title>Built-in <acronym>GIN</acronym> Operator Classes</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Indexable Operators</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry morerows="3" valign="middle"><literal>array_ops</literal></entry>
+ <entry><literal>&& (anyarray,anyarray)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>@> (anyarray,anyarray)</literal></entry>
+ </row>
+ <row>
+ <entry><literal><@ (anyarray,anyarray)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>= (anyarray,anyarray)</literal></entry>
+ </row>
+ <row>
+ <entry morerows="5" valign="middle"><literal>jsonb_ops</literal></entry>
+ <entry><literal>@> (jsonb,jsonb)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>@? (jsonb,jsonpath)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>@@ (jsonb,jsonpath)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>? (jsonb,text)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>?| (jsonb,text[])</literal></entry>
+ </row>
+ <row>
+ <entry><literal>?& (jsonb,text[])</literal></entry>
+ </row>
+ <row>
+ <entry morerows="2" valign="middle"><literal>jsonb_path_ops</literal></entry>
+ <entry><literal>@> (jsonb,jsonb)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>@? (jsonb,jsonpath)</literal></entry>
+ </row>
+ <row>
+ <entry><literal>@@ (jsonb,jsonpath)</literal></entry>
+ </row>
+ <row>
+ <entry valign="middle"><literal>tsvector_ops</literal></entry>
+ <entry><literal>@@ (tsvector,tsquery)</literal></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Of the two operator classes for type <type>jsonb</type>, <literal>jsonb_ops</literal>
+ is the default. <literal>jsonb_path_ops</literal> supports fewer operators but
+ offers better performance for those operators.
+ See <xref linkend="json-indexing"/> for details.
+ </para>
+
+ </sect2>
+
+ <sect2 id="gin-extensibility">
+ <title>Extensibility</title>
+
+ <para>
+ The <acronym>GIN</acronym> interface has a high level of abstraction,
+ requiring the access method implementer only to implement the semantics of
+ the data type being accessed. The <acronym>GIN</acronym> layer itself
+ takes care of concurrency, logging and searching the tree structure.
+ </para>
+
+ <para>
+ All it takes to get a <acronym>GIN</acronym> access method working is to
+ implement a few user-defined methods, which define the behavior of
+ keys in the tree and the relationships between keys, indexed items,
+ and indexable queries. In short, <acronym>GIN</acronym> combines
+ extensibility with generality, code reuse, and a clean interface.
+ </para>
+
+ <para>
+ There are two methods that an operator class for
+ <acronym>GIN</acronym> must provide:
+
+ <variablelist>
+ <varlistentry>
+ <term><function>Datum *extractValue(Datum itemValue, int32 *nkeys,
+ bool **nullFlags)</function></term>
+ <listitem>
+ <para>
+ Returns a palloc'd array of keys given an item to be indexed. The
+ number of returned keys must be stored into <literal>*nkeys</literal>.
+ If any of the keys can be null, also palloc an array of
+ <literal>*nkeys</literal> <type>bool</type> fields, store its address at
+ <literal>*nullFlags</literal>, and set these null flags as needed.
+ <literal>*nullFlags</literal> can be left <symbol>NULL</symbol> (its initial value)
+ if all keys are non-null.
+ The return value can be <symbol>NULL</symbol> if the item contains no keys.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>Datum *extractQuery(Datum query, int32 *nkeys,
+ StrategyNumber n, bool **pmatch, Pointer **extra_data,
+ bool **nullFlags, int32 *searchMode)</function></term>
+ <listitem>
+ <para>
+ Returns a palloc'd array of keys given a value to be queried; that is,
+ <literal>query</literal> is the value on the right-hand side of an
+ indexable operator whose left-hand side is the indexed column.
+ <literal>n</literal> is the strategy number of the operator within the
+ operator class (see <xref linkend="xindex-strategies"/>).
+ Often, <function>extractQuery</function> will need
+ to consult <literal>n</literal> to determine the data type of
+ <literal>query</literal> and the method it should use to extract key values.
+ The number of returned keys must be stored into <literal>*nkeys</literal>.
+ If any of the keys can be null, also palloc an array of
+ <literal>*nkeys</literal> <type>bool</type> fields, store its address at
+ <literal>*nullFlags</literal>, and set these null flags as needed.
+ <literal>*nullFlags</literal> can be left <symbol>NULL</symbol> (its initial value)
+ if all keys are non-null.
+ The return value can be <symbol>NULL</symbol> if the <literal>query</literal> contains no keys.
+ </para>
+
+ <para>
+ <literal>searchMode</literal> is an output argument that allows
+ <function>extractQuery</function> to specify details about how the search
+ will be done.
+ If <literal>*searchMode</literal> is set to
+ <literal>GIN_SEARCH_MODE_DEFAULT</literal> (which is the value it is
+ initialized to before call), only items that match at least one of
+ the returned keys are considered candidate matches.
+ If <literal>*searchMode</literal> is set to
+ <literal>GIN_SEARCH_MODE_INCLUDE_EMPTY</literal>, then in addition to items
+ containing at least one matching key, items that contain no keys at
+ all are considered candidate matches. (This mode is useful for
+ implementing is-subset-of operators, for example.)
+ If <literal>*searchMode</literal> is set to <literal>GIN_SEARCH_MODE_ALL</literal>,
+ then all non-null items in the index are considered candidate
+ matches, whether they match any of the returned keys or not. (This
+ mode is much slower than the other two choices, since it requires
+ scanning essentially the entire index, but it may be necessary to
+ implement corner cases correctly. An operator that needs this mode
+ in most cases is probably not a good candidate for a GIN operator
+ class.)
+ The symbols to use for setting this mode are defined in
+ <filename>access/gin.h</filename>.
+ </para>
+
+ <para>
+ <literal>pmatch</literal> is an output argument for use when partial match
+ is supported. To use it, <function>extractQuery</function> must allocate
+ an array of <literal>*nkeys</literal> <type>bool</type>s and store its address at
+ <literal>*pmatch</literal>. Each element of the array should be set to true
+ if the corresponding key requires partial match, false if not.
+ If <literal>*pmatch</literal> is set to <symbol>NULL</symbol> then GIN assumes partial match
+ is not required. The variable is initialized to <symbol>NULL</symbol> before call,
+ so this argument can simply be ignored by operator classes that do
+ not support partial match.
+ </para>
+
+ <para>
+ <literal>extra_data</literal> is an output argument that allows
+ <function>extractQuery</function> to pass additional data to the
+ <function>consistent</function> and <function>comparePartial</function> methods.
+ To use it, <function>extractQuery</function> must allocate
+ an array of <literal>*nkeys</literal> pointers and store its address at
+ <literal>*extra_data</literal>, then store whatever it wants to into the
+ individual pointers. The variable is initialized to <symbol>NULL</symbol> before
+ call, so this argument can simply be ignored by operator classes that
+ do not require extra data. If <literal>*extra_data</literal> is set, the
+ whole array is passed to the <function>consistent</function> method, and
+ the appropriate element to the <function>comparePartial</function> method.
+ </para>
+
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ An operator class must also provide a function to check if an indexed item
+ matches the query. It comes in two flavors, a Boolean <function>consistent</function>
+ function, and a ternary <function>triConsistent</function> function.
+ <function>triConsistent</function> covers the functionality of both, so providing
+ <function>triConsistent</function> alone is sufficient. However, if the Boolean
+ variant is significantly cheaper to calculate, it can be advantageous to
+ provide both. If only the Boolean variant is provided, some optimizations
+ that depend on refuting index items before fetching all the keys are
+ disabled.
+
+ <variablelist>
+ <varlistentry>
+ <term><function>bool consistent(bool check[], StrategyNumber n, Datum query,
+ int32 nkeys, Pointer extra_data[], bool *recheck,
+ Datum queryKeys[], bool nullFlags[])</function></term>
+ <listitem>
+ <para>
+ Returns true if an indexed item satisfies the query operator with
+ strategy number <literal>n</literal> (or might satisfy it, if the recheck
+ indication is returned). This function does not have direct access
+ to the indexed item's value, since <acronym>GIN</acronym> does not
+ store items explicitly. Rather, what is available is knowledge
+ about which key values extracted from the query appear in a given
+ indexed item. The <literal>check</literal> array has length
+ <literal>nkeys</literal>, which is the same as the number of keys previously
+ returned by <function>extractQuery</function> for this <literal>query</literal> datum.
+ Each element of the
+ <literal>check</literal> array is true if the indexed item contains the
+ corresponding query key, i.e., if (check[i] == true) the i-th key of the
+ <function>extractQuery</function> result array is present in the indexed item.
+ The original <literal>query</literal> datum is
+ passed in case the <function>consistent</function> method needs to consult it,
+ and so are the <literal>queryKeys[]</literal> and <literal>nullFlags[]</literal>
+ arrays previously returned by <function>extractQuery</function>.
+ <literal>extra_data</literal> is the extra-data array returned by
+ <function>extractQuery</function>, or <symbol>NULL</symbol> if none.
+ </para>
+
+ <para>
+ When <function>extractQuery</function> returns a null key in
+ <literal>queryKeys[]</literal>, the corresponding <literal>check[]</literal> element
+ is true if the indexed item contains a null key; that is, the
+ semantics of <literal>check[]</literal> are like <literal>IS NOT DISTINCT
+ FROM</literal>. The <function>consistent</function> function can examine the
+ corresponding <literal>nullFlags[]</literal> element if it needs to tell
+ the difference between a regular value match and a null match.
+ </para>
+
+ <para>
+ On success, <literal>*recheck</literal> should be set to true if the heap
+ tuple needs to be rechecked against the query operator, or false if
+ the index test is exact. That is, a false return value guarantees
+ that the heap tuple does not match the query; a true return value with
+ <literal>*recheck</literal> set to false guarantees that the heap tuple does
+ match the query; and a true return value with
+ <literal>*recheck</literal> set to true means that the heap tuple might match
+ the query, so it needs to be fetched and rechecked by evaluating the
+ query operator directly against the originally indexed item.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>GinTernaryValue triConsistent(GinTernaryValue check[], StrategyNumber n, Datum query,
+ int32 nkeys, Pointer extra_data[],
+ Datum queryKeys[], bool nullFlags[])</function></term>
+ <listitem>
+ <para>
+ <function>triConsistent</function> is similar to <function>consistent</function>,
+ but instead of Booleans in the <literal>check</literal> vector, there are
+ three possible values for each
+ key: <literal>GIN_TRUE</literal>, <literal>GIN_FALSE</literal> and
+ <literal>GIN_MAYBE</literal>. <literal>GIN_FALSE</literal> and <literal>GIN_TRUE</literal>
+ have the same meaning as regular Boolean values, while
+ <literal>GIN_MAYBE</literal> means that the presence of that key is not known.
+ When <literal>GIN_MAYBE</literal> values are present, the function should only
+ return <literal>GIN_TRUE</literal> if the item certainly matches whether or
+ not the index item contains the corresponding query keys. Likewise, the
+ function must return <literal>GIN_FALSE</literal> only if the item certainly
+ does not match, whether or not it contains the <literal>GIN_MAYBE</literal>
+ keys. If the result depends on the <literal>GIN_MAYBE</literal> entries, i.e.,
+ the match cannot be confirmed or refuted based on the known query keys,
+ the function must return <literal>GIN_MAYBE</literal>.
+ </para>
+ <para>
+ When there are no <literal>GIN_MAYBE</literal> values in the <literal>check</literal>
+ vector, a <literal>GIN_MAYBE</literal> return value is the equivalent of
+ setting the <literal>recheck</literal> flag in the
+ Boolean <function>consistent</function> function.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ In addition, GIN must have a way to sort the key values stored in the index.
+ The operator class can define the sort ordering by specifying a comparison
+ method:
+
+ <variablelist>
+ <varlistentry>
+ <term><function>int compare(Datum a, Datum b)</function></term>
+ <listitem>
+ <para>
+ Compares two keys (not indexed items!) and returns an integer less than
+ zero, zero, or greater than zero, indicating whether the first key is
+ less than, equal to, or greater than the second. Null keys are never
+ passed to this function.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ Alternatively, if the operator class does not provide a <function>compare</function>
+ method, GIN will look up the default btree operator class for the index
+ key data type, and use its comparison function. It is recommended to
+ specify the comparison function in a GIN operator class that is meant for
+ just one data type, as looking up the btree operator class costs a few
+ cycles. However, polymorphic GIN operator classes (such
+ as <literal>array_ops</literal>) typically cannot specify a single comparison
+ function.
+ </para>
+
+ <para>
+ An operator class for <acronym>GIN</acronym> can optionally supply the
+ following methods:
+
+ <variablelist>
+ <varlistentry>
+ <term><function>int comparePartial(Datum partial_key, Datum key, StrategyNumber n,
+ Pointer extra_data)</function></term>
+ <listitem>
+ <para>
+ Compare a partial-match query key to an index key. Returns an integer
+ whose sign indicates the result: less than zero means the index key
+ does not match the query, but the index scan should continue; zero
+ means that the index key does match the query; greater than zero
+ indicates that the index scan should stop because no more matches
+ are possible. The strategy number <literal>n</literal> of the operator
+ that generated the partial match query is provided, in case its
+ semantics are needed to determine when to end the scan. Also,
+ <literal>extra_data</literal> is the corresponding element of the extra-data
+ array made by <function>extractQuery</function>, or <symbol>NULL</symbol> if none.
+ Null keys are never passed to this function.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><function>void options(local_relopts *relopts)</function></term>
+ <listitem>
+ <para>
+ Defines a set of user-visible parameters that control operator class
+ behavior.
+ </para>
+
+ <para>
+ The <function>options</function> function is passed a pointer to a
+ <structname>local_relopts</structname> struct, which needs to be
+ filled with a set of operator class specific options. The options
+ can be accessed from other support functions using the
+ <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
+ <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
+ </para>
+
+ <para>
+ Since both key extraction of indexed values and representation of the
+ key in <acronym>GIN</acronym> are flexible, they may depend on
+ user-specified parameters.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ To support <quote>partial match</quote> queries, an operator class must
+ provide the <function>comparePartial</function> method, and its
+ <function>extractQuery</function> method must set the <literal>pmatch</literal>
+ parameter when a partial-match query is encountered. See
+ <xref linkend="gin-partial-match"/> for details.
+ </para>
+
+ <para>
+ The actual data types of the various <literal>Datum</literal> values mentioned
+ above vary depending on the operator class. The item values passed to
+ <function>extractValue</function> are always of the operator class's input type, and
+ all key values must be of the class's <literal>STORAGE</literal> type. The type of
+ the <literal>query</literal> argument passed to <function>extractQuery</function>,
+ <function>consistent</function> and <function>triConsistent</function> is whatever is the
+ right-hand input type of the class member operator identified by the
+ strategy number. This need not be the same as the indexed type, so long as
+ key values of the correct type can be extracted from it. However, it is
+ recommended that the SQL declarations of these three support functions use
+ the opclass's indexed data type for the <literal>query</literal> argument, even
+ though the actual type might be something else depending on the operator.
+ </para>
+
+ </sect2>
+
+ <sect2 id="gin-implementation">
+ <title>Implementation</title>
+
+ <para>
+ Internally, a <acronym>GIN</acronym> index contains a B-tree index
+ constructed over keys, where each key is an element of one or more indexed
+ items (a member of an array, for example) and where each tuple in a leaf
+ page contains either a pointer to a B-tree of heap pointers (a
+ <quote>posting tree</quote>), or a simple list of heap pointers (a <quote>posting
+ list</quote>) when the list is small enough to fit into a single index tuple along
+ with the key value. <xref linkend="gin-internals-figure"/> illustrates
+ these components of a GIN index.
+ </para>
+
+ <para>
+ As of <productname>PostgreSQL</productname> 9.1, null key values can be
+ included in the index. Also, placeholder nulls are included in the index
+ for indexed items that are null or contain no keys according to
+ <function>extractValue</function>. This allows searches that should find empty
+ items to do so.
+ </para>
+
+ <para>
+ Multicolumn <acronym>GIN</acronym> indexes are implemented by building
+ a single B-tree over composite values (column number, key value). The
+ key values for different columns can be of different types.
+ </para>
+
+ <figure id="gin-internals-figure">
+ <title>GIN Internals</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/gin.svg" format="SVG" width="100%"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+
+ <sect3 id="gin-fast-update">
+ <title>GIN Fast Update Technique</title>
+
+ <para>
+ Updating a <acronym>GIN</acronym> index tends to be slow because of the
+ intrinsic nature of inverted indexes: inserting or updating one heap row
+ can cause many inserts into the index (one for each key extracted
+ from the indexed item).
+ <acronym>GIN</acronym> is capable of postponing much of this work by inserting
+ new tuples into a temporary, unsorted list of pending entries.
+ When the table is vacuumed or autoanalyzed, or when
+ <function>gin_clean_pending_list</function> function is called, or if the
+ pending list becomes larger than
+ <xref linkend="guc-gin-pending-list-limit"/>, the entries are moved to the
+ main <acronym>GIN</acronym> data structure using the same bulk insert
+ techniques used during initial index creation. This greatly improves
+ <acronym>GIN</acronym> index update speed, even counting the additional
+ vacuum overhead. Moreover the overhead work can be done by a background
+ process instead of in foreground query processing.
+ </para>
+
+ <para>
+ The main disadvantage of this approach is that searches must scan the list
+ of pending entries in addition to searching the regular index, and so
+ a large list of pending entries will slow searches significantly.
+ Another disadvantage is that, while most updates are fast, an update
+ that causes the pending list to become <quote>too large</quote> will incur an
+ immediate cleanup cycle and thus be much slower than other updates.
+ Proper use of autovacuum can minimize both of these problems.
+ </para>
+
+ <para>
+ If consistent response time is more important than update speed,
+ use of pending entries can be disabled by turning off the
+ <literal>fastupdate</literal> storage parameter for a
+ <acronym>GIN</acronym> index. See <xref linkend="sql-createindex"/>
+ for details.
+ </para>
+ </sect3>
+
+ <sect3 id="gin-partial-match">
+ <title>Partial Match Algorithm</title>
+
+ <para>
+ GIN can support <quote>partial match</quote> queries, in which the query
+ does not determine an exact match for one or more keys, but the possible
+ matches fall within a reasonably narrow range of key values (within the
+ key sorting order determined by the <function>compare</function> support method).
+ The <function>extractQuery</function> method, instead of returning a key value
+ to be matched exactly, returns a key value that is the lower bound of
+ the range to be searched, and sets the <literal>pmatch</literal> flag true.
+ The key range is then scanned using the <function>comparePartial</function>
+ method. <function>comparePartial</function> must return zero for a matching
+ index key, less than zero for a non-match that is still within the range
+ to be searched, or greater than zero if the index key is past the range
+ that could match.
+ </para>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="gin-tips">
+ <title>GIN Tips and Tricks</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>Create vs. insert</term>
+ <listitem>
+ <para>
+ Insertion into a <acronym>GIN</acronym> index can be slow
+ due to the likelihood of many keys being inserted for each item.
+ So, for bulk insertions into a table it is advisable to drop the GIN
+ index and recreate it after finishing bulk insertion.
+ </para>
+
+ <para>
+ When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
+ (see <xref linkend="gin-fast-update"/> for details), the penalty is
+ less than when it is not. But for very large updates it may still be
+ best to drop and recreate the index.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="guc-maintenance-work-mem"/></term>
+ <listitem>
+ <para>
+ Build time for a <acronym>GIN</acronym> index is very sensitive to
+ the <varname>maintenance_work_mem</varname> setting; it doesn't pay to
+ skimp on work memory during index creation.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="guc-gin-pending-list-limit"/></term>
+ <listitem>
+ <para>
+ During a series of insertions into an existing <acronym>GIN</acronym>
+ index that has <literal>fastupdate</literal> enabled, the system will clean up
+ the pending-entry list whenever the list grows larger than
+ <varname>gin_pending_list_limit</varname>. To avoid fluctuations in observed
+ response time, it's desirable to have pending-list cleanup occur in the
+ background (i.e., via autovacuum). Foreground cleanup operations
+ can be avoided by increasing <varname>gin_pending_list_limit</varname>
+ or making autovacuum more aggressive.
+ However, enlarging the threshold of the cleanup operation means that
+ if a foreground cleanup does occur, it will take even longer.
+ </para>
+ <para>
+ <varname>gin_pending_list_limit</varname> can be overridden for individual
+ GIN indexes by changing storage parameters, which allows each
+ GIN index to have its own cleanup threshold.
+ For example, it's possible to increase the threshold only for the GIN
+ index which can be updated heavily, and decrease it otherwise.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="guc-gin-fuzzy-search-limit"/></term>
+ <listitem>
+ <para>
+ The primary goal of developing <acronym>GIN</acronym> indexes was
+ to create support for highly scalable full-text search in
+ <productname>PostgreSQL</productname>, and there are often situations when
+ a full-text search returns a very large set of results. Moreover, this
+ often happens when the query contains very frequent words, so that the
+ large result set is not even useful. Since reading many
+ tuples from the disk and sorting them could take a lot of time, this is
+ unacceptable for production. (Note that the index search itself is very
+ fast.)
+ </para>
+ <para>
+ To facilitate controlled execution of such queries,
+ <acronym>GIN</acronym> has a configurable soft upper limit on the
+ number of rows returned: the
+ <varname>gin_fuzzy_search_limit</varname> configuration parameter.
+ It is set to 0 (meaning no limit) by default.
+ If a non-zero limit is set, then the returned set is a subset of
+ the whole result set, chosen at random.
+ </para>
+ <para>
+ <quote>Soft</quote> means that the actual number of returned results
+ could differ somewhat from the specified limit, depending on the query
+ and the quality of the system's random number generator.
+ </para>
+ <para>
+ From experience, values in the thousands (e.g., 5000 — 20000)
+ work well.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ </sect2>
+
+ <sect2 id="gin-limit">
+ <title>Limitations</title>
+
+ <para>
+ <acronym>GIN</acronym> assumes that indexable operators are strict. This
+ means that <function>extractValue</function> will not be called at all on a null
+ item value (instead, a placeholder index entry is created automatically),
+ and <function>extractQuery</function> will not be called on a null query
+ value either (instead, the query is presumed to be unsatisfiable). Note
+ however that null key values contained within a non-null composite item
+ or query value are supported.
+ </para>
+ </sect2>
+
+ <sect2 id="gin-examples">
+ <title>Examples</title>
+
+ <para>
+ The core <productname>PostgreSQL</productname> distribution
+ includes the <acronym>GIN</acronym> operator classes previously shown in
+ <xref linkend="gin-builtin-opclasses-table"/>.
+ The following <filename>contrib</filename> modules also contain
+ <acronym>GIN</acronym> operator classes:
+
+ <variablelist>
+ <varlistentry>
+ <term><filename>btree_gin</filename></term>
+ <listitem>
+ <para>B-tree equivalent functionality for several data types</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>hstore</filename></term>
+ <listitem>
+ <para>Module for storing (key, value) pairs</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>intarray</filename></term>
+ <listitem>
+ <para>Enhanced support for <type>int[]</type></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>pg_trgm</filename></term>
+ <listitem>
+ <para>Text similarity using trigram matching</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="brin">
+ <title>BRIN Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>BRIN</secondary>
+ </indexterm>
+
+ <sect2 id="brin-intro">
+ <title>Introduction</title>
+
+ <para>
+ <acronym>BRIN</acronym> stands for Block Range Index.
+ <acronym>BRIN</acronym> is designed for handling very large tables
+ in which certain columns have some natural correlation with their
+ physical location within the table.
+ </para>
+
+ <para>
+ <acronym>BRIN</acronym> works in terms of <firstterm>block ranges</firstterm>
+ (or <quote>page ranges</quote>).
+ A block range is a group of pages that are physically
+ adjacent in the table; for each block range, some summary info is stored
+ by the index.
+ For example, a table storing a store's sale orders might have
+ a date column on which each order was placed, and most of the time
+ the entries for earlier orders will appear earlier in the table as well;
+ a table storing a ZIP code column might have all codes for a city
+ grouped together naturally.
+ </para>
+
+ <para>
+ <acronym>BRIN</acronym> indexes can satisfy queries via regular bitmap
+ index scans, and will return all tuples in all pages within each range if
+ the summary info stored by the index is <firstterm>consistent</firstterm> with the
+ query conditions.
+ The query executor is in charge of rechecking these tuples and discarding
+ those that do not match the query conditions — in other words, these
+ indexes are lossy.
+ Because a <acronym>BRIN</acronym> index is very small, scanning the index
+ adds little overhead compared to a sequential scan, but may avoid scanning
+ large parts of the table that are known not to contain matching tuples.
+ </para>
+
+ <para>
+ The specific data that a <acronym>BRIN</acronym> index will store,
+ as well as the specific queries that the index will be able to satisfy,
+ depend on the operator class selected for each column of the index.
+ Data types having a linear sort order can have operator classes that
+ store the minimum and maximum value within each block range, for instance;
+ geometrical types might store the bounding box for all the objects
+ in the block range.
+ </para>
+
+ <para>
+ The size of the block range is determined at index creation time by
+ the <literal>pages_per_range</literal> storage parameter. The number of index
+ entries will be equal to the size of the relation in pages divided by
+ the selected value for <literal>pages_per_range</literal>. Therefore, the smaller
+ the number, the larger the index becomes (because of the need to
+ store more index entries), but at the same time the summary data stored can
+ be more precise and more data blocks can be skipped during an index scan.
+ </para>
+
+ <sect3 id="brin-operation">
+ <title>Index Maintenance</title>
+
+ <para>
+ At the time of creation, all existing heap pages are scanned and a
+ summary index tuple is created for each range, including the
+ possibly-incomplete range at the end.
+ As new pages are filled with data, page ranges that are already
+ summarized will cause the summary information to be updated with data
+ from the new tuples.
+ When a new page is created that does not fall within the last
+ summarized range, the range that the new page belongs to
+ does not automatically acquire a summary tuple;
+ those tuples remain unsummarized until a summarization run is
+ invoked later, creating the initial summary for that range.
+ </para>
+
+ <para>
+ There are several ways to trigger the initial summarization of a page range.
+ If the table is vacuumed, either manually or by
+ <link linkend="autovacuum">autovacuum</link>, all existing unsummarized
+ page ranges are summarized.
+ Also, if the index's
+ <xref linkend="index-reloption-autosummarize"/> parameter is enabled,
+ which it isn't by default,
+ whenever autovacuum runs in that database, summarization will occur for all
+ unsummarized page ranges that have been filled,
+ regardless of whether the table itself is processed by autovacuum; see below.
+ </para>
+
+ <para>
+ Lastly, the following functions can be used (while these functions run,
+ <xref linkend="guc-search-path"/> is temporarily changed to
+ <literal>pg_catalog, pg_temp</literal>):
+ <simplelist>
+ <member>
+ <function>brin_summarize_new_values(regclass)</function>
+ which summarizes all unsummarized ranges;
+ </member>
+ <member>
+ <function>brin_summarize_range(regclass, bigint)</function>
+ which summarizes only the range containing the given page,
+ if it is unsummarized.
+ </member>
+ </simplelist>
+ </para>
+
+ <para>
+ When autosummarization is enabled, a request is sent to
+ <literal>autovacuum</literal> to execute a targeted summarization
+ for a block range when an insertion is detected for the first item
+ of the first page of the next block range,
+ to be fulfilled the next time an autovacuum
+ worker finishes running in the
+ same database. If the request queue is full, the request is not recorded
+ and a message is sent to the server log:
+ <screen>
+ LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was not recorded
+ </screen>
+ When this happens, the range will remain unsummarized until the next
+ regular vacuum run on the table, or one of the functions mentioned above
+ are invoked.
+ </para>
+
+ <para>
+ Conversely, a range can be de-summarized using the
+ <function>brin_desummarize_range(regclass, bigint)</function> function,
+ which is useful when the index tuple is no longer a very good
+ representation because the existing values have changed.
+ See <xref linkend="functions-admin-index"/> for details.
+ </para>
+
+ </sect3>
+ </sect2>
+
+ <sect2 id="brin-builtin-opclasses">
+ <title>Built-in Operator Classes</title>
+
+ <para>
+ The core <productname>PostgreSQL</productname> distribution
+ includes the <acronym>BRIN</acronym> operator classes shown in
+ <xref linkend="brin-builtin-opclasses-table"/>.
+ </para>
+
+ <para>
+ The <firstterm>minmax</firstterm>
+ operator classes store the minimum and the maximum values appearing
+ in the indexed column within the range. The <firstterm>inclusion</firstterm>
+ operator classes store a value which includes the values in the indexed
+ column within the range. The <firstterm>bloom</firstterm> operator
+ classes build a Bloom filter for all values in the range. The
+ <firstterm>minmax-multi</firstterm> operator classes store multiple
+ minimum and maximum values, representing values appearing in the indexed
+ column within the range.
+ </para>
+
+ <table id="brin-builtin-opclasses-table">
+ <title>Built-in <acronym>BRIN</acronym> Operator Classes</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Indexable Operators</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry valign="middle" morerows="4"><literal>bit_minmax_ops</literal></entry>
+ <entry><literal>= (bit,bit)</literal></entry>
+ </row>
+ <row><entry><literal>< (bit,bit)</literal></entry></row>
+ <row><entry><literal>> (bit,bit)</literal></entry></row>
+ <row><entry><literal><= (bit,bit)</literal></entry></row>
+ <row><entry><literal>>= (bit,bit)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="12"><literal>box_inclusion_ops</literal></entry>
+ <entry><literal>@> (box,point)</literal></entry>
+ </row>
+ <row><entry><literal><< (box,box)</literal></entry></row>
+ <row><entry><literal>&< (box,box)</literal></entry></row>
+ <row><entry><literal>&> (box,box)</literal></entry></row>
+ <row><entry><literal>>> (box,box)</literal></entry></row>
+ <row><entry><literal><@ (box,box)</literal></entry></row>
+ <row><entry><literal>@> (box,box)</literal></entry></row>
+ <row><entry><literal>~= (box,box)</literal></entry></row>
+ <row><entry><literal>&& (box,box)</literal></entry></row>
+ <row><entry><literal><<| (box,box)</literal></entry></row>
+ <row><entry><literal>&<| (box,box)</literal></entry></row>
+ <row><entry><literal>|&> (box,box)</literal></entry></row>
+ <row><entry><literal>|>> (box,box)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>bpchar_bloom_ops</literal></entry>
+ <entry><literal>= (character,character)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>bpchar_minmax_ops</literal></entry>
+ <entry><literal>= (character,character)</literal></entry>
+ </row>
+ <row><entry><literal>< (character,character)</literal></entry></row>
+ <row><entry><literal><= (character,character)</literal></entry></row>
+ <row><entry><literal>> (character,character)</literal></entry></row>
+ <row><entry><literal>>= (character,character)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>bytea_bloom_ops</literal></entry>
+ <entry><literal>= (bytea,bytea)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>bytea_minmax_ops</literal></entry>
+ <entry><literal>= (bytea,bytea)</literal></entry>
+ </row>
+ <row><entry><literal>< (bytea,bytea)</literal></entry></row>
+ <row><entry><literal><= (bytea,bytea)</literal></entry></row>
+ <row><entry><literal>> (bytea,bytea)</literal></entry></row>
+ <row><entry><literal>>= (bytea,bytea)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>char_bloom_ops</literal></entry>
+ <entry><literal>= ("char","char")</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>char_minmax_ops</literal></entry>
+ <entry><literal>= ("char","char")</literal></entry>
+ </row>
+ <row><entry><literal>< ("char","char")</literal></entry></row>
+ <row><entry><literal><= ("char","char")</literal></entry></row>
+ <row><entry><literal>> ("char","char")</literal></entry></row>
+ <row><entry><literal>>= ("char","char")</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>date_bloom_ops</literal></entry>
+ <entry><literal>= (date,date)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>date_minmax_ops</literal></entry>
+ <entry><literal>= (date,date)</literal></entry>
+ </row>
+ <row><entry><literal>< (date,date)</literal></entry></row>
+ <row><entry><literal><= (date,date)</literal></entry></row>
+ <row><entry><literal>> (date,date)</literal></entry></row>
+ <row><entry><literal>>= (date,date)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>date_minmax_multi_ops</literal></entry>
+ <entry><literal>= (date,date)</literal></entry>
+ </row>
+ <row><entry><literal>< (date,date)</literal></entry></row>
+ <row><entry><literal><= (date,date)</literal></entry></row>
+ <row><entry><literal>> (date,date)</literal></entry></row>
+ <row><entry><literal>>= (date,date)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>float4_bloom_ops</literal></entry>
+ <entry><literal>= (float4,float4)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>float4_minmax_ops</literal></entry>
+ <entry><literal>= (float4,float4)</literal></entry>
+ </row>
+ <row><entry><literal>< (float4,float4)</literal></entry></row>
+ <row><entry><literal>> (float4,float4)</literal></entry></row>
+ <row><entry><literal><= (float4,float4)</literal></entry></row>
+ <row><entry><literal>>= (float4,float4)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>float4_minmax_multi_ops</literal></entry>
+ <entry><literal>= (float4,float4)</literal></entry>
+ </row>
+ <row><entry><literal>< (float4,float4)</literal></entry></row>
+ <row><entry><literal>> (float4,float4)</literal></entry></row>
+ <row><entry><literal><= (float4,float4)</literal></entry></row>
+ <row><entry><literal>>= (float4,float4)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>float8_bloom_ops</literal></entry>
+ <entry><literal>= (float8,float8)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>float8_minmax_ops</literal></entry>
+ <entry><literal>= (float8,float8)</literal></entry>
+ </row>
+ <row><entry><literal>< (float8,float8)</literal></entry></row>
+ <row><entry><literal><= (float8,float8)</literal></entry></row>
+ <row><entry><literal>> (float8,float8)</literal></entry></row>
+ <row><entry><literal>>= (float8,float8)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>float8_minmax_multi_ops</literal></entry>
+ <entry><literal>= (float8,float8)</literal></entry>
+ </row>
+ <row><entry><literal>< (float8,float8)</literal></entry></row>
+ <row><entry><literal><= (float8,float8)</literal></entry></row>
+ <row><entry><literal>> (float8,float8)</literal></entry></row>
+ <row><entry><literal>>= (float8,float8)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="5"><literal>inet_inclusion_ops</literal></entry>
+ <entry><literal><< (inet,inet)</literal></entry>
+ </row>
+ <row><entry><literal><<= (inet,inet)</literal></entry></row>
+ <row><entry><literal>>> (inet,inet)</literal></entry></row>
+ <row><entry><literal>>>= (inet,inet)</literal></entry></row>
+ <row><entry><literal>= (inet,inet)</literal></entry></row>
+ <row><entry><literal>&& (inet,inet)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>inet_bloom_ops</literal></entry>
+ <entry><literal>= (inet,inet)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>inet_minmax_ops</literal></entry>
+ <entry><literal>= (inet,inet)</literal></entry>
+ </row>
+ <row><entry><literal>< (inet,inet)</literal></entry></row>
+ <row><entry><literal><= (inet,inet)</literal></entry></row>
+ <row><entry><literal>> (inet,inet)</literal></entry></row>
+ <row><entry><literal>>= (inet,inet)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>inet_minmax_multi_ops</literal></entry>
+ <entry><literal>= (inet,inet)</literal></entry>
+ </row>
+ <row><entry><literal>< (inet,inet)</literal></entry></row>
+ <row><entry><literal><= (inet,inet)</literal></entry></row>
+ <row><entry><literal>> (inet,inet)</literal></entry></row>
+ <row><entry><literal>>= (inet,inet)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>int2_bloom_ops</literal></entry>
+ <entry><literal>= (int2,int2)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int2_minmax_ops</literal></entry>
+ <entry><literal>= (int2,int2)</literal></entry>
+ </row>
+ <row><entry><literal>< (int2,int2)</literal></entry></row>
+ <row><entry><literal>> (int2,int2)</literal></entry></row>
+ <row><entry><literal><= (int2,int2)</literal></entry></row>
+ <row><entry><literal>>= (int2,int2)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int2_minmax_multi_ops</literal></entry>
+ <entry><literal>= (int2,int2)</literal></entry>
+ </row>
+ <row><entry><literal>< (int2,int2)</literal></entry></row>
+ <row><entry><literal>> (int2,int2)</literal></entry></row>
+ <row><entry><literal><= (int2,int2)</literal></entry></row>
+ <row><entry><literal>>= (int2,int2)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>int4_bloom_ops</literal></entry>
+ <entry><literal>= (int4,int4)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int4_minmax_ops</literal></entry>
+ <entry><literal>= (int4,int4)</literal></entry>
+ </row>
+ <row><entry><literal>< (int4,int4)</literal></entry></row>
+ <row><entry><literal>> (int4,int4)</literal></entry></row>
+ <row><entry><literal><= (int4,int4)</literal></entry></row>
+ <row><entry><literal>>= (int4,int4)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int4_minmax_multi_ops</literal></entry>
+ <entry><literal>= (int4,int4)</literal></entry>
+ </row>
+ <row><entry><literal>< (int4,int4)</literal></entry></row>
+ <row><entry><literal>> (int4,int4)</literal></entry></row>
+ <row><entry><literal><= (int4,int4)</literal></entry></row>
+ <row><entry><literal>>= (int4,int4)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>int8_bloom_ops</literal></entry>
+ <entry><literal>= (bigint,bigint)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int8_minmax_ops</literal></entry>
+ <entry><literal>= (bigint,bigint)</literal></entry>
+ </row>
+ <row><entry><literal>< (bigint,bigint)</literal></entry></row>
+ <row><entry><literal>> (bigint,bigint)</literal></entry></row>
+ <row><entry><literal><= (bigint,bigint)</literal></entry></row>
+ <row><entry><literal>>= (bigint,bigint)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>int8_minmax_multi_ops</literal></entry>
+ <entry><literal>= (bigint,bigint)</literal></entry>
+ </row>
+ <row><entry><literal>< (bigint,bigint)</literal></entry></row>
+ <row><entry><literal>> (bigint,bigint)</literal></entry></row>
+ <row><entry><literal><= (bigint,bigint)</literal></entry></row>
+ <row><entry><literal>>= (bigint,bigint)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>interval_bloom_ops</literal></entry>
+ <entry><literal>= (interval,interval)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>interval_minmax_ops</literal></entry>
+ <entry><literal>= (interval,interval)</literal></entry>
+ </row>
+ <row><entry><literal>< (interval,interval)</literal></entry></row>
+ <row><entry><literal><= (interval,interval)</literal></entry></row>
+ <row><entry><literal>> (interval,interval)</literal></entry></row>
+ <row><entry><literal>>= (interval,interval)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>interval_minmax_multi_ops</literal></entry>
+ <entry><literal>= (interval,interval)</literal></entry>
+ </row>
+ <row><entry><literal>< (interval,interval)</literal></entry></row>
+ <row><entry><literal><= (interval,interval)</literal></entry></row>
+ <row><entry><literal>> (interval,interval)</literal></entry></row>
+ <row><entry><literal>>= (interval,interval)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>macaddr_bloom_ops</literal></entry>
+ <entry><literal>= (macaddr,macaddr)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>macaddr_minmax_ops</literal></entry>
+ <entry><literal>= (macaddr,macaddr)</literal></entry>
+ </row>
+ <row><entry><literal>< (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal><= (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal>> (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal>>= (macaddr,macaddr)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>macaddr_minmax_multi_ops</literal></entry>
+ <entry><literal>= (macaddr,macaddr)</literal></entry>
+ </row>
+ <row><entry><literal>< (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal><= (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal>> (macaddr,macaddr)</literal></entry></row>
+ <row><entry><literal>>= (macaddr,macaddr)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>macaddr8_bloom_ops</literal></entry>
+ <entry><literal>= (macaddr8,macaddr8)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>macaddr8_minmax_ops</literal></entry>
+ <entry><literal>= (macaddr8,macaddr8)</literal></entry>
+ </row>
+ <row><entry><literal>< (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal><= (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal>> (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal>>= (macaddr8,macaddr8)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>macaddr8_minmax_multi_ops</literal></entry>
+ <entry><literal>= (macaddr8,macaddr8)</literal></entry>
+ </row>
+ <row><entry><literal>< (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal><= (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal>> (macaddr8,macaddr8)</literal></entry></row>
+ <row><entry><literal>>= (macaddr8,macaddr8)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>name_bloom_ops</literal></entry>
+ <entry><literal>= (name,name)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>name_minmax_ops</literal></entry>
+ <entry><literal>= (name,name)</literal></entry>
+ </row>
+ <row><entry><literal>< (name,name)</literal></entry></row>
+ <row><entry><literal><= (name,name)</literal></entry></row>
+ <row><entry><literal>> (name,name)</literal></entry></row>
+ <row><entry><literal>>= (name,name)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>numeric_bloom_ops</literal></entry>
+ <entry><literal>= (numeric,numeric)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>numeric_minmax_ops</literal></entry>
+ <entry><literal>= (numeric,numeric)</literal></entry>
+ </row>
+ <row><entry><literal>< (numeric,numeric)</literal></entry></row>
+ <row><entry><literal><= (numeric,numeric)</literal></entry></row>
+ <row><entry><literal>> (numeric,numeric)</literal></entry></row>
+ <row><entry><literal>>= (numeric,numeric)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>numeric_minmax_multi_ops</literal></entry>
+ <entry><literal>= (numeric,numeric)</literal></entry>
+ </row>
+ <row><entry><literal>< (numeric,numeric)</literal></entry></row>
+ <row><entry><literal><= (numeric,numeric)</literal></entry></row>
+ <row><entry><literal>> (numeric,numeric)</literal></entry></row>
+ <row><entry><literal>>= (numeric,numeric)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>oid_bloom_ops</literal></entry>
+ <entry><literal>= (oid,oid)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>oid_minmax_ops</literal></entry>
+ <entry><literal>= (oid,oid)</literal></entry>
+ </row>
+ <row><entry><literal>< (oid,oid)</literal></entry></row>
+ <row><entry><literal>> (oid,oid)</literal></entry></row>
+ <row><entry><literal><= (oid,oid)</literal></entry></row>
+ <row><entry><literal>>= (oid,oid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>oid_minmax_multi_ops</literal></entry>
+ <entry><literal>= (oid,oid)</literal></entry>
+ </row>
+ <row><entry><literal>< (oid,oid)</literal></entry></row>
+ <row><entry><literal>> (oid,oid)</literal></entry></row>
+ <row><entry><literal><= (oid,oid)</literal></entry></row>
+ <row><entry><literal>>= (oid,oid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>pg_lsn_bloom_ops</literal></entry>
+ <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>pg_lsn_minmax_ops</literal></entry>
+ <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
+ </row>
+ <row><entry><literal>< (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal>> (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal><= (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal>>= (pg_lsn,pg_lsn)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>pg_lsn_minmax_multi_ops</literal></entry>
+ <entry><literal>= (pg_lsn,pg_lsn)</literal></entry>
+ </row>
+ <row><entry><literal>< (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal>> (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal><= (pg_lsn,pg_lsn)</literal></entry></row>
+ <row><entry><literal>>= (pg_lsn,pg_lsn)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="13"><literal>range_inclusion_ops</literal></entry>
+ <entry><literal>= (anyrange,anyrange)</literal></entry>
+ </row>
+ <row><entry><literal>< (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal><= (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>>= (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>&& (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>@> (anyrange,anyelement)</literal></entry></row>
+ <row><entry><literal>@> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal><@ (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal><< (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>>> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>&< (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>&> (anyrange,anyrange)</literal></entry></row>
+ <row><entry><literal>-|- (anyrange,anyrange)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>text_bloom_ops</literal></entry>
+ <entry><literal>= (text,text)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>text_minmax_ops</literal></entry>
+ <entry><literal>= (text,text)</literal></entry>
+ </row>
+ <row><entry><literal>< (text,text)</literal></entry></row>
+ <row><entry><literal><= (text,text)</literal></entry></row>
+ <row><entry><literal>> (text,text)</literal></entry></row>
+ <row><entry><literal>>= (text,text)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>tid_bloom_ops</literal></entry>
+ <entry><literal>= (tid,tid)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>tid_minmax_ops</literal></entry>
+ <entry><literal>= (tid,tid)</literal></entry>
+ </row>
+ <row><entry><literal>< (tid,tid)</literal></entry></row>
+ <row><entry><literal>> (tid,tid)</literal></entry></row>
+ <row><entry><literal><= (tid,tid)</literal></entry></row>
+ <row><entry><literal>>= (tid,tid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>tid_minmax_multi_ops</literal></entry>
+ <entry><literal>= (tid,tid)</literal></entry>
+ </row>
+ <row><entry><literal>< (tid,tid)</literal></entry></row>
+ <row><entry><literal>> (tid,tid)</literal></entry></row>
+ <row><entry><literal><= (tid,tid)</literal></entry></row>
+ <row><entry><literal>>= (tid,tid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>timestamp_bloom_ops</literal></entry>
+ <entry><literal>= (timestamp,timestamp)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timestamp_minmax_ops</literal></entry>
+ <entry><literal>= (timestamp,timestamp)</literal></entry>
+ </row>
+ <row><entry><literal>< (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal><= (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal>> (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal>>= (timestamp,timestamp)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timestamp_minmax_multi_ops</literal></entry>
+ <entry><literal>= (timestamp,timestamp)</literal></entry>
+ </row>
+ <row><entry><literal>< (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal><= (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal>> (timestamp,timestamp)</literal></entry></row>
+ <row><entry><literal>>= (timestamp,timestamp)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>timestamptz_bloom_ops</literal></entry>
+ <entry><literal>= (timestamptz,timestamptz)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timestamptz_minmax_ops</literal></entry>
+ <entry><literal>= (timestamptz,timestamptz)</literal></entry>
+ </row>
+ <row><entry><literal>< (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal><= (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal>> (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal>>= (timestamptz,timestamptz)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timestamptz_minmax_multi_ops</literal></entry>
+ <entry><literal>= (timestamptz,timestamptz)</literal></entry>
+ </row>
+ <row><entry><literal>< (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal><= (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal>> (timestamptz,timestamptz)</literal></entry></row>
+ <row><entry><literal>>= (timestamptz,timestamptz)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>time_bloom_ops</literal></entry>
+ <entry><literal>= (time,time)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>time_minmax_ops</literal></entry>
+ <entry><literal>= (time,time)</literal></entry>
+ </row>
+ <row><entry><literal>< (time,time)</literal></entry></row>
+ <row><entry><literal><= (time,time)</literal></entry></row>
+ <row><entry><literal>> (time,time)</literal></entry></row>
+ <row><entry><literal>>= (time,time)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>time_minmax_multi_ops</literal></entry>
+ <entry><literal>= (time,time)</literal></entry>
+ </row>
+ <row><entry><literal>< (time,time)</literal></entry></row>
+ <row><entry><literal><= (time,time)</literal></entry></row>
+ <row><entry><literal>> (time,time)</literal></entry></row>
+ <row><entry><literal>>= (time,time)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>timetz_bloom_ops</literal></entry>
+ <entry><literal>= (timetz,timetz)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timetz_minmax_ops</literal></entry>
+ <entry><literal>= (timetz,timetz)</literal></entry>
+ </row>
+ <row><entry><literal>< (timetz,timetz)</literal></entry></row>
+ <row><entry><literal><= (timetz,timetz)</literal></entry></row>
+ <row><entry><literal>> (timetz,timetz)</literal></entry></row>
+ <row><entry><literal>>= (timetz,timetz)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>timetz_minmax_multi_ops</literal></entry>
+ <entry><literal>= (timetz,timetz)</literal></entry>
+ </row>
+ <row><entry><literal>< (timetz,timetz)</literal></entry></row>
+ <row><entry><literal><= (timetz,timetz)</literal></entry></row>
+ <row><entry><literal>> (timetz,timetz)</literal></entry></row>
+ <row><entry><literal>>= (timetz,timetz)</literal></entry></row>
+
+ <row>
+ <entry valign="middle"><literal>uuid_bloom_ops</literal></entry>
+ <entry><literal>= (uuid,uuid)</literal></entry>
+ </row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>uuid_minmax_ops</literal></entry>
+ <entry><literal>= (uuid,uuid)</literal></entry>
+ </row>
+ <row><entry><literal>< (uuid,uuid)</literal></entry></row>
+ <row><entry><literal>> (uuid,uuid)</literal></entry></row>
+ <row><entry><literal><= (uuid,uuid)</literal></entry></row>
+ <row><entry><literal>>= (uuid,uuid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>uuid_minmax_multi_ops</literal></entry>
+ <entry><literal>= (uuid,uuid)</literal></entry>
+ </row>
+ <row><entry><literal>< (uuid,uuid)</literal></entry></row>
+ <row><entry><literal>> (uuid,uuid)</literal></entry></row>
+ <row><entry><literal><= (uuid,uuid)</literal></entry></row>
+ <row><entry><literal>>= (uuid,uuid)</literal></entry></row>
+
+ <row>
+ <entry valign="middle" morerows="4"><literal>varbit_minmax_ops</literal></entry>
+ <entry><literal>= (varbit,varbit)</literal></entry>
+ </row>
+ <row><entry><literal>< (varbit,varbit)</literal></entry></row>
+ <row><entry><literal>> (varbit,varbit)</literal></entry></row>
+ <row><entry><literal><= (varbit,varbit)</literal></entry></row>
+ <row><entry><literal>>= (varbit,varbit)</literal></entry></row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <sect3 id="brin-builtin-opclasses--parameters">
+ <title>Operator Class Parameters</title>
+
+ <para>
+ Some of the built-in operator classes allow specifying parameters affecting
+ behavior of the operator class. Each operator class has its own set of
+ allowed parameters. Only the <literal>bloom</literal> and <literal>minmax-multi</literal>
+ operator classes allow specifying parameters:
+ </para>
+
+ <para>
+ bloom operator classes accept these parameters:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>n_distinct_per_range</literal></term>
+ <listitem>
+ <para>
+ Defines the estimated number of distinct non-null values in the block
+ range, used by <acronym>BRIN</acronym> bloom indexes for sizing of the
+ Bloom filter. It behaves similarly to <literal>n_distinct</literal> option
+ for <xref linkend="sql-altertable"/>. When set to a positive value,
+ each block range is assumed to contain this number of distinct non-null
+ values. When set to a negative value, which must be greater than or
+ equal to -1, the number of distinct non-null values is assumed to grow linearly with
+ the maximum possible number of tuples in the block range (about 290
+ rows per block). The default value is <literal>-0.1</literal>, and
+ the minimum number of distinct non-null values is <literal>16</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>false_positive_rate</literal></term>
+ <listitem>
+ <para>
+ Defines the desired false positive rate used by <acronym>BRIN</acronym>
+ bloom indexes for sizing of the Bloom filter. The values must be
+ between 0.0001 and 0.25. The default value is 0.01, which is 1% false
+ positive rate.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ <para>
+ minmax-multi operator classes accept these parameters:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>values_per_range</literal></term>
+ <listitem>
+ <para>
+ Defines the maximum number of values stored by <acronym>BRIN</acronym>
+ minmax indexes to summarize a block range. Each value may represent
+ either a point, or a boundary of an interval. Values must be between
+ 8 and 256, and the default value is 32.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="brin-extensibility">
+ <title>Extensibility</title>
+
+ <para>
+ The <acronym>BRIN</acronym> interface has a high level of abstraction,
+ requiring the access method implementer only to implement the semantics
+ of the data type being accessed. The <acronym>BRIN</acronym> layer
+ itself takes care of concurrency, logging and searching the index structure.
+ </para>
+
+ <para>
+ All it takes to get a <acronym>BRIN</acronym> access method working is to
+ implement a few user-defined methods, which define the behavior of
+ summary values stored in the index and the way they interact with
+ scan keys.
+ In short, <acronym>BRIN</acronym> combines
+ extensibility with generality, code reuse, and a clean interface.
+ </para>
+
+ <para>
+ There are four methods that an operator class for <acronym>BRIN</acronym>
+ must provide:
+
+ <variablelist>
+ <varlistentry>
+ <term><function>BrinOpcInfo *opcInfo(Oid type_oid)</function></term>
+ <listitem>
+ <para>
+ Returns internal information about the indexed columns' summary data.
+ The return value must point to a palloc'd <structname>BrinOpcInfo</structname>,
+ which has this definition:
+<programlisting>
+typedef struct BrinOpcInfo
+{
+ /* Number of columns stored in an index column of this opclass */
+ uint16 oi_nstored;
+
+ /* Opaque pointer for the opclass' private use */
+ void *oi_opaque;
+
+ /* Type cache entries of the stored columns */
+ TypeCacheEntry *oi_typcache[FLEXIBLE_ARRAY_MEMBER];
+} BrinOpcInfo;
+</programlisting>
+ <structname>BrinOpcInfo</structname>.<structfield>oi_opaque</structfield> can be used by the
+ operator class routines to pass information between support functions
+ during an index scan.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>bool consistent(BrinDesc *bdesc, BrinValues *column,
+ ScanKey *keys, int nkeys)</function></term>
+ <listitem>
+ <para>
+ Returns whether all the ScanKey entries are consistent with the given
+ indexed values for a range.
+ The attribute number to use is passed as part of the scan key.
+ Multiple scan keys for the same attribute may be passed at once; the
+ number of entries is determined by the <literal>nkeys</literal> parameter.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>bool consistent(BrinDesc *bdesc, BrinValues *column,
+ ScanKey key)</function></term>
+ <listitem>
+ <para>
+ Returns whether the ScanKey is consistent with the given indexed
+ values for a range.
+ The attribute number to use is passed as part of the scan key.
+ This is an older backward-compatible variant of the consistent function.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>bool addValue(BrinDesc *bdesc, BrinValues *column,
+ Datum newval, bool isnull)</function></term>
+ <listitem>
+ <para>
+ Given an index tuple and an indexed value, modifies the indicated
+ attribute of the tuple so that it additionally represents the new value.
+ If any modification was done to the tuple, <literal>true</literal> is
+ returned.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><function>bool unionTuples(BrinDesc *bdesc, BrinValues *a,
+ BrinValues *b)</function></term>
+ <listitem>
+ <para>
+ Consolidates two index tuples. Given two index tuples, modifies the
+ indicated attribute of the first of them so that it represents both tuples.
+ The second tuple is not modified.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ An operator class for <acronym>BRIN</acronym> can optionally specify the
+ following method:
+
+ <variablelist>
+ <varlistentry>
+ <term><function>void options(local_relopts *relopts)</function></term>
+ <listitem>
+ <para>
+ Defines a set of user-visible parameters that control operator class
+ behavior.
+ </para>
+
+ <para>
+ The <function>options</function> function is passed a pointer to a
+ <structname>local_relopts</structname> struct, which needs to be
+ filled with a set of operator class specific options. The options
+ can be accessed from other support functions using the
+ <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
+ <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
+ </para>
+
+ <para>
+ Since both key extraction of indexed values and representation of the
+ key in <acronym>BRIN</acronym> are flexible, they may depend on
+ user-specified parameters.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ The core distribution includes support for four types of operator classes:
+ minmax, minmax-multi, inclusion and bloom. Operator class definitions
+ using them are shipped for in-core data types as appropriate. Additional
+ operator classes can be defined by the user for other data types using
+ equivalent definitions, without having to write any source code;
+ appropriate catalog entries being declared is enough. Note that
+ assumptions about the semantics of operator strategies are embedded in the
+ support functions' source code.
+ </para>
+
+ <para>
+ Operator classes that implement completely different semantics are also
+ possible, provided implementations of the four main support functions
+ described above are written. Note that backwards compatibility across major
+ releases is not guaranteed: for example, additional support functions might
+ be required in later releases.
+ </para>
+
+ <para>
+ To write an operator class for a data type that implements a totally
+ ordered set, it is possible to use the minmax support functions
+ alongside the corresponding operators, as shown in
+ <xref linkend="brin-extensibility-minmax-table"/>.
+ All operator class members (functions and operators) are mandatory.
+ </para>
+
+ <table id="brin-extensibility-minmax-table">
+ <title>Function and Support Numbers for Minmax Operator Classes</title>
+ <tgroup cols="2">
+ <colspec colname="col1" colwidth="1*"/>
+ <colspec colname="col2" colwidth="2*"/>
+ <thead>
+ <row>
+ <entry>Operator class member</entry>
+ <entry>Object</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Support Function 1</entry>
+ <entry>internal function <function>brin_minmax_opcinfo()</function></entry>
+ </row>
+ <row>
+ <entry>Support Function 2</entry>
+ <entry>internal function <function>brin_minmax_add_value()</function></entry>
+ </row>
+ <row>
+ <entry>Support Function 3</entry>
+ <entry>internal function <function>brin_minmax_consistent()</function></entry>
+ </row>
+ <row>
+ <entry>Support Function 4</entry>
+ <entry>internal function <function>brin_minmax_union()</function></entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 1</entry>
+ <entry>operator less-than</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 2</entry>
+ <entry>operator less-than-or-equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 3</entry>
+ <entry>operator equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 4</entry>
+ <entry>operator greater-than-or-equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 5</entry>
+ <entry>operator greater-than</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ To write an operator class for a complex data type which has values
+ included within another type, it's possible to use the inclusion support
+ functions alongside the corresponding operators, as shown
+ in <xref linkend="brin-extensibility-inclusion-table"/>. It requires
+ only a single additional function, which can be written in any language.
+ More functions can be defined for additional functionality. All operators
+ are optional. Some operators require other operators, as shown as
+ dependencies on the table.
+ </para>
+
+ <table id="brin-extensibility-inclusion-table">
+ <title>Function and Support Numbers for Inclusion Operator Classes</title>
+ <tgroup cols="3">
+ <colspec colname="col1" colwidth="1*"/>
+ <colspec colname="col2" colwidth="2*"/>
+ <colspec colname="col3" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry>Operator class member</entry>
+ <entry>Object</entry>
+ <entry>Dependency</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Support Function 1</entry>
+ <entry>internal function <function>brin_inclusion_opcinfo()</function></entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 2</entry>
+ <entry>internal function <function>brin_inclusion_add_value()</function></entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 3</entry>
+ <entry>internal function <function>brin_inclusion_consistent()</function></entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 4</entry>
+ <entry>internal function <function>brin_inclusion_union()</function></entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 11</entry>
+ <entry>function to merge two elements</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 12</entry>
+ <entry>optional function to check whether two elements are mergeable</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 13</entry>
+ <entry>optional function to check if an element is contained within another</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Support Function 14</entry>
+ <entry>optional function to check whether an element is empty</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 1</entry>
+ <entry>operator left-of</entry>
+ <entry>Operator Strategy 4</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 2</entry>
+ <entry>operator does-not-extend-to-the-right-of</entry>
+ <entry>Operator Strategy 5</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 3</entry>
+ <entry>operator overlaps</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 4</entry>
+ <entry>operator does-not-extend-to-the-left-of</entry>
+ <entry>Operator Strategy 1</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 5</entry>
+ <entry>operator right-of</entry>
+ <entry>Operator Strategy 2</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 6, 18</entry>
+ <entry>operator same-as-or-equal-to</entry>
+ <entry>Operator Strategy 7</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 7, 16, 24, 25</entry>
+ <entry>operator contains-or-equal-to</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 8, 26, 27</entry>
+ <entry>operator is-contained-by-or-equal-to</entry>
+ <entry>Operator Strategy 3</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 9</entry>
+ <entry>operator does-not-extend-above</entry>
+ <entry>Operator Strategy 11</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 10</entry>
+ <entry>operator is-below</entry>
+ <entry>Operator Strategy 12</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 11</entry>
+ <entry>operator is-above</entry>
+ <entry>Operator Strategy 9</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 12</entry>
+ <entry>operator does-not-extend-below</entry>
+ <entry>Operator Strategy 10</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 20</entry>
+ <entry>operator less-than</entry>
+ <entry>Operator Strategy 5</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 21</entry>
+ <entry>operator less-than-or-equal-to</entry>
+ <entry>Operator Strategy 5</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 22</entry>
+ <entry>operator greater-than</entry>
+ <entry>Operator Strategy 1</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 23</entry>
+ <entry>operator greater-than-or-equal-to</entry>
+ <entry>Operator Strategy 1</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Support function numbers 1 through 10 are reserved for the BRIN internal
+ functions, so the SQL level functions start with number 11. Support
+ function number 11 is the main function required to build the index.
+ It should accept two arguments with the same data type as the operator class,
+ and return the union of them. The inclusion operator class can store union
+ values with different data types if it is defined with the
+ <literal>STORAGE</literal> parameter. The return value of the union
+ function should match the <literal>STORAGE</literal> data type.
+ </para>
+
+ <para>
+ Support function numbers 12 and 14 are provided to support
+ irregularities of built-in data types. Function number 12
+ is used to support network addresses from different families which
+ are not mergeable. Function number 14 is used to support
+ empty ranges. Function number 13 is an optional but
+ recommended one, which allows the new value to be checked before
+ it is passed to the union function. As the BRIN framework can shortcut
+ some operations when the union is not changed, using this
+ function can improve index performance.
+ </para>
+
+ <para>
+ To write an operator class for a data type that implements only an equality
+ operator and supports hashing, it is possible to use the bloom support procedures
+ alongside the corresponding operators, as shown in
+ <xref linkend="brin-extensibility-bloom-table"/>.
+ All operator class members (procedures and operators) are mandatory.
+ </para>
+
+ <table id="brin-extensibility-bloom-table">
+ <title>Procedure and Support Numbers for Bloom Operator Classes</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Operator class member</entry>
+ <entry>Object</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Support Procedure 1</entry>
+ <entry>internal function <function>brin_bloom_opcinfo()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 2</entry>
+ <entry>internal function <function>brin_bloom_add_value()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 3</entry>
+ <entry>internal function <function>brin_bloom_consistent()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 4</entry>
+ <entry>internal function <function>brin_bloom_union()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 5</entry>
+ <entry>internal function <function>brin_bloom_options()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 11</entry>
+ <entry>function to compute hash of an element</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 1</entry>
+ <entry>operator equal-to</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Support procedure numbers 1-10 are reserved for the BRIN internal
+ functions, so the SQL level functions start with number 11. Support
+ function number 11 is the main function required to build the index.
+ It should accept one argument with the same data type as the operator class,
+ and return a hash of the value.
+ </para>
+
+ <para>
+ The minmax-multi operator class is also intended for data types implementing
+ a totally ordered set, and may be seen as a simple extension of the minmax
+ operator class. While minmax operator class summarizes values from each block
+ range into a single contiguous interval, minmax-multi allows summarization
+ into multiple smaller intervals to improve handling of outlier values.
+ It is possible to use the minmax-multi support procedures alongside the
+ corresponding operators, as shown in
+ <xref linkend="brin-extensibility-minmax-multi-table"/>.
+ All operator class members (procedures and operators) are mandatory.
+ </para>
+
+ <table id="brin-extensibility-minmax-multi-table">
+ <title>Procedure and Support Numbers for minmax-multi Operator Classes</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Operator class member</entry>
+ <entry>Object</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Support Procedure 1</entry>
+ <entry>internal function <function>brin_minmax_multi_opcinfo()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 2</entry>
+ <entry>internal function <function>brin_minmax_multi_add_value()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 3</entry>
+ <entry>internal function <function>brin_minmax_multi_consistent()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 4</entry>
+ <entry>internal function <function>brin_minmax_multi_union()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 5</entry>
+ <entry>internal function <function>brin_minmax_multi_options()</function></entry>
+ </row>
+ <row>
+ <entry>Support Procedure 11</entry>
+ <entry>function to compute distance between two values (length of a range)</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 1</entry>
+ <entry>operator less-than</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 2</entry>
+ <entry>operator less-than-or-equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 3</entry>
+ <entry>operator equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 4</entry>
+ <entry>operator greater-than-or-equal-to</entry>
+ </row>
+ <row>
+ <entry>Operator Strategy 5</entry>
+ <entry>operator greater-than</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Both minmax and inclusion operator classes support cross-data-type
+ operators, though with these the dependencies become more complicated.
+ The minmax operator class requires a full set of operators to be
+ defined with both arguments having the same data type. It allows
+ additional data types to be supported by defining extra sets
+ of operators. Inclusion operator class operator strategies are dependent
+ on another operator strategy as shown in
+ <xref linkend="brin-extensibility-inclusion-table"/>, or the same
+ operator strategy as themselves. They require the dependency
+ operator to be defined with the <literal>STORAGE</literal> data type as the
+ left-hand-side argument and the other supported data type to be the
+ right-hand-side argument of the supported operator. See
+ <literal>float4_minmax_ops</literal> as an example of minmax, and
+ <literal>box_inclusion_ops</literal> as an example of inclusion.
+ </para>
+ </sect2>
+ </sect1>
+
+ <sect1 id="hash-index">
+ <title>Hash Indexes</title>
+
+ <indexterm>
+ <primary>index</primary>
+ <secondary>Hash</secondary>
+ </indexterm>
+
+ <sect2 id="hash-intro">
+ <title>Overview</title>
+
+ <para>
+ <productname>PostgreSQL</productname>
+ includes an implementation of persistent on-disk hash indexes,
+ which are fully crash recoverable. Any data type can be indexed by a
+ hash index, including data types that do not have a well-defined linear
+ ordering. Hash indexes store only the hash value of the data being
+ indexed, thus there are no restrictions on the size of the data column
+ being indexed.
+ </para>
+
+ <para>
+ Hash indexes support only single-column indexes and do not allow
+ uniqueness checking.
+ </para>
+
+ <para>
+ Hash indexes support only the <literal>=</literal> operator,
+ so WHERE clauses that specify range operations will not be able to take
+ advantage of hash indexes.
+ </para>
+
+ <para>
+ Each hash index tuple stores just the 4-byte hash value, not the actual
+ column value. As a result, hash indexes may be much smaller than B-trees
+ when indexing longer data items such as UUIDs, URLs, etc. The absence of
+ the column value also makes all hash index scans lossy. Hash indexes may
+ take part in bitmap index scans and backward scans.
+ </para>
+
+ <para>
+ Hash indexes are best optimized for SELECT and UPDATE-heavy workloads
+ that use equality scans on larger tables. In a B-tree index, searches must
+ descend through the tree until the leaf page is found. In tables with
+ millions of rows, this descent can increase access time to data. The
+ equivalent of a leaf page in a hash index is referred to as a bucket page. In
+ contrast, a hash index allows accessing the bucket pages directly,
+ thereby potentially reducing index access time in larger tables. This
+ reduction in "logical I/O" becomes even more pronounced on indexes/data
+ larger than shared_buffers/RAM.
+ </para>
+
+ <para>
+ Hash indexes have been designed to cope with uneven distributions of
+ hash values. Direct access to the bucket pages works well if the hash
+ values are evenly distributed. When inserts mean that the bucket page
+ becomes full, additional overflow pages are chained to that specific
+ bucket page, locally expanding the storage for index tuples that match
+ that hash value. When scanning a hash bucket during queries, we need to
+ scan through all of the overflow pages. Thus an unbalanced hash index
+ might actually be worse than a B-tree in terms of number of block
+ accesses required, for some data.
+ </para>
+
+ <para>
+ As a result of the overflow cases, we can say that hash indexes are
+ most suitable for unique, nearly unique data or data with a low number
+ of rows per hash bucket.
+ One possible way to avoid problems is to exclude highly non-unique
+ values from the index using a partial index condition, but this may
+ not be suitable in many cases.
+ </para>
+
+ <para>
+ Like B-Trees, hash indexes perform simple index tuple deletion. This
+ is a deferred maintenance operation that deletes index tuples that are
+ known to be safe to delete (those whose item identifier's LP_DEAD bit
+ is already set). If an insert finds no space is available on a page we
+ try to avoid creating a new overflow page by attempting to remove dead
+ index tuples. Removal cannot occur if the page is pinned at that time.
+ Deletion of dead index pointers also occurs during VACUUM.
+ </para>
+
+ <para>
+ If it can, VACUUM will also try to squeeze the index tuples onto as
+ few overflow pages as possible, minimizing the overflow chain. If an
+ overflow page becomes empty, overflow pages can be recycled for reuse
+ in other buckets, though we never return them to the operating system.
+ There is currently no provision to shrink a hash index, other than by
+ rebuilding it with REINDEX.
+ There is no provision for reducing the number of buckets, either.
+ </para>
+
+ <para>
+ Hash indexes may expand the number of bucket pages as the number of
+ rows indexed grows. The hash key-to-bucket-number mapping is chosen so that
+ the index can be incrementally expanded. When a new bucket is to be added to
+ the index, exactly one existing bucket will need to be "split", with some of
+ its tuples being transferred to the new bucket according to the updated
+ key-to-bucket-number mapping.
+ </para>
+
+ <para>
+ The expansion occurs in the foreground, which could increase execution
+ time for user inserts. Thus, hash indexes may not be suitable for tables
+ with rapidly increasing number of rows.
+ </para>
+
+ </sect2>
+
+ <sect2 id="hash-implementation">
+ <title>Implementation</title>
+
+ <para>
+ There are four kinds of pages in a hash index: the meta page (page zero),
+ which contains statically allocated control information; primary bucket
+ pages; overflow pages; and bitmap pages, which keep track of overflow
+ pages that have been freed and are available for re-use. For addressing
+ purposes, bitmap pages are regarded as a subset of the overflow pages.
+ </para>
+
+ <para>
+ Both scanning the index and inserting tuples require locating the bucket
+ where a given tuple ought to be located. To do this, we need the bucket
+ count, highmask, and lowmask from the metapage; however, it's undesirable
+ for performance reasons to have to have to lock and pin the metapage for
+ every such operation. Instead, we retain a cached copy of the metapage
+ in each backend's relcache entry. This will produce the correct bucket
+ mapping as long as the target bucket hasn't been split since the last
+ cache refresh.
+ </para>
+
+ <para>
+ Primary bucket pages and overflow pages are allocated independently since
+ any given index might need more or fewer overflow pages relative to its
+ number of buckets. The hash code uses an interesting set of addressing
+ rules to support a variable number of overflow pages while not having to
+ move primary bucket pages around after they are created.
+ </para>
+
+ <para>
+ Each row in the table indexed is represented by a single index tuple in
+ the hash index. Hash index tuples are stored in bucket pages, and if
+ they exist, overflow pages. We speed up searches by keeping the index entries
+ in any one index page sorted by hash code, thus allowing binary search to be
+ used within an index page. Note however that there is *no* assumption about
+ the relative ordering of hash codes across different index pages of a bucket.
+ </para>
+
+ <para>
+ The bucket splitting algorithms to expand the hash index are too complex to
+ be worthy of mention here, though are described in more detail in
+ <filename>src/backend/access/hash/README</filename>.
+ The split algorithm is crash safe and can be restarted if not completed
+ successfully.
+ </para>
+
+ </sect2>
+
+ </sect1>
+
+</chapter>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 73b497bcf8..0235c0e352 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -257,12 +257,7 @@ break is not needed in a wider output rendering.
&indexam;
&generic-wal;
&custom-rmgr;
- &btree;
- &gist;
- &spgist;
- &gin;
- &brin;
- &hash;
+ &indextypes;
&storage;
&transaction;
&bki;
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
deleted file mode 100644
index 102f8627bd..0000000000
--- a/doc/src/sgml/spgist.sgml
+++ /dev/null
@@ -1,1076 +0,0 @@
-<!-- doc/src/sgml/spgist.sgml -->
-
-<chapter id="spgist">
-<title>SP-GiST Indexes</title>
-
- <indexterm>
- <primary>index</primary>
- <secondary>SP-GiST</secondary>
- </indexterm>
-
-<sect1 id="spgist-intro">
- <title>Introduction</title>
-
- <para>
- <acronym>SP-GiST</acronym> is an abbreviation for space-partitioned
- <acronym>GiST</acronym>. <acronym>SP-GiST</acronym> supports partitioned
- search trees, which facilitate development of a wide range of different
- non-balanced data structures, such as quad-trees, k-d trees, and radix
- trees (tries). The common feature of these structures is that they
- repeatedly divide the search space into partitions that need not be
- of equal size. Searches that are well matched to the partitioning rule
- can be very fast.
- </para>
-
- <para>
- These popular data structures were originally developed for in-memory
- usage. In main memory, they are usually designed as a set of dynamically
- allocated nodes linked by pointers. This is not suitable for direct
- storing on disk, since these chains of pointers can be rather long which
- would require too many disk accesses. In contrast, disk-based data
- structures should have a high fanout to minimize I/O. The challenge
- addressed by <acronym>SP-GiST</acronym> is to map search tree nodes to
- disk pages in such a way that a search need access only a few disk pages,
- even if it traverses many nodes.
- </para>
-
- <para>
- Like <acronym>GiST</acronym>, <acronym>SP-GiST</acronym> is meant to allow
- the development of custom data types with the appropriate access methods,
- by an expert in the domain of the data type, rather than a database expert.
- </para>
-
- <para>
- Some of the information here is derived from Purdue University's
- SP-GiST Indexing Project
- <ulink url="https://www.cs.purdue.edu/spgist/">web site</ulink>.
- The <acronym>SP-GiST</acronym> implementation in
- <productname>PostgreSQL</productname> is primarily maintained by Teodor
- Sigaev and Oleg Bartunov, and there is more information on their
- <!-- URL will be changed -->
- <ulink url="http://www.sai.msu.su/~megera/wiki/spgist_dev">web site</ulink>.
- </para>
-
-</sect1>
-
-<sect1 id="spgist-builtin-opclasses">
- <title>Built-in Operator Classes</title>
-
- <para>
- The core <productname>PostgreSQL</productname> distribution
- includes the <acronym>SP-GiST</acronym> operator classes shown in
- <xref linkend="spgist-builtin-opclasses-table"/>.
- </para>
-
- <table id="spgist-builtin-opclasses-table">
- <title>Built-in <acronym>SP-GiST</acronym> Operator Classes</title>
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Name</entry>
- <entry>Indexable Operators</entry>
- <entry>Ordering Operators</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry valign="middle" morerows="11"><literal>box_ops</literal></entry>
- <entry><literal><< (box,box)</literal></entry>
- <entry valign="middle" morerows="11"><literal><-> (box,point)</literal></entry>
- </row>
- <row><entry><literal>&< (box,box)</literal></entry></row>
- <row><entry><literal>&> (box,box)</literal></entry></row>
- <row><entry><literal>>> (box,box)</literal></entry></row>
- <row><entry><literal><@ (box,box)</literal></entry></row>
- <row><entry><literal>@> (box,box)</literal></entry></row>
- <row><entry><literal>~= (box,box)</literal></entry></row>
- <row><entry><literal>&& (box,box)</literal></entry></row>
- <row><entry><literal><<| (box,box)</literal></entry></row>
- <row><entry><literal>&<| (box,box)</literal></entry></row>
- <row><entry><literal>|&> (box,box)</literal></entry></row>
- <row><entry><literal>|>> (box,box)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="10"><literal>inet_ops</literal></entry>
- <entry><literal><< (inet,inet)</literal></entry>
- <entry valign="middle" morerows="10"></entry>
- </row>
- <row><entry><literal><<= (inet,inet)</literal></entry></row>
- <row><entry><literal>>> (inet,inet)</literal></entry></row>
- <row><entry><literal>>>= (inet,inet)</literal></entry></row>
- <row><entry><literal>= (inet,inet)</literal></entry></row>
- <row><entry><literal><> (inet,inet)</literal></entry></row>
- <row><entry><literal>< (inet,inet)</literal></entry></row>
- <row><entry><literal><= (inet,inet)</literal></entry></row>
- <row><entry><literal>> (inet,inet)</literal></entry></row>
- <row><entry><literal>>= (inet,inet)</literal></entry></row>
- <row><entry><literal>&& (inet,inet)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="5"><literal>kd_point_ops</literal></entry>
- <entry><literal>|>> (point,point)</literal></entry>
- <entry valign="middle" morerows="5"><literal><-> (point,point)</literal></entry>
- </row>
- <row><entry><literal><< (point,point)</literal></entry></row>
- <row><entry><literal>>> (point,point)</literal></entry></row>
- <row><entry><literal><<| (point,point)</literal></entry></row>
- <row><entry><literal>~= (point,point)</literal></entry></row>
- <row><entry><literal><@ (point,box)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="11"><literal>poly_ops</literal></entry>
- <entry><literal><< (polygon,polygon)</literal></entry>
- <entry valign="middle" morerows="11"><literal><-> (polygon,point)</literal></entry>
- </row>
- <row><entry><literal>&< (polygon,polygon)</literal></entry></row>
- <row><entry><literal>&> (polygon,polygon)</literal></entry></row>
- <row><entry><literal>>> (polygon,polygon)</literal></entry></row>
- <row><entry><literal><@ (polygon,polygon)</literal></entry></row>
- <row><entry><literal>@> (polygon,polygon)</literal></entry></row>
- <row><entry><literal>~= (polygon,polygon)</literal></entry></row>
- <row><entry><literal>&& (polygon,polygon)</literal></entry></row>
- <row><entry><literal><<| (polygon,polygon)</literal></entry></row>
- <row><entry><literal>&<| (polygon,polygon)</literal></entry></row>
- <row><entry><literal>|>> (polygon,polygon)</literal></entry></row>
- <row><entry><literal>|&> (polygon,polygon)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="5"><literal>quad_point_ops</literal></entry>
- <entry><literal>|>> (point,point)</literal></entry>
- <entry valign="middle" morerows="5"><literal><-> (point,point)</literal></entry>
- </row>
- <row><entry><literal><< (point,point)</literal></entry></row>
- <row><entry><literal>>> (point,point)</literal></entry></row>
- <row><entry><literal><<| (point,point)</literal></entry></row>
- <row><entry><literal>~= (point,point)</literal></entry></row>
- <row><entry><literal><@ (point,box)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="9"><literal>range_ops</literal></entry>
- <entry><literal>= (anyrange,anyrange)</literal></entry>
- <entry valign="middle" morerows="9"></entry>
- </row>
- <row><entry><literal>&& (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>@> (anyrange,anyelement)</literal></entry></row>
- <row><entry><literal>@> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal><@ (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal><< (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>>> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>&< (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>&> (anyrange,anyrange)</literal></entry></row>
- <row><entry><literal>-|- (anyrange,anyrange)</literal></entry></row>
-
- <row>
- <entry valign="middle" morerows="9"><literal>text_ops</literal></entry>
- <entry><literal>= (text,text)</literal></entry>
- <entry valign="middle" morerows="9"></entry>
- </row>
- <row><entry><literal>< (text,text)</literal></entry></row>
- <row><entry><literal><= (text,text)</literal></entry></row>
- <row><entry><literal>> (text,text)</literal></entry></row>
- <row><entry><literal>>= (text,text)</literal></entry></row>
- <row><entry><literal>~<~ (text,text)</literal></entry></row>
- <row><entry><literal>~<=~ (text,text)</literal></entry></row>
- <row><entry><literal>~>=~ (text,text)</literal></entry></row>
- <row><entry><literal>~>~ (text,text)</literal></entry></row>
- <row><entry><literal>^@ (text,text)</literal></entry></row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Of the two operator classes for type <type>point</type>,
- <literal>quad_point_ops</literal> is the default. <literal>kd_point_ops</literal>
- supports the same operators but uses a different index data structure that
- may offer better performance in some applications.
- </para>
- <para>
- The <literal>quad_point_ops</literal>, <literal>kd_point_ops</literal> and
- <literal>poly_ops</literal> operator classes support the <literal><-></literal>
- ordering operator, which enables the k-nearest neighbor (<literal>k-NN</literal>)
- search over indexed point or polygon data sets.
- </para>
-
-</sect1>
-
-<sect1 id="spgist-extensibility">
- <title>Extensibility</title>
-
- <para>
- <acronym>SP-GiST</acronym> offers an interface with a high level of
- abstraction, requiring the access method developer to implement only
- methods specific to a given data type. The <acronym>SP-GiST</acronym> core
- is responsible for efficient disk mapping and searching the tree structure.
- It also takes care of concurrency and logging considerations.
- </para>
-
- <para>
- Leaf tuples of an <acronym>SP-GiST</acronym> tree usually contain values
- of the same data type as the indexed column, although it is also possible
- for them to contain lossy representations of the indexed column.
- Leaf tuples stored at the root level will directly represent
- the original indexed data value, but leaf tuples at lower
- levels might contain only a partial value, such as a suffix.
- In that case the operator class support functions must be able to
- reconstruct the original value using information accumulated from the
- inner tuples that are passed through to reach the leaf level.
- </para>
-
- <para>
- When an <acronym>SP-GiST</acronym> index is created with
- <literal>INCLUDE</literal> columns, the values of those columns are also
- stored in leaf tuples. The <literal>INCLUDE</literal> columns are of no
- concern to the <acronym>SP-GiST</acronym> operator class, so they are
- not discussed further here.
- </para>
-
- <para>
- Inner tuples are more complex, since they are branching points in the
- search tree. Each inner tuple contains a set of one or more
- <firstterm>nodes</firstterm>, which represent groups of similar leaf values.
- A node contains a downlink that leads either to another, lower-level inner
- tuple, or to a short list of leaf tuples that all lie on the same index page.
- Each node normally has a <firstterm>label</firstterm> that describes it; for example,
- in a radix tree the node label could be the next character of the string
- value. (Alternatively, an operator class can omit the node labels, if it
- works with a fixed set of nodes for all inner tuples;
- see <xref linkend="spgist-null-labels"/>.)
- Optionally, an inner tuple can have a <firstterm>prefix</firstterm> value
- that describes all its members. In a radix tree this could be the common
- prefix of the represented strings. The prefix value is not necessarily
- really a prefix, but can be any data needed by the operator class;
- for example, in a quad-tree it can store the central point that the four
- quadrants are measured with respect to. A quad-tree inner tuple would
- then also contain four nodes corresponding to the quadrants around this
- central point.
- </para>
-
- <para>
- Some tree algorithms require knowledge of level (or depth) of the current
- tuple, so the <acronym>SP-GiST</acronym> core provides the possibility for
- operator classes to manage level counting while descending the tree.
- There is also support for incrementally reconstructing the represented
- value when that is needed, and for passing down additional data (called
- <firstterm>traverse values</firstterm>) during a tree descent.
- </para>
-
- <note>
- <para>
- The <acronym>SP-GiST</acronym> core code takes care of null entries.
- Although <acronym>SP-GiST</acronym> indexes do store entries for nulls
- in indexed columns, this is hidden from the index operator class code:
- no null index entries or search conditions will ever be passed to the
- operator class methods. (It is assumed that <acronym>SP-GiST</acronym>
- operators are strict and so cannot succeed for null values.) Null values
- are therefore not discussed further here.
- </para>
- </note>
-
- <para>
- There are five user-defined methods that an index operator class for
- <acronym>SP-GiST</acronym> must provide, and two are optional. All five
- mandatory methods follow the convention of accepting two <type>internal</type>
- arguments, the first of which is a pointer to a C struct containing input
- values for the support method, while the second argument is a pointer to a
- C struct where output values must be placed. Four of the mandatory methods just
- return <type>void</type>, since all their results appear in the output struct; but
- <function>leaf_consistent</function> returns a <type>boolean</type> result.
- The methods must not modify any fields of their input structs. In all
- cases, the output struct is initialized to zeroes before calling the
- user-defined method. The optional sixth method <function>compress</function>
- accepts a <type>datum</type> to be indexed as the only argument and returns a value suitable
- for physical storage in a leaf tuple. The optional seventh method
- <function>options</function> accepts an <type>internal</type> pointer to a C struct, where
- opclass-specific parameters should be placed, and returns <type>void</type>.
- </para>
-
- <para>
- The five mandatory user-defined methods are:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><function>config</function></term>
- <listitem>
- <para>
- Returns static information about the index implementation, including
- the data type OIDs of the prefix and node label data types.
- </para>
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-<programlisting>
-CREATE FUNCTION my_config(internal, internal) RETURNS void ...
-</programlisting>
- The first argument is a pointer to a <structname>spgConfigIn</structname>
- C struct, containing input data for the function.
- The second argument is a pointer to a <structname>spgConfigOut</structname>
- C struct, which the function must fill with result data.
-<programlisting>
-typedef struct spgConfigIn
-{
- Oid attType; /* Data type to be indexed */
-} spgConfigIn;
-
-typedef struct spgConfigOut
-{
- Oid prefixType; /* Data type of inner-tuple prefixes */
- Oid labelType; /* Data type of inner-tuple node labels */
- Oid leafType; /* Data type of leaf-tuple values */
- bool canReturnData; /* Opclass can reconstruct original data */
- bool longValuesOK; /* Opclass can cope with values > 1 page */
-} spgConfigOut;
-</programlisting>
-
- <structfield>attType</structfield> is passed in order to support polymorphic
- index operator classes; for ordinary fixed-data-type operator classes, it
- will always have the same value and so can be ignored.
- </para>
-
- <para>
- For operator classes that do not use prefixes,
- <structfield>prefixType</structfield> can be set to <literal>VOIDOID</literal>.
- Likewise, for operator classes that do not use node labels,
- <structfield>labelType</structfield> can be set to <literal>VOIDOID</literal>.
- <structfield>canReturnData</structfield> should be set true if the operator class
- is capable of reconstructing the originally-supplied index value.
- <structfield>longValuesOK</structfield> should be set true only when the
- <structfield>attType</structfield> is of variable length and the operator
- class is capable of segmenting long values by repeated suffixing
- (see <xref linkend="spgist-limits"/>).
- </para>
-
- <para>
- <structfield>leafType</structfield> should match the index storage type
- defined by the operator class's <structfield>opckeytype</structfield>
- catalog entry.
- (Note that <structfield>opckeytype</structfield> can be zero,
- implying the storage type is the same as the operator class's input
- type, which is the most common situation.)
- For reasons of backward compatibility, the <function>config</function>
- method can set <structfield>leafType</structfield> to some other value,
- and that value will be used; but this is deprecated since the index
- contents are then incorrectly identified in the catalogs.
- Also, it's permissible to
- leave <structfield>leafType</structfield> uninitialized (zero);
- that is interpreted as meaning the index storage type derived from
- <structfield>opckeytype</structfield>.
- </para>
-
- <para>
- When <structfield>attType</structfield>
- and <structfield>leafType</structfield> are different, the optional
- method <function>compress</function> must be provided.
- Method <function>compress</function> is responsible
- for transformation of datums to be indexed from <structfield>attType</structfield>
- to <structfield>leafType</structfield>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>choose</function></term>
- <listitem>
- <para>
- Chooses a method for inserting a new value into an inner tuple.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-<programlisting>
-CREATE FUNCTION my_choose(internal, internal) RETURNS void ...
-</programlisting>
- The first argument is a pointer to a <structname>spgChooseIn</structname>
- C struct, containing input data for the function.
- The second argument is a pointer to a <structname>spgChooseOut</structname>
- C struct, which the function must fill with result data.
-<programlisting>
-typedef struct spgChooseIn
-{
- Datum datum; /* original datum to be indexed */
- Datum leafDatum; /* current datum to be stored at leaf */
- int level; /* current level (counting from zero) */
-
- /* Data from current inner tuple */
- bool allTheSame; /* tuple is marked all-the-same? */
- bool hasPrefix; /* tuple has a prefix? */
- Datum prefixDatum; /* if so, the prefix value */
- int nNodes; /* number of nodes in the inner tuple */
- Datum *nodeLabels; /* node label values (NULL if none) */
-} spgChooseIn;
-
-typedef enum spgChooseResultType
-{
- spgMatchNode = 1, /* descend into existing node */
- spgAddNode, /* add a node to the inner tuple */
- spgSplitTuple /* split inner tuple (change its prefix) */
-} spgChooseResultType;
-
-typedef struct spgChooseOut
-{
- spgChooseResultType resultType; /* action code, see above */
- union
- {
- struct /* results for spgMatchNode */
- {
- int nodeN; /* descend to this node (index from 0) */
- int levelAdd; /* increment level by this much */
- Datum restDatum; /* new leaf datum */
- } matchNode;
- struct /* results for spgAddNode */
- {
- Datum nodeLabel; /* new node's label */
- int nodeN; /* where to insert it (index from 0) */
- } addNode;
- struct /* results for spgSplitTuple */
- {
- /* Info to form new upper-level inner tuple with one child tuple */
- bool prefixHasPrefix; /* tuple should have a prefix? */
- Datum prefixPrefixDatum; /* if so, its value */
- int prefixNNodes; /* number of nodes */
- Datum *prefixNodeLabels; /* their labels (or NULL for
- * no labels) */
- int childNodeN; /* which node gets child tuple */
-
- /* Info to form new lower-level inner tuple with all old nodes */
- bool postfixHasPrefix; /* tuple should have a prefix? */
- Datum postfixPrefixDatum; /* if so, its value */
- } splitTuple;
- } result;
-} spgChooseOut;
-</programlisting>
-
- <structfield>datum</structfield> is the original datum of
- <structname>spgConfigIn</structname>.<structfield>attType</structfield>
- type that was to be inserted into the index.
- <structfield>leafDatum</structfield> is a value of
- <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
- type, which is initially a result of method
- <function>compress</function> applied to <structfield>datum</structfield>
- when method <function>compress</function> is provided, or the same value as
- <structfield>datum</structfield> otherwise.
- <structfield>leafDatum</structfield> can change at lower levels of the tree
- if the <function>choose</function> or <function>picksplit</function>
- methods change it. When the insertion search reaches a leaf page,
- the current value of <structfield>leafDatum</structfield> is what will be stored
- in the newly created leaf tuple.
- <structfield>level</structfield> is the current inner tuple's level, starting at
- zero for the root level.
- <structfield>allTheSame</structfield> is true if the current inner tuple is
- marked as containing multiple equivalent nodes
- (see <xref linkend="spgist-all-the-same"/>).
- <structfield>hasPrefix</structfield> is true if the current inner tuple contains
- a prefix; if so,
- <structfield>prefixDatum</structfield> is its value.
- <structfield>nNodes</structfield> is the number of child nodes contained in the
- inner tuple, and
- <structfield>nodeLabels</structfield> is an array of their label values, or
- NULL if there are no labels.
- </para>
-
- <para>
- The <function>choose</function> function can determine either that
- the new value matches one of the existing child nodes, or that a new
- child node must be added, or that the new value is inconsistent with
- the tuple prefix and so the inner tuple must be split to create a
- less restrictive prefix.
- </para>
-
- <para>
- If the new value matches one of the existing child nodes,
- set <structfield>resultType</structfield> to <literal>spgMatchNode</literal>.
- Set <structfield>nodeN</structfield> to the index (from zero) of that node in
- the node array.
- Set <structfield>levelAdd</structfield> to the increment in
- <structfield>level</structfield> caused by descending through that node,
- or leave it as zero if the operator class does not use levels.
- Set <structfield>restDatum</structfield> to equal <structfield>leafDatum</structfield>
- if the operator class does not modify datums from one level to the
- next, or otherwise set it to the modified value to be used as
- <structfield>leafDatum</structfield> at the next level.
- </para>
-
- <para>
- If a new child node must be added,
- set <structfield>resultType</structfield> to <literal>spgAddNode</literal>.
- Set <structfield>nodeLabel</structfield> to the label to be used for the new
- node, and set <structfield>nodeN</structfield> to the index (from zero) at which
- to insert the node in the node array.
- After the node has been added, the <function>choose</function>
- function will be called again with the modified inner tuple;
- that call should result in an <literal>spgMatchNode</literal> result.
- </para>
-
- <para>
- If the new value is inconsistent with the tuple prefix,
- set <structfield>resultType</structfield> to <literal>spgSplitTuple</literal>.
- This action moves all the existing nodes into a new lower-level
- inner tuple, and replaces the existing inner tuple with a tuple
- having a single downlink pointing to the new lower-level inner tuple.
- Set <structfield>prefixHasPrefix</structfield> to indicate whether the new
- upper tuple should have a prefix, and if so set
- <structfield>prefixPrefixDatum</structfield> to the prefix value. This new
- prefix value must be sufficiently less restrictive than the original
- to accept the new value to be indexed.
- Set <structfield>prefixNNodes</structfield> to the number of nodes needed in the
- new tuple, and set <structfield>prefixNodeLabels</structfield> to a palloc'd array
- holding their labels, or to NULL if node labels are not required.
- Note that the total size of the new upper tuple must be no more
- than the total size of the tuple it is replacing; this constrains
- the lengths of the new prefix and new labels.
- Set <structfield>childNodeN</structfield> to the index (from zero) of the node
- that will downlink to the new lower-level inner tuple.
- Set <structfield>postfixHasPrefix</structfield> to indicate whether the new
- lower-level inner tuple should have a prefix, and if so set
- <structfield>postfixPrefixDatum</structfield> to the prefix value. The
- combination of these two prefixes and the downlink node's label
- (if any) must have the same meaning as the original prefix, because
- there is no opportunity to alter the node labels that are moved to
- the new lower-level tuple, nor to change any child index entries.
- After the node has been split, the <function>choose</function>
- function will be called again with the replacement inner tuple.
- That call may return an <literal>spgAddNode</literal> result, if no suitable
- node was created by the <literal>spgSplitTuple</literal> action. Eventually
- <function>choose</function> must return <literal>spgMatchNode</literal> to
- allow the insertion to descend to the next level.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>picksplit</function></term>
- <listitem>
- <para>
- Decides how to create a new inner tuple over a set of leaf tuples.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-<programlisting>
-CREATE FUNCTION my_picksplit(internal, internal) RETURNS void ...
-</programlisting>
- The first argument is a pointer to a <structname>spgPickSplitIn</structname>
- C struct, containing input data for the function.
- The second argument is a pointer to a <structname>spgPickSplitOut</structname>
- C struct, which the function must fill with result data.
-<programlisting>
-typedef struct spgPickSplitIn
-{
- int nTuples; /* number of leaf tuples */
- Datum *datums; /* their datums (array of length nTuples) */
- int level; /* current level (counting from zero) */
-} spgPickSplitIn;
-
-typedef struct spgPickSplitOut
-{
- bool hasPrefix; /* new inner tuple should have a prefix? */
- Datum prefixDatum; /* if so, its value */
-
- int nNodes; /* number of nodes for new inner tuple */
- Datum *nodeLabels; /* their labels (or NULL for no labels) */
-
- int *mapTuplesToNodes; /* node index for each leaf tuple */
- Datum *leafTupleDatums; /* datum to store in each new leaf tuple */
-} spgPickSplitOut;
-</programlisting>
-
- <structfield>nTuples</structfield> is the number of leaf tuples provided.
- <structfield>datums</structfield> is an array of their datum values of
- <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
- type.
- <structfield>level</structfield> is the current level that all the leaf tuples
- share, which will become the level of the new inner tuple.
- </para>
-
- <para>
- Set <structfield>hasPrefix</structfield> to indicate whether the new inner
- tuple should have a prefix, and if so set
- <structfield>prefixDatum</structfield> to the prefix value.
- Set <structfield>nNodes</structfield> to indicate the number of nodes that
- the new inner tuple will contain, and
- set <structfield>nodeLabels</structfield> to an array of their label values,
- or to NULL if node labels are not required.
- Set <structfield>mapTuplesToNodes</structfield> to an array that gives the index
- (from zero) of the node that each leaf tuple should be assigned to.
- Set <structfield>leafTupleDatums</structfield> to an array of the values to
- be stored in the new leaf tuples (these will be the same as the
- input <structfield>datums</structfield> if the operator class does not modify
- datums from one level to the next).
- Note that the <function>picksplit</function> function is
- responsible for palloc'ing the
- <structfield>nodeLabels</structfield>, <structfield>mapTuplesToNodes</structfield> and
- <structfield>leafTupleDatums</structfield> arrays.
- </para>
-
- <para>
- If more than one leaf tuple is supplied, it is expected that the
- <function>picksplit</function> function will classify them into more than
- one node; otherwise it is not possible to split the leaf tuples
- across multiple pages, which is the ultimate purpose of this
- operation. Therefore, if the <function>picksplit</function> function
- ends up placing all the leaf tuples in the same node, the core
- SP-GiST code will override that decision and generate an inner
- tuple in which the leaf tuples are assigned at random to several
- identically-labeled nodes. Such a tuple is marked
- <literal>allTheSame</literal> to signify that this has happened. The
- <function>choose</function> and <function>inner_consistent</function> functions
- must take suitable care with such inner tuples.
- See <xref linkend="spgist-all-the-same"/> for more information.
- </para>
-
- <para>
- <function>picksplit</function> can be applied to a single leaf tuple only
- in the case that the <function>config</function> function set
- <structfield>longValuesOK</structfield> to true and a larger-than-a-page input
- value has been supplied. In this case the point of the operation is
- to strip off a prefix and produce a new, shorter leaf datum value.
- The call will be repeated until a leaf datum short enough to fit on
- a page has been produced. See <xref linkend="spgist-limits"/> for
- more information.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>inner_consistent</function></term>
- <listitem>
- <para>
- Returns set of nodes (branches) to follow during tree search.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-<programlisting>
-CREATE FUNCTION my_inner_consistent(internal, internal) RETURNS void ...
-</programlisting>
- The first argument is a pointer to a <structname>spgInnerConsistentIn</structname>
- C struct, containing input data for the function.
- The second argument is a pointer to a <structname>spgInnerConsistentOut</structname>
- C struct, which the function must fill with result data.
-
-<programlisting>
-typedef struct spgInnerConsistentIn
-{
- ScanKey scankeys; /* array of operators and comparison values */
- ScanKey orderbys; /* array of ordering operators and comparison
- * values */
- int nkeys; /* length of scankeys array */
- int norderbys; /* length of orderbys array */
-
- Datum reconstructedValue; /* value reconstructed at parent */
- void *traversalValue; /* opclass-specific traverse value */
- MemoryContext traversalMemoryContext; /* put new traverse values here */
- int level; /* current level (counting from zero) */
- bool returnData; /* original data must be returned? */
-
- /* Data from current inner tuple */
- bool allTheSame; /* tuple is marked all-the-same? */
- bool hasPrefix; /* tuple has a prefix? */
- Datum prefixDatum; /* if so, the prefix value */
- int nNodes; /* number of nodes in the inner tuple */
- Datum *nodeLabels; /* node label values (NULL if none) */
-} spgInnerConsistentIn;
-
-typedef struct spgInnerConsistentOut
-{
- int nNodes; /* number of child nodes to be visited */
- int *nodeNumbers; /* their indexes in the node array */
- int *levelAdds; /* increment level by this much for each */
- Datum *reconstructedValues; /* associated reconstructed values */
- void **traversalValues; /* opclass-specific traverse values */
- double **distances; /* associated distances */
-} spgInnerConsistentOut;
-</programlisting>
-
- The array <structfield>scankeys</structfield>, of length <structfield>nkeys</structfield>,
- describes the index search condition(s). These conditions are
- combined with AND — only index entries that satisfy all of
- them are interesting. (Note that <structfield>nkeys</structfield> = 0 implies
- that all index entries satisfy the query.) Usually the consistent
- function only cares about the <structfield>sk_strategy</structfield> and
- <structfield>sk_argument</structfield> fields of each array entry, which
- respectively give the indexable operator and comparison value.
- In particular it is not necessary to check <structfield>sk_flags</structfield> to
- see if the comparison value is NULL, because the SP-GiST core code
- will filter out such conditions.
- The array <structfield>orderbys</structfield>, of length <structfield>norderbys</structfield>,
- describes ordering operators (if any) in the same manner.
- <structfield>reconstructedValue</structfield> is the value reconstructed for the
- parent tuple; it is <literal>(Datum) 0</literal> at the root level or if the
- <function>inner_consistent</function> function did not provide a value at the
- parent level.
- <structfield>traversalValue</structfield> is a pointer to any traverse data
- passed down from the previous call of <function>inner_consistent</function>
- on the parent index tuple, or NULL at the root level.
- <structfield>traversalMemoryContext</structfield> is the memory context in which
- to store output traverse values (see below).
- <structfield>level</structfield> is the current inner tuple's level, starting at
- zero for the root level.
- <structfield>returnData</structfield> is <literal>true</literal> if reconstructed data is
- required for this query; this will only be so if the
- <function>config</function> function asserted <structfield>canReturnData</structfield>.
- <structfield>allTheSame</structfield> is true if the current inner tuple is
- marked <quote>all-the-same</quote>; in this case all the nodes have the
- same label (if any) and so either all or none of them match the query
- (see <xref linkend="spgist-all-the-same"/>).
- <structfield>hasPrefix</structfield> is true if the current inner tuple contains
- a prefix; if so,
- <structfield>prefixDatum</structfield> is its value.
- <structfield>nNodes</structfield> is the number of child nodes contained in the
- inner tuple, and
- <structfield>nodeLabels</structfield> is an array of their label values, or
- NULL if the nodes do not have labels.
- </para>
-
- <para>
- <structfield>nNodes</structfield> must be set to the number of child nodes that
- need to be visited by the search, and
- <structfield>nodeNumbers</structfield> must be set to an array of their indexes.
- If the operator class keeps track of levels, set
- <structfield>levelAdds</structfield> to an array of the level increments
- required when descending to each node to be visited. (Often these
- increments will be the same for all the nodes, but that's not
- necessarily so, so an array is used.)
- If value reconstruction is needed, set
- <structfield>reconstructedValues</structfield> to an array of the values
- reconstructed for each child node to be visited; otherwise, leave
- <structfield>reconstructedValues</structfield> as NULL.
- The reconstructed values are assumed to be of type
- <structname>spgConfigOut</structname>.<structfield>leafType</structfield>.
- (However, since the core system will do nothing with them except
- possibly copy them, it is sufficient for them to have the
- same <literal>typlen</literal> and <literal>typbyval</literal>
- properties as <structfield>leafType</structfield>.)
- If ordered search is performed, set <structfield>distances</structfield>
- to an array of distance values according to <structfield>orderbys</structfield>
- array (nodes with lowest distances will be processed first). Leave it
- NULL otherwise.
- If it is desired to pass down additional out-of-band information
- (<quote>traverse values</quote>) to lower levels of the tree search,
- set <structfield>traversalValues</structfield> to an array of the appropriate
- traverse values, one for each child node to be visited; otherwise,
- leave <structfield>traversalValues</structfield> as NULL.
- Note that the <function>inner_consistent</function> function is
- responsible for palloc'ing the
- <structfield>nodeNumbers</structfield>, <structfield>levelAdds</structfield>,
- <structfield>distances</structfield>,
- <structfield>reconstructedValues</structfield>, and
- <structfield>traversalValues</structfield> arrays in the current memory context.
- However, any output traverse values pointed to by
- the <structfield>traversalValues</structfield> array should be allocated
- in <structfield>traversalMemoryContext</structfield>.
- Each traverse value must be a single palloc'd chunk.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>leaf_consistent</function></term>
- <listitem>
- <para>
- Returns true if a leaf tuple satisfies a query.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-<programlisting>
-CREATE FUNCTION my_leaf_consistent(internal, internal) RETURNS bool ...
-</programlisting>
- The first argument is a pointer to a <structname>spgLeafConsistentIn</structname>
- C struct, containing input data for the function.
- The second argument is a pointer to a <structname>spgLeafConsistentOut</structname>
- C struct, which the function must fill with result data.
-<programlisting>
-typedef struct spgLeafConsistentIn
-{
- ScanKey scankeys; /* array of operators and comparison values */
- ScanKey orderbys; /* array of ordering operators and comparison
- * values */
- int nkeys; /* length of scankeys array */
- int norderbys; /* length of orderbys array */
-
- Datum reconstructedValue; /* value reconstructed at parent */
- void *traversalValue; /* opclass-specific traverse value */
- int level; /* current level (counting from zero) */
- bool returnData; /* original data must be returned? */
-
- Datum leafDatum; /* datum in leaf tuple */
-} spgLeafConsistentIn;
-
-typedef struct spgLeafConsistentOut
-{
- Datum leafValue; /* reconstructed original data, if any */
- bool recheck; /* set true if operator must be rechecked */
- bool recheckDistances; /* set true if distances must be rechecked */
- double *distances; /* associated distances */
-} spgLeafConsistentOut;
-</programlisting>
-
- The array <structfield>scankeys</structfield>, of length <structfield>nkeys</structfield>,
- describes the index search condition(s). These conditions are
- combined with AND — only index entries that satisfy all of
- them satisfy the query. (Note that <structfield>nkeys</structfield> = 0 implies
- that all index entries satisfy the query.) Usually the consistent
- function only cares about the <structfield>sk_strategy</structfield> and
- <structfield>sk_argument</structfield> fields of each array entry, which
- respectively give the indexable operator and comparison value.
- In particular it is not necessary to check <structfield>sk_flags</structfield> to
- see if the comparison value is NULL, because the SP-GiST core code
- will filter out such conditions.
- The array <structfield>orderbys</structfield>, of length <structfield>norderbys</structfield>,
- describes the ordering operators in the same manner.
- <structfield>reconstructedValue</structfield> is the value reconstructed for the
- parent tuple; it is <literal>(Datum) 0</literal> at the root level or if the
- <function>inner_consistent</function> function did not provide a value at the
- parent level.
- <structfield>traversalValue</structfield> is a pointer to any traverse data
- passed down from the previous call of <function>inner_consistent</function>
- on the parent index tuple, or NULL at the root level.
- <structfield>level</structfield> is the current leaf tuple's level, starting at
- zero for the root level.
- <structfield>returnData</structfield> is <literal>true</literal> if reconstructed data is
- required for this query; this will only be so if the
- <function>config</function> function asserted <structfield>canReturnData</structfield>.
- <structfield>leafDatum</structfield> is the key value of
- <structname>spgConfigOut</structname>.<structfield>leafType</structfield>
- stored in the current leaf tuple.
- </para>
-
- <para>
- The function must return <literal>true</literal> if the leaf tuple matches the
- query, or <literal>false</literal> if not. In the <literal>true</literal> case,
- if <structfield>returnData</structfield> is <literal>true</literal> then
- <structfield>leafValue</structfield> must be set to the value (of type
- <structname>spgConfigIn</structname>.<structfield>attType</structfield>)
- originally supplied to be indexed for this leaf tuple. Also,
- <structfield>recheck</structfield> may be set to <literal>true</literal> if the match
- is uncertain and so the operator(s) must be re-applied to the actual
- heap tuple to verify the match.
- If ordered search is performed, set <structfield>distances</structfield>
- to an array of distance values according to <structfield>orderbys</structfield>
- array. Leave it NULL otherwise. If at least one of returned distances
- is not exact, set <structfield>recheckDistances</structfield> to true.
- In this case, the executor will calculate the exact distances after
- fetching the tuple from the heap, and will reorder the tuples if needed.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- The optional user-defined methods are:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><function>Datum compress(Datum in)</function></term>
- <listitem>
- <para>
- Converts a data item into a format suitable for physical storage in
- a leaf tuple of the index. It accepts a value of type
- <structname>spgConfigIn</structname>.<structfield>attType</structfield>
- and returns a value of type
- <structname>spgConfigOut</structname>.<structfield>leafType</structfield>.
- The output value must not contain an out-of-line TOAST pointer.
- </para>
-
- <para>
- Note: the <function>compress</function> method is only applied to
- values to be stored. The consistent methods receive query
- <structfield>scankeys</structfield> unchanged, without transformation
- using <function>compress</function>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><function>options</function></term>
- <listitem>
- <para>
- Defines a set of user-visible parameters that control operator class
- behavior.
- </para>
-
- <para>
- The <acronym>SQL</acronym> declaration of the function must look like this:
-
-<programlisting>
-CREATE OR REPLACE FUNCTION my_options(internal)
-RETURNS void
-AS 'MODULE_PATHNAME'
-LANGUAGE C STRICT;
-</programlisting>
- </para>
-
- <para>
- The function is passed a pointer to a <structname>local_relopts</structname>
- struct, which needs to be filled with a set of operator class
- specific options. The options can be accessed from other support
- functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
- <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
- </para>
-
- <para>
- Since the representation of the key in <acronym>SP-GiST</acronym> is
- flexible, it may depend on user-specified parameters.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- All the SP-GiST support methods are normally called in a short-lived
- memory context; that is, <varname>CurrentMemoryContext</varname> will be reset
- after processing of each tuple. It is therefore not very important to
- worry about pfree'ing everything you palloc. (The <function>config</function>
- method is an exception: it should try to avoid leaking memory. But
- usually the <function>config</function> method need do nothing but assign
- constants into the passed parameter struct.)
- </para>
-
- <para>
- If the indexed column is of a collatable data type, the index collation
- will be passed to all the support methods, using the standard
- <function>PG_GET_COLLATION()</function> mechanism.
- </para>
-
-</sect1>
-
-<sect1 id="spgist-implementation">
- <title>Implementation</title>
-
- <para>
- This section covers implementation details and other tricks that are
- useful for implementers of <acronym>SP-GiST</acronym> operator classes to
- know.
- </para>
-
- <sect2 id="spgist-limits">
- <title>SP-GiST Limits</title>
-
- <para>
- Individual leaf tuples and inner tuples must fit on a single index page
- (8kB by default). Therefore, when indexing values of variable-length
- data types, long values can only be supported by methods such as radix
- trees, in which each level of the tree includes a prefix that is short
- enough to fit on a page, and the final leaf level includes a suffix also
- short enough to fit on a page. The operator class should set
- <structfield>longValuesOK</structfield> to true only if it is prepared to arrange for
- this to happen. Otherwise, the <acronym>SP-GiST</acronym> core will
- reject any request to index a value that is too large to fit
- on an index page.
- </para>
-
- <para>
- Likewise, it is the operator class's responsibility that inner tuples
- do not grow too large to fit on an index page; this limits the number
- of child nodes that can be used in one inner tuple, as well as the
- maximum size of a prefix value.
- </para>
-
- <para>
- Another limitation is that when an inner tuple's node points to a set
- of leaf tuples, those tuples must all be in the same index page.
- (This is a design decision to reduce seeking and save space in the
- links that chain such tuples together.) If the set of leaf tuples
- grows too large for a page, a split is performed and an intermediate
- inner tuple is inserted. For this to fix the problem, the new inner
- tuple <emphasis>must</emphasis> divide the set of leaf values into more than one
- node group. If the operator class's <function>picksplit</function> function
- fails to do that, the <acronym>SP-GiST</acronym> core resorts to
- extraordinary measures described in <xref linkend="spgist-all-the-same"/>.
- </para>
-
- <para>
- When <structfield>longValuesOK</structfield> is true, it is expected
- that successive levels of the <acronym>SP-GiST</acronym> tree will
- absorb more and more information into the prefixes and node labels of
- the inner tuples, making the required leaf datum smaller and smaller,
- so that eventually it will fit on a page.
- To prevent bugs in operator classes from causing infinite insertion
- loops, the <acronym>SP-GiST</acronym> core will raise an error if the
- leaf datum does not become any smaller within ten cycles
- of <function>choose</function> method calls.
- </para>
- </sect2>
-
- <sect2 id="spgist-null-labels">
- <title>SP-GiST Without Node Labels</title>
-
- <para>
- Some tree algorithms use a fixed set of nodes for each inner tuple;
- for example, in a quad-tree there are always exactly four nodes
- corresponding to the four quadrants around the inner tuple's centroid
- point. In such a case the code typically works with the nodes by
- number, and there is no need for explicit node labels. To suppress
- node labels (and thereby save some space), the <function>picksplit</function>
- function can return NULL for the <structfield>nodeLabels</structfield> array,
- and likewise the <function>choose</function> function can return NULL for
- the <structfield>prefixNodeLabels</structfield> array during
- a <literal>spgSplitTuple</literal> action.
- This will in turn result in <structfield>nodeLabels</structfield> being NULL during
- subsequent calls to <function>choose</function> and <function>inner_consistent</function>.
- In principle, node labels could be used for some inner tuples and omitted
- for others in the same index.
- </para>
-
- <para>
- When working with an inner tuple having unlabeled nodes, it is an error
- for <function>choose</function> to return <literal>spgAddNode</literal>, since the set
- of nodes is supposed to be fixed in such cases.
- </para>
- </sect2>
-
- <sect2 id="spgist-all-the-same">
- <title><quote>All-the-Same</quote> Inner Tuples</title>
-
- <para>
- The <acronym>SP-GiST</acronym> core can override the results of the
- operator class's <function>picksplit</function> function when
- <function>picksplit</function> fails to divide the supplied leaf values into
- at least two node categories. When this happens, the new inner tuple
- is created with multiple nodes that each have the same label (if any)
- that <function>picksplit</function> gave to the one node it did use, and the
- leaf values are divided at random among these equivalent nodes.
- The <literal>allTheSame</literal> flag is set on the inner tuple to warn the
- <function>choose</function> and <function>inner_consistent</function> functions that the
- tuple does not have the node set that they might otherwise expect.
- </para>
-
- <para>
- When dealing with an <literal>allTheSame</literal> tuple, a <function>choose</function>
- result of <literal>spgMatchNode</literal> is interpreted to mean that the new
- value can be assigned to any of the equivalent nodes; the core code will
- ignore the supplied <structfield>nodeN</structfield> value and descend into one
- of the nodes at random (so as to keep the tree balanced). It is an
- error for <function>choose</function> to return <literal>spgAddNode</literal>, since
- that would make the nodes not all equivalent; the
- <literal>spgSplitTuple</literal> action must be used if the value to be inserted
- doesn't match the existing nodes.
- </para>
-
- <para>
- When dealing with an <literal>allTheSame</literal> tuple, the
- <function>inner_consistent</function> function should return either all or none
- of the nodes as targets for continuing the index search, since they are
- all equivalent. This may or may not require any special-case code,
- depending on how much the <function>inner_consistent</function> function normally
- assumes about the meaning of the nodes.
- </para>
- </sect2>
-
-</sect1>
-
-<sect1 id="spgist-examples">
- <title>Examples</title>
-
- <para>
- The <productname>PostgreSQL</productname> source distribution includes
- several examples of index operator classes for <acronym>SP-GiST</acronym>,
- as described in <xref linkend="spgist-builtin-opclasses-table"/>. Look
- into <filename>src/backend/access/spgist/</filename>
- and <filename>src/backend/utils/adt/</filename> to see the code.
- </para>
-
-</sect1>
-
-</chapter>
--
2.39.3 (Apple Git-145)
Re: documentation structure
On Wed, Mar 20, 2024 at 12:43:08PM -0400, Robert Haas wrote:
Overall, I think this achieves a minor but pleasant level of
de-cluttering of the index. It's going to take a lot more than one
morning's work to produce a major improvement, but at least this is
something.
I think this kind of doc structure review is long overdue.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
On Wed, Mar 20, 2024 at 1:35 PM Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Mar 20, 2024 at 12:43:08PM -0400, Robert Haas wrote:
Overall, I think this achieves a minor but pleasant level of
de-cluttering of the index. It's going to take a lot more than one
morning's work to produce a major improvement, but at least this is
something.I think this kind of doc structure review is long overdue.
Thanks, Bruce!
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On 2024-Mar-20, Robert Haas wrote:
0003 merges all of the "Internals" chapters whose names are the names
of built-in index access methods (Btree, Gin, etc.) into a single
chapter called "Built-In Index Access Methods". All of these chapters
have a very similar structure and none of them are very long, so it
makes a lot of sense, at least in my mind, to consolidate them into
one.
I think you can achieve this with a much smaller patch that just changes
the outer tag in each file so that each file is a <sect1>, then create a
single file that includes all of these plus an additional outer tag for
the <chapter> (or maybe just add the <chapter> in postgres.sgml). This
has the advantage that each AM continues to be a separate single file,
and you still have your desired structure.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Re: documentation structure
On Wed, Mar 20, 2024 at 5:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
I think you can achieve this with a much smaller patch that just changes
the outer tag in each file so that each file is a <sect1>, then create a
single file that includes all of these plus an additional outer tag for
the <chapter> (or maybe just add the <chapter> in postgres.sgml). This
has the advantage that each AM continues to be a separate single file,
and you still have your desired structure.
Right, that could also be done, and not just for 0003. I just wasn't
sure that was the right approach. It would mean that the division of
the SGML into files continues to reflect the original chapter
divisions rather than the current ones forever. In the short run
that's less churn, less back-patching pain, etc.; but in the long term
it means you've got relics of a structure that doesn't exist any more
sticking around forever.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Mar 20, 2024 at 5:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
I think you can achieve this with a much smaller patch that just changes
the outer tag in each file so that each file is a <sect1>, then create a
single file that includes all of these plus an additional outer tag for
the <chapter> (or maybe just add the <chapter> in postgres.sgml). This
has the advantage that each AM continues to be a separate single file,
and you still have your desired structure.
Right, that could also be done, and not just for 0003. I just wasn't
sure that was the right approach. It would mean that the division of
the SGML into files continues to reflect the original chapter
divisions rather than the current ones forever. In the short run
that's less churn, less back-patching pain, etc.; but in the long term
it means you've got relics of a structure that doesn't exist any more
sticking around forever.
I'd say that a separate file per AM is a good thing regardless.
Elsewhere in this same thread are grumblings about how big func.sgml
is; why would you think it good to start down that same path for the
AM documentation?
regards, tom lane
Re: documentation structure
On Wed, Mar 20, 2024 at 5:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'd say that a separate file per AM is a good thing regardless.
Elsewhere in this same thread are grumblings about how big func.sgml
is; why would you think it good to start down that same path for the
AM documentation?
Well, I suppose I thought it was a good idea because (1) we don't seem
to have any existing precedent for file-per-sect1 rather than
file-per-chapter and (2) all of the per-AM files combined are less
than 20% of the size of func.sgml.
But, OK, if you want to establish a new paradigm here, sure. I see two
ways to do it. We can either put the <chapter> tag directly in
postgres.sgml, or I can still create a new indextypes.sgml and put
&btree; etc. inside of it. Which way do you prefer?
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
Robert Haas <robertmhaas@gmail.com> writes:
Well, I suppose I thought it was a good idea because (1) we don't seem
to have any existing precedent for file-per-sect1 rather than
file-per-chapter and (2) all of the per-AM files combined are less
than 20% of the size of func.sgml.
We have done (1) in places, eg. json.sgml, array.sgml,
rangetypes.sgml, rowtypes.sgml, and the bulk of extend.sgml is split
out into xaggr, xfunc, xindex, xoper, xtypes. I'd be the first to
concede it's a bit haphazard, but it's not like there's no precedent.
As for (2), func.sgml likely should have been split years ago.
But, OK, if you want to establish a new paradigm here, sure. I see two
ways to do it. We can either put the <chapter> tag directly in
postgres.sgml, or I can still create a new indextypes.sgml and put
&btree; etc. inside of it. Which way do you prefer?
I'd follow the extend.sgml precedent: have a file corresponding to the
chapter and containing any top-level text we need, then that includes
a file per sect1.
regards, tom lane
Re: documentation structure
On Thu, Mar 21, 2024 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'd follow the extend.sgml precedent: have a file corresponding to the
chapter and containing any top-level text we need, then that includes
a file per sect1.
OK, here's a new patch set. I've revised 0003 and 0004 to use this
approach, and I've added a new 0005 that does essentially the same
thing for the PL chapters.
0001 and 0002 are changed. Should 0002 use the include-an-entity
approach as well?
--
Robert Haas
EDB: http://www.enterprisedb.com
Attachments:
v2-0004-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchapplication/octet-stream; name=v2-0004-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchDownload
From bee277b6fda299e510beacf47db10493ef689f76 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 12:12:48 -0400
Subject: [PATCH v2 4/5] docs: Consolidate into new "WAL for Extensions"
chapter.
Previously, we had consecutive, very short chapters called "Generic
WAL" and "Custom WAL Resource Managers," explaining different approaches
to the same problem. Merge them into a single chapter.
Rather than actually combining all of the SGML into a single file,
keep one file per <sect1>, and add a glue file that includes all
of them.
---
doc/src/sgml/custom-rmgr.sgml | 4 ++--
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/generic-wal.sgml | 4 ++--
doc/src/sgml/postgres.sgml | 3 +--
doc/src/sgml/wal-for-extensions.sgml | 9 +++++++++
5 files changed, 15 insertions(+), 6 deletions(-)
create mode 100644 doc/src/sgml/wal-for-extensions.sgml
diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
index 0d98229295..13a5a6a5b1 100644
--- a/doc/src/sgml/custom-rmgr.sgml
+++ b/doc/src/sgml/custom-rmgr.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/custom-rmgr.sgml -->
-<chapter id="custom-rmgr">
+<sect1 id="custom-rmgr">
<title>Custom WAL Resource Managers</title>
<para>
@@ -102,4 +102,4 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
the custom WAL records, which may prevent the server from starting.
</para>
</note>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index b5615e1fce..1bb662c16f 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -106,6 +106,7 @@
<!ENTITY storage SYSTEM "storage.sgml">
<!ENTITY transaction SYSTEM "xact.sgml">
<!ENTITY tablesample-method SYSTEM "tablesample-method.sgml">
+<!ENTITY wal-for-extensions SYSTEM "wal-for-extensions.sgml">
<!ENTITY generic-wal SYSTEM "generic-wal.sgml">
<!ENTITY custom-rmgr SYSTEM "custom-rmgr.sgml">
<!ENTITY backup-manifest SYSTEM "backup-manifest.sgml">
diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml
index a028856d2e..ba00ddf100 100644
--- a/doc/src/sgml/generic-wal.sgml
+++ b/doc/src/sgml/generic-wal.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/generic-wal.sgml -->
-<chapter id="generic-wal">
+<sect1 id="generic-wal">
<title>Generic WAL Records</title>
<para>
@@ -171,4 +171,4 @@
</listitem>
</itemizedlist>
</para>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 0235c0e352..5bc47a9e71 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -255,8 +255,7 @@ break is not needed in a wider output rendering.
&geqo;
&tableam;
&indexam;
- &generic-wal;
- &custom-rmgr;
+ &wal-for-extensions;
&indextypes;
&storage;
&transaction;
diff --git a/doc/src/sgml/wal-for-extensions.sgml b/doc/src/sgml/wal-for-extensions.sgml
new file mode 100644
index 0000000000..fbebafb5a9
--- /dev/null
+++ b/doc/src/sgml/wal-for-extensions.sgml
@@ -0,0 +1,9 @@
+<!-- doc/src/sgml/wal-for-extensions.sgml -->
+
+<chapter id="wal-for-extensions">
+ <title>Write Ahead Logging for Extensions</title>
+
+&generic-wal;
+&custom-rmgr;
+
+</chapter>
--
2.39.3 (Apple Git-145)
v2-0002-docs-Demote-Monitoring-Disk-Usage-from-chapter-to.patchapplication/octet-stream; name=v2-0002-docs-Demote-Monitoring-Disk-Usage-from-chapter-to.patchDownload
From adce7677286f48a6971251758b9a78877db1895a Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 10:52:16 -0400
Subject: [PATCH v2 2/5] docs: Demote "Monitoring Disk Usage" from chapter to
section.
This chapter is very short, and the immediately preceding chapter is
called "Monitoring Database Activity". So, instead of having a
separate chapter for this, make it the last section of the preceding
chapter instead.
---
doc/src/sgml/diskusage.sgml | 144 -----------------------------------
doc/src/sgml/filelist.sgml | 1 -
doc/src/sgml/monitoring.sgml | 143 ++++++++++++++++++++++++++++++++++
doc/src/sgml/postgres.sgml | 1 -
4 files changed, 143 insertions(+), 146 deletions(-)
delete mode 100644 doc/src/sgml/diskusage.sgml
diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
deleted file mode 100644
index 75467582e4..0000000000
--- a/doc/src/sgml/diskusage.sgml
+++ /dev/null
@@ -1,144 +0,0 @@
-<!-- doc/src/sgml/diskusage.sgml -->
-
-<chapter id="diskusage">
- <title>Monitoring Disk Usage</title>
-
- <para>
- This chapter discusses how to monitor the disk usage of a
- <productname>PostgreSQL</productname> database system.
- </para>
-
- <sect1 id="disk-usage">
- <title>Determining Disk Usage</title>
-
- <indexterm zone="disk-usage">
- <primary>disk usage</primary>
- </indexterm>
-
- <para>
- Each table has a primary heap disk file where most of the data is
- stored. If the table has any columns with potentially-wide values,
- there also might be a <acronym>TOAST</acronym> file associated with the table,
- which is used to store values too wide to fit comfortably in the main
- table (see <xref linkend="storage-toast"/>). There will be one valid index
- on the <acronym>TOAST</acronym> table, if present. There also might be indexes
- associated with the base table. Each table and index is stored in a
- separate disk file — possibly more than one file, if the file would
- exceed one gigabyte. Naming conventions for these files are described
- in <xref linkend="storage-file-layout"/>.
- </para>
-
- <para>
- You can monitor disk space in three ways:
- using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
- using the <xref linkend="oid2name"/> module, or
- using manual inspection of the system catalogs.
- The SQL functions are the easiest to use and are generally recommended.
- The remainder of this section shows how to do it by inspection of the
- system catalogs.
- </para>
-
- <para>
- Using <application>psql</application> on a recently vacuumed or analyzed database,
- you can issue queries to see the disk usage of any table:
-<programlisting>
-SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
-
- pg_relation_filepath | relpages
-----------------------+----------
- base/16384/16806 | 60
-(1 row)
-</programlisting>
- Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
- is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
- a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
- is of interest if you want to examine the table's disk file directly.
- </para>
-
- <para>
- To show the space used by <acronym>TOAST</acronym> tables, use a query
- like the following:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class,
- (SELECT reltoastrelid
- FROM pg_class
- WHERE relname = 'customer') AS ss
-WHERE oid = ss.reltoastrelid OR
- oid = (SELECT indexrelid
- FROM pg_index
- WHERE indrelid = ss.reltoastrelid)
-ORDER BY relname;
-
- relname | relpages
-----------------------+----------
- pg_toast_16806 | 0
- pg_toast_16806_index | 1
-</programlisting>
- </para>
-
- <para>
- You can easily display index sizes, too:
-<programlisting>
-SELECT c2.relname, c2.relpages
-FROM pg_class c, pg_class c2, pg_index i
-WHERE c.relname = 'customer' AND
- c.oid = i.indrelid AND
- c2.oid = i.indexrelid
-ORDER BY c2.relname;
-
- relname | relpages
--------------------+----------
- customer_id_index | 26
-</programlisting>
- </para>
-
- <para>
- It is easy to find your largest tables and indexes using this
- information:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class
-ORDER BY relpages DESC;
-
- relname | relpages
-----------------------+----------
- bigtable | 3290
- customer | 3144
-</programlisting>
- </para>
- </sect1>
-
- <sect1 id="disk-full">
- <title>Disk Full Failure</title>
-
- <para>
- The most important disk monitoring task of a database administrator
- is to make sure the disk doesn't become full. A filled data disk will
- not result in data corruption, but it might prevent useful activity
- from occurring. If the disk holding the WAL files grows full, database
- server panic and consequent shutdown might occur.
- </para>
-
- <para>
- If you cannot free up additional space on the disk by deleting
- other things, you can move some of the database files to other file
- systems by making use of tablespaces. See <xref
- linkend="manage-ag-tablespaces"/> for more information about that.
- </para>
-
- <tip>
- <para>
- Some file systems perform badly when they are almost full, so do
- not wait until the disk is completely full to take action.
- </para>
- </tip>
-
- <para>
- If your system supports per-user disk quotas, then the database
- will naturally be subject to whatever quota is placed on the user
- the server runs as. Exceeding the quota will have the same bad
- effects as running out of disk space entirely.
- </para>
- </sect1>
-</chapter>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index b7d1222e3e..f39b4efe38 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -34,7 +34,6 @@
<!ENTITY backup SYSTEM "backup.sgml">
<!ENTITY charset SYSTEM "charset.sgml">
<!ENTITY client-auth SYSTEM "client-auth.sgml">
-<!ENTITY diskusage SYSTEM "diskusage.sgml">
<!ENTITY high-availability SYSTEM "high-availability.sgml">
<!ENTITY installation SYSTEM "installation.sgml">
<!ENTITY targets-meson SYSTEM "targets-meson.sgml">
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 8736eac284..eda54b4985 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -7282,4 +7282,147 @@ if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
</sect1>
+ <sect1 id="diskusage">
+ <title>Monitoring Disk Usage</title>
+
+ <para>
+ This section discusses how to monitor the disk usage of a
+ <productname>PostgreSQL</productname> database system.
+ </para>
+
+ <sect2 id="disk-usage">
+ <title>Determining Disk Usage</title>
+
+ <indexterm zone="disk-usage">
+ <primary>disk usage</primary>
+ </indexterm>
+
+ <para>
+ Each table has a primary heap disk file where most of the data is
+ stored. If the table has any columns with potentially-wide values,
+ there also might be a <acronym>TOAST</acronym> file associated with the table,
+ which is used to store values too wide to fit comfortably in the main
+ table (see <xref linkend="storage-toast"/>). There will be one valid index
+ on the <acronym>TOAST</acronym> table, if present. There also might be indexes
+ associated with the base table. Each table and index is stored in a
+ separate disk file — possibly more than one file, if the file would
+ exceed one gigabyte. Naming conventions for these files are described
+ in <xref linkend="storage-file-layout"/>.
+ </para>
+
+ <para>
+ You can monitor disk space in three ways:
+ using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
+ using the <xref linkend="oid2name"/> module, or
+ using manual inspection of the system catalogs.
+ The SQL functions are the easiest to use and are generally recommended.
+ The remainder of this section shows how to do it by inspection of the
+ system catalogs.
+ </para>
+
+ <para>
+ Using <application>psql</application> on a recently vacuumed or analyzed
+ database, you can issue queries to see the disk usage of any table:
+<programlisting>
+SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
+
+ pg_relation_filepath | relpages
+----------------------+----------
+ base/16384/16806 | 60
+(1 row)
+</programlisting>
+ Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
+ is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
+ a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
+ is of interest if you want to examine the table's disk file directly.
+ </para>
+
+ <para>
+ To show the space used by <acronym>TOAST</acronym> tables, use a query
+ like the following:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class,
+ (SELECT reltoastrelid
+ FROM pg_class
+ WHERE relname = 'customer') AS ss
+WHERE oid = ss.reltoastrelid OR
+ oid = (SELECT indexrelid
+ FROM pg_index
+ WHERE indrelid = ss.reltoastrelid)
+ORDER BY relname;
+
+ relname | relpages
+----------------------+----------
+ pg_toast_16806 | 0
+ pg_toast_16806_index | 1
+</programlisting>
+ </para>
+
+ <para>
+ You can easily display index sizes, too:
+<programlisting>
+SELECT c2.relname, c2.relpages
+FROM pg_class c, pg_class c2, pg_index i
+WHERE c.relname = 'customer' AND
+ c.oid = i.indrelid AND
+ c2.oid = i.indexrelid
+ORDER BY c2.relname;
+
+ relname | relpages
+-------------------+----------
+ customer_id_index | 26
+</programlisting>
+ </para>
+
+ <para>
+ It is easy to find your largest tables and indexes using this
+ information:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class
+ORDER BY relpages DESC;
+
+ relname | relpages
+----------------------+----------
+ bigtable | 3290
+ customer | 3144
+</programlisting>
+ </para>
+ </sect2>
+
+ <sect2 id="disk-full">
+ <title>Disk Full Failure</title>
+
+ <para>
+ The most important disk monitoring task of a database administrator
+ is to make sure the disk doesn't become full. A filled data disk will
+ not result in data corruption, but it might prevent useful activity
+ from occurring. If the disk holding the WAL files grows full, database
+ server panic and consequent shutdown might occur.
+ </para>
+
+ <para>
+ If you cannot free up additional space on the disk by deleting
+ other things, you can move some of the database files to other file
+ systems by making use of tablespaces. See <xref
+ linkend="manage-ag-tablespaces"/> for more information about that.
+ </para>
+
+ <tip>
+ <para>
+ Some file systems perform badly when they are almost full, so do
+ not wait until the disk is completely full to take action.
+ </para>
+ </tip>
+
+ <para>
+ If your system supports per-user disk quotas, then the database
+ will naturally be subject to whatever quota is placed on the user
+ the server runs as. Exceeding the quota will have the same bad
+ effects as running out of disk space entirely.
+ </para>
+ </sect2>
+ </sect1>
+
</chapter>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 7c234ff1db..73b497bcf8 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -161,7 +161,6 @@ break is not needed in a wider output rendering.
&backup;
&high-availability;
&monitoring;
- &diskusage;
&wal;
&logical-replication;
&jit;
--
2.39.3 (Apple Git-145)
v2-0003-docs-Merge-separate-chapters-on-built-in-index-AM.patchapplication/octet-stream; name=v2-0003-docs-Merge-separate-chapters-on-built-in-index-AM.patchDownload
From bca9818514d801df1b83fa1d022b6f1d61deafd8 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 11:51:53 -0400
Subject: [PATCH v2 3/5] docs: Merge separate chapters on built-in index AMs
into one.
The documetation index is getting very long, which makes it hard
to find things. Since these chapters are all very similar in structure
and content, merging them is a natural way of reducing the size of
the toplevel index.
Rather than actually combining all of the SGML into a single file,
keep one file per <sect1>, and add a glue file that includes all
of them.
---
doc/src/sgml/brin.sgml | 22 ++++++++++----------
doc/src/sgml/btree.sgml | 32 ++++++++++++++---------------
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/gin.sgml | 40 ++++++++++++++++++------------------
doc/src/sgml/gist.sgml | 28 ++++++++++++-------------
doc/src/sgml/hash.sgml | 12 +++++------
doc/src/sgml/indextypes.sgml | 13 ++++++++++++
doc/src/sgml/postgres.sgml | 7 +------
doc/src/sgml/spgist.sgml | 36 ++++++++++++++++----------------
9 files changed, 100 insertions(+), 91 deletions(-)
create mode 100644 doc/src/sgml/indextypes.sgml
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index d898cc4720..64fb520db7 100644
--- a/doc/src/sgml/brin.sgml
+++ b/doc/src/sgml/brin.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/brin.sgml -->
-<chapter id="brin">
+<sect1 id="brin">
<title>BRIN Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>BRIN</secondary>
</indexterm>
-<sect1 id="brin-intro">
+<sect2 id="brin-intro">
<title>Introduction</title>
<para>
@@ -64,7 +64,7 @@
be more precise and more data blocks can be skipped during an index scan.
</para>
- <sect2 id="brin-operation">
+ <sect3 id="brin-operation">
<title>Index Maintenance</title>
<para>
@@ -136,10 +136,10 @@ LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was
See <xref linkend="functions-admin-index"/> for details.
</para>
- </sect2>
-</sect1>
+ </sect3>
+</sect2>
-<sect1 id="brin-builtin-opclasses">
+<sect2 id="brin-builtin-opclasses">
<title>Built-in Operator Classes</title>
<para>
@@ -743,7 +743,7 @@ LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was
</tgroup>
</table>
- <sect2 id="brin-builtin-opclasses--parameters">
+ <sect3 id="brin-builtin-opclasses--parameters">
<title>Operator Class Parameters</title>
<para>
@@ -808,11 +808,11 @@ LOG: request for BRIN range summarization for index "brin_wi_idx" page 128 was
</varlistentry>
</variablelist>
- </sect2>
+ </sect3>
-</sect1>
+</sect2>
-<sect1 id="brin-extensibility">
+<sect2 id="brin-extensibility">
<title>Extensibility</title>
<para>
@@ -1340,5 +1340,5 @@ typedef struct BrinOpcInfo
<literal>float4_minmax_ops</literal> as an example of minmax, and
<literal>box_inclusion_ops</literal> as an example of inclusion.
</para>
+</sect2>
</sect1>
-</chapter>
diff --git a/doc/src/sgml/btree.sgml b/doc/src/sgml/btree.sgml
index be8210286b..2b3997988c 100644
--- a/doc/src/sgml/btree.sgml
+++ b/doc/src/sgml/btree.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/btree.sgml -->
-<chapter id="btree">
+<sect1 id="btree">
<title>B-Tree Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>B-Tree</secondary>
</indexterm>
-<sect1 id="btree-intro">
+<sect2 id="btree-intro">
<title>Introduction</title>
<para>
@@ -30,9 +30,9 @@
btree <acronym>AM</acronym> make use of them.
</para>
-</sect1>
+</sect2>
-<sect1 id="btree-behavior">
+<sect2 id="btree-behavior">
<title>Behavior of B-Tree Operator Classes</title>
<para>
@@ -200,9 +200,9 @@
planner relies on them for optimization purposes.
</para>
-</sect1>
+</sect2>
-<sect1 id="btree-support-funcs">
+<sect2 id="btree-support-funcs">
<title>B-Tree Support Functions</title>
<para>
@@ -585,9 +585,9 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
</varlistentry>
</variablelist>
-</sect1>
+</sect2>
-<sect1 id="btree-implementation">
+<sect2 id="btree-implementation">
<title>Implementation</title>
<para>
@@ -597,7 +597,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
distribution for a much more detailed, internals-focused description
of the B-Tree implementation.
</para>
- <sect2 id="btree-structure">
+ <sect3 id="btree-structure">
<title>B-Tree Structure</title>
<para>
<productname>PostgreSQL</productname> B-Tree indexes are
@@ -627,9 +627,9 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
the tree structure by creating a new root page that is one level
above the original root page.
</para>
- </sect2>
+ </sect3>
- <sect2 id="btree-deletion">
+ <sect3 id="btree-deletion">
<title>Bottom-up Index Deletion</title>
<para>
B-Tree indexes are not directly aware that under MVCC, there might
@@ -731,9 +731,9 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
two logical rows whose lifetimes span the same
<command>VACUUM</command> cycle).
</para>
- </sect2>
+ </sect3>
- <sect2 id="btree-deduplication">
+ <sect3 id="btree-deduplication">
<title>Deduplication</title>
<para>
A duplicate is a leaf page tuple (a tuple that points to a table
@@ -908,7 +908,7 @@ options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns
</itemizedlist>
</para>
- </sect2>
-</sect1>
+ </sect3>
+</sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index f39b4efe38..b5615e1fce 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -84,6 +84,7 @@
<!ENTITY catalogs SYSTEM "catalogs.sgml">
<!ENTITY system-views SYSTEM "system-views.sgml">
<!ENTITY geqo SYSTEM "geqo.sgml">
+<!ENTITY indextypes SYSTEM "indextypes.sgml">
<!ENTITY btree SYSTEM "btree.sgml">
<!ENTITY gist SYSTEM "gist.sgml">
<!ENTITY spgist SYSTEM "spgist.sgml">
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index 5bd1efae92..46e87e0132 100644
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/gin.sgml -->
-<chapter id="gin">
+<sect1 id="gin">
<title>GIN Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>GIN</secondary>
</indexterm>
-<sect1 id="gin-intro">
+<sect2 id="gin-intro">
<title>Introduction</title>
<para>
@@ -60,9 +60,9 @@
information about <acronym>GIN</acronym> on their
<ulink url="http://www.sai.msu.su/~megera/wiki/Gin">website</ulink>.
</para>
-</sect1>
+</sect2>
-<sect1 id="gin-builtin-opclasses">
+<sect2 id="gin-builtin-opclasses">
<title>Built-in Operator Classes</title>
<para>
@@ -140,9 +140,9 @@
See <xref linkend="json-indexing"/> for details.
</para>
-</sect1>
+</sect2>
-<sect1 id="gin-extensibility">
+<sect2 id="gin-extensibility">
<title>Extensibility</title>
<para>
@@ -458,9 +458,9 @@
though the actual type might be something else depending on the operator.
</para>
-</sect1>
+</sect2>
-<sect1 id="gin-implementation">
+<sect2 id="gin-implementation">
<title>Implementation</title>
<para>
@@ -497,7 +497,7 @@
</mediaobject>
</figure>
- <sect2 id="gin-fast-update">
+ <sect3 id="gin-fast-update">
<title>GIN Fast Update Technique</title>
<para>
@@ -535,9 +535,9 @@
<acronym>GIN</acronym> index. See <xref linkend="sql-createindex"/>
for details.
</para>
- </sect2>
+ </sect3>
- <sect2 id="gin-partial-match">
+ <sect3 id="gin-partial-match">
<title>Partial Match Algorithm</title>
<para>
@@ -554,11 +554,11 @@
to be searched, or greater than zero if the index key is past the range
that could match.
</para>
- </sect2>
+ </sect3>
-</sect1>
+</sect2>
-<sect1 id="gin-tips">
+<sect2 id="gin-tips">
<title>GIN Tips and Tricks</title>
<variablelist>
@@ -653,9 +653,9 @@
</varlistentry>
</variablelist>
-</sect1>
+</sect2>
-<sect1 id="gin-limit">
+<sect2 id="gin-limit">
<title>Limitations</title>
<para>
@@ -667,9 +667,9 @@
however that null key values contained within a non-null composite item
or query value are supported.
</para>
-</sect1>
+</sect2>
-<sect1 id="gin-examples">
+<sect2 id="gin-examples">
<title>Examples</title>
<para>
@@ -709,6 +709,6 @@
</varlistentry>
</variablelist>
</para>
-</sect1>
+</sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/gist.sgml b/doc/src/sgml/gist.sgml
index 8a19f156d8..3f7df103b8 100644
--- a/doc/src/sgml/gist.sgml
+++ b/doc/src/sgml/gist.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/gist.sgml -->
-<chapter id="gist">
+<sect1 id="gist">
<title>GiST Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>GiST</secondary>
</indexterm>
-<sect1 id="gist-intro">
+<sect2 id="gist-intro">
<title>Introduction</title>
<para>
@@ -38,9 +38,9 @@
<ulink url="http://www.sai.msu.su/~megera/postgres/gist/">web site</ulink>.
</para>
-</sect1>
+</sect2>
-<sect1 id="gist-builtin-opclasses">
+<sect2 id="gist-builtin-opclasses">
<title>Built-in Operator Classes</title>
<para>
@@ -222,9 +222,9 @@ CREATE INDEX ON my_table USING GIST (my_inet_column inet_ops);
</programlisting>
</para>
-</sect1>
+</sect2>
-<sect1 id="gist-extensibility">
+<sect2 id="gist-extensibility">
<title>Extensibility</title>
<para>
@@ -1260,12 +1260,12 @@ my_stratnum(PG_FUNCTION_ARGS)
will accumulate for the duration of the operation.
</para>
-</sect1>
+</sect2>
-<sect1 id="gist-implementation">
+<sect2 id="gist-implementation">
<title>Implementation</title>
- <sect2 id="gist-buffering-build">
+ <sect3 id="gist-buffering-build">
<title>GiST Index Build Methods</title>
<para>
@@ -1314,10 +1314,10 @@ my_stratnum(PG_FUNCTION_ARGS)
is ordered.
</para>
- </sect2>
-</sect1>
+ </sect3>
+</sect2>
-<sect1 id="gist-examples">
+<sect2 id="gist-examples">
<title>Examples</title>
<para>
@@ -1382,6 +1382,6 @@ my_stratnum(PG_FUNCTION_ARGS)
</variablelist>
</para>
-</sect1>
+</sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml
index e35911ebf8..9e69ef91fe 100644
--- a/doc/src/sgml/hash.sgml
+++ b/doc/src/sgml/hash.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/hash.sgml -->
-<chapter id="hash-index">
+<sect1 id="hash-index">
<title>Hash Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>Hash</secondary>
</indexterm>
-<sect1 id="hash-intro">
+<sect2 id="hash-intro">
<title>Overview</title>
<para>
@@ -108,9 +108,9 @@
with rapidly increasing number of rows.
</para>
-</sect1>
+</sect2>
-<sect1 id="hash-implementation">
+<sect2 id="hash-implementation">
<title>Implementation</title>
<para>
@@ -157,6 +157,6 @@
successfully.
</para>
-</sect1>
+</sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/indextypes.sgml b/doc/src/sgml/indextypes.sgml
new file mode 100644
index 0000000000..94a2b01afc
--- /dev/null
+++ b/doc/src/sgml/indextypes.sgml
@@ -0,0 +1,13 @@
+ <!-- doc/src/sgml/indextypes.sgml -->
+
+<chapter id="indextypes">
+<title>Built-in Index Access Methods</title>
+
+&btree;
+&gist;
+&spgist;
+&gin;
+&brin;
+&hash;
+
+</chapter>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 73b497bcf8..0235c0e352 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -257,12 +257,7 @@ break is not needed in a wider output rendering.
&indexam;
&generic-wal;
&custom-rmgr;
- &btree;
- &gist;
- &spgist;
- &gin;
- &brin;
- &hash;
+ &indextypes;
&storage;
&transaction;
&bki;
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index 102f8627bd..6af93719b8 100644
--- a/doc/src/sgml/spgist.sgml
+++ b/doc/src/sgml/spgist.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/spgist.sgml -->
-<chapter id="spgist">
+<sect1 id="spgist">
<title>SP-GiST Indexes</title>
<indexterm>
@@ -8,7 +8,7 @@
<secondary>SP-GiST</secondary>
</indexterm>
-<sect1 id="spgist-intro">
+<sect2 id="spgist-intro">
<title>Introduction</title>
<para>
@@ -51,9 +51,9 @@
<ulink url="http://www.sai.msu.su/~megera/wiki/spgist_dev">web site</ulink>.
</para>
-</sect1>
+</sect2>
-<sect1 id="spgist-builtin-opclasses">
+<sect2 id="spgist-builtin-opclasses">
<title>Built-in Operator Classes</title>
<para>
@@ -191,9 +191,9 @@
search over indexed point or polygon data sets.
</para>
-</sect1>
+</sect2>
-<sect1 id="spgist-extensibility">
+<sect2 id="spgist-extensibility">
<title>Extensibility</title>
<para>
@@ -933,9 +933,9 @@ LANGUAGE C STRICT;
<function>PG_GET_COLLATION()</function> mechanism.
</para>
-</sect1>
+</sect2>
-<sect1 id="spgist-implementation">
+<sect2 id="spgist-implementation">
<title>Implementation</title>
<para>
@@ -944,7 +944,7 @@ LANGUAGE C STRICT;
know.
</para>
- <sect2 id="spgist-limits">
+ <sect3 id="spgist-limits">
<title>SP-GiST Limits</title>
<para>
@@ -991,9 +991,9 @@ LANGUAGE C STRICT;
leaf datum does not become any smaller within ten cycles
of <function>choose</function> method calls.
</para>
- </sect2>
+ </sect3>
- <sect2 id="spgist-null-labels">
+ <sect3 id="spgist-null-labels">
<title>SP-GiST Without Node Labels</title>
<para>
@@ -1018,9 +1018,9 @@ LANGUAGE C STRICT;
for <function>choose</function> to return <literal>spgAddNode</literal>, since the set
of nodes is supposed to be fixed in such cases.
</para>
- </sect2>
+ </sect3>
- <sect2 id="spgist-all-the-same">
+ <sect3 id="spgist-all-the-same">
<title><quote>All-the-Same</quote> Inner Tuples</title>
<para>
@@ -1056,11 +1056,11 @@ LANGUAGE C STRICT;
depending on how much the <function>inner_consistent</function> function normally
assumes about the meaning of the nodes.
</para>
- </sect2>
+ </sect3>
-</sect1>
+</sect2>
-<sect1 id="spgist-examples">
+<sect2 id="spgist-examples">
<title>Examples</title>
<para>
@@ -1071,6 +1071,6 @@ LANGUAGE C STRICT;
and <filename>src/backend/utils/adt/</filename> to see the code.
</para>
-</sect1>
+</sect2>
-</chapter>
+</sect1>
--
2.39.3 (Apple Git-145)
v2-0001-docs-Remove-the-Installation-from-Binaries-chapte.patchapplication/octet-stream; name=v2-0001-docs-Remove-the-Installation-from-Binaries-chapte.patchDownload
From 3a21aee199804b557631960e2eae6223ed93bd19 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 20 Mar 2024 10:08:05 -0400
Subject: [PATCH v2 1/5] docs: Remove the "Installation from Binaries" chapter.
The entire chapter was four sentences. Move the most useful
information from those sentences to the "Installation from Source
Code" chapter, and rename that to just "Installation".
---
doc/src/sgml/filelist.sgml | 1 -
doc/src/sgml/install-binaries.sgml | 24 ------------------------
doc/src/sgml/installation.sgml | 23 +++++++++++++++++------
doc/src/sgml/postgres.sgml | 1 -
4 files changed, 17 insertions(+), 32 deletions(-)
delete mode 100644 doc/src/sgml/install-binaries.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index e0dca81cb2..b7d1222e3e 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -36,7 +36,6 @@
<!ENTITY client-auth SYSTEM "client-auth.sgml">
<!ENTITY diskusage SYSTEM "diskusage.sgml">
<!ENTITY high-availability SYSTEM "high-availability.sgml">
-<!ENTITY installbin SYSTEM "install-binaries.sgml">
<!ENTITY installation SYSTEM "installation.sgml">
<!ENTITY targets-meson SYSTEM "targets-meson.sgml">
<!ENTITY maintenance SYSTEM "maintenance.sgml">
diff --git a/doc/src/sgml/install-binaries.sgml b/doc/src/sgml/install-binaries.sgml
deleted file mode 100644
index 001c3c7be0..0000000000
--- a/doc/src/sgml/install-binaries.sgml
+++ /dev/null
@@ -1,24 +0,0 @@
-<!-- doc/src/sgml/install-binaries.sgml -->
-<chapter id="install-binaries">
- <title>Installation from Binaries</title>
-
- <indexterm>
- <primary>installation</primary>
- <secondary>binaries</secondary>
- </indexterm>
-
- <para>
- <productname>PostgreSQL</productname> is available in the form of binary
- packages for most common operating systems today. When available, this is
- the recommended way to install PostgreSQL for users of the system. Building
- from source (see <xref linkend="installation" />) is only recommended for
- people developing <productname>PostgreSQL</productname> or extensions.
- </para>
-
- <para>
- For an updated list of platforms providing binary packages, please visit
- the download section on the <productname>PostgreSQL</productname> website at
- <ulink url="https://www.postgresql.org/download/"></ulink> and follow the
- instructions for the specific platform.
- </para>
-</chapter>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index a453f804cd..7b2e6786f4 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -1,18 +1,29 @@
<!-- doc/src/sgml/installation.sgml -->
<chapter id="installation">
- <title>Installation from Source Code</title>
+ <title>Installation</title>
<indexterm zone="installation">
<primary>installation</primary>
</indexterm>
<para>
- This chapter describes the installation of
- <productname>PostgreSQL</productname> using the source code
- distribution. If you are installing a pre-packaged distribution,
- such as an RPM or Debian package, ignore this chapter
- and see <xref linkend="install-binaries" /> instead.
+ Since <productname>PostgreSQL</productname> is available in the form of
+ binary packages for most common operating systems today, it is typically not
+ necessary to build from source.
+ </para>
+
+ <para>
+ For an updated list of platforms providing binary packages, please visit
+ the download section on the <productname>PostgreSQL</productname> website at
+ <ulink url="https://www.postgresql.org/download/"></ulink> and follow the
+ instructions for the specific platform.
+ </para>
+
+ <para>
+ If you wish to compile from source code, for example to develop
+ <productname>PostgreSQL</productname> or an extension, the following
+ sections explain how to do this.
</para>
<sect1 id="install-requirements">
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 2c107199d3..7c234ff1db 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -150,7 +150,6 @@ break is not needed in a wider output rendering.
</para>
</partintro>
- &installbin;
&installation;
&runtime;
&config;
--
2.39.3 (Apple Git-145)
v2-0005-docs-Merge-all-procedural-language-documentation-.patchapplication/octet-stream; name=v2-0005-docs-Merge-all-procedural-language-documentation-.patchDownload
From 61e6f930d24d72b1212fafaed904205fa9ca15a0 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Thu, 21 Mar 2024 10:20:34 -0400
Subject: [PATCH v2 5/5] docs: Merge all procedural language documentation into
one chapter.
The documentation index is getting very long, which makes it hard
to find things. These chapters are consecutive and cover closely related
topics, so merge them into one. Hopefully, that will reduce the size
of the index without making it harder for users to find the information
they need.
Rather than actually combining all of the SGML into a single file,
keep one file per <sect1>, and add a glue file that includes all
of them.
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/plang.sgml | 47 ++++++
doc/src/sgml/plperl.sgml | 52 +++----
doc/src/sgml/plpgsql.sgml | 300 ++++++++++++++++++-------------------
doc/src/sgml/plpython.sgml | 80 +++++-----
doc/src/sgml/pltcl.sgml | 52 +++----
doc/src/sgml/postgres.sgml | 8 +-
doc/src/sgml/xplang.sgml | 42 +-----
8 files changed, 292 insertions(+), 290 deletions(-)
create mode 100644 doc/src/sgml/plang.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 1bb662c16f..b801d1cdf3 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -66,6 +66,7 @@
<!ENTITY xaggr SYSTEM "xaggr.sgml">
<!ENTITY xfunc SYSTEM "xfunc.sgml">
<!ENTITY xindex SYSTEM "xindex.sgml">
+<!ENTITY plang SYSTEM "plang.sgml">
<!ENTITY xplang SYSTEM "xplang.sgml">
<!ENTITY xoper SYSTEM "xoper.sgml">
<!ENTITY xtypes SYSTEM "xtypes.sgml">
diff --git a/doc/src/sgml/plang.sgml b/doc/src/sgml/plang.sgml
new file mode 100644
index 0000000000..cdcf81ca3d
--- /dev/null
+++ b/doc/src/sgml/plang.sgml
@@ -0,0 +1,47 @@
+<!-- doc/src/sgml/xplang.sgml -->
+
+ <chapter id="plang">
+ <title>Procedural Languages</title>
+
+ <indexterm zone="plang">
+ <primary>procedural language</primary>
+ </indexterm>
+
+ <para>
+ <productname>PostgreSQL</productname> allows user-defined functions
+ to be written in other languages besides SQL and C. These other
+ languages are generically called <firstterm>procedural
+ languages</firstterm> (<acronym>PL</acronym>s). For a function
+ written in a procedural language, the database server has
+ no built-in knowledge about how to interpret the function's source
+ text. Instead, the task is passed to a special handler that knows
+ the details of the language. The handler could either do all the
+ work of parsing, syntax analysis, execution, etc. itself, or it
+ could serve as <quote>glue</quote> between
+ <productname>PostgreSQL</productname> and an existing implementation
+ of a programming language. The handler itself is a
+ C language function compiled into a shared object and
+ loaded on demand, just like any other C function.
+ </para>
+
+ <para>
+ There are currently four procedural languages available in the
+ standard <productname>PostgreSQL</productname> distribution:
+ <application>PL/pgSQL</application> (<xref linkend="plpgsql"/>),
+ <application>PL/Tcl</application> (<xref linkend="pltcl"/>),
+ <application>PL/Perl</application> (<xref linkend="plperl"/>), and
+ <application>PL/Python</application> (<xref linkend="plpython"/>).
+ There are additional procedural languages available that are not
+ included in the core distribution. <xref linkend="external-projects"/>
+ has information about finding them. In addition other languages can
+ be defined by users; the basics of developing a new procedural
+ language are covered in <xref linkend="plhandler"/>.
+ </para>
+
+ &xplang;
+ &plsql;
+ &pltcl;
+ &plperl;
+ &plpython;
+
+</chapter>
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 25b1077ad7..912677724a 100644
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/plperl.sgml -->
- <chapter id="plperl">
+ <sect1 id="plperl">
<title>PL/Perl — Perl Procedural Language</title>
<indexterm zone="plperl">
@@ -46,7 +46,7 @@
</para>
</note>
- <sect1 id="plperl-funcs">
+ <sect2 id="plperl-funcs">
<title>PL/Perl Functions and Arguments</title>
<para>
@@ -405,9 +405,9 @@ use strict;
The <literal>feature</literal> pragma is also available to <function>use</function> if your Perl is version 5.10.0 or higher.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plperl-data">
+ <sect2 id="plperl-data">
<title>Data Values in PL/Perl</title>
<para>
@@ -425,12 +425,12 @@ use strict;
for <type>bool</type> values. Several examples of transform modules
are included in the <productname>PostgreSQL</productname> distribution.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plperl-builtins">
+ <sect2 id="plperl-builtins">
<title>Built-in Functions</title>
- <sect2 id="plperl-database">
+ <sect3 id="plperl-database">
<title>Database Access from PL/Perl</title>
<para>
@@ -779,9 +779,9 @@ CALL transaction_test1();
</listitem>
</varlistentry>
</variablelist>
- </sect2>
+ </sect3>
- <sect2 id="plperl-utility-functions">
+ <sect3 id="plperl-utility-functions">
<title>Utility Functions in PL/Perl</title>
<variablelist>
@@ -993,10 +993,10 @@ CALL transaction_test1();
</varlistentry>
</variablelist>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plperl-global">
+ <sect2 id="plperl-global">
<title>Global Values in PL/Perl</title>
<para>
@@ -1069,9 +1069,9 @@ $$ LANGUAGE plperl;
them <literal>SECURITY DEFINER</literal>. You must of course take care that
such functions can't be used to do anything unintended.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plperl-trusted">
+ <sect2 id="plperl-trusted">
<title>Trusted and Untrusted PL/Perl</title>
<indexterm zone="plperl-trusted">
@@ -1169,9 +1169,9 @@ $$ LANGUAGE plperl;
</para>
</note>
- </sect1>
+ </sect2>
- <sect1 id="plperl-triggers">
+ <sect2 id="plperl-triggers">
<title>PL/Perl Triggers</title>
<para>
@@ -1357,9 +1357,9 @@ CREATE TRIGGER test_valid_id_trig
FOR EACH ROW EXECUTE FUNCTION valid_id();
</programlisting>
</para>
- </sect1>
+ </sect2>
- <sect1 id="plperl-event-triggers">
+ <sect2 id="plperl-event-triggers">
<title>PL/Perl Event Triggers</title>
<para>
@@ -1407,12 +1407,12 @@ CREATE EVENT TRIGGER perl_a_snitch
EXECUTE FUNCTION perlsnitch();
</programlisting>
</para>
- </sect1>
+ </sect2>
- <sect1 id="plperl-under-the-hood">
+ <sect2 id="plperl-under-the-hood">
<title>PL/Perl Under the Hood</title>
- <sect2 id="plperl-config">
+ <sect3 id="plperl-config">
<title>Configuration</title>
<para>
@@ -1538,9 +1538,9 @@ DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
</varlistentry>
</variablelist>
-</sect2>
+</sect3>
- <sect2 id="plperl-missing">
+ <sect3 id="plperl-missing">
<title>Limitations and Missing Features</title>
<para>
@@ -1588,8 +1588,8 @@ DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
</listitem>
</itemizedlist>
</para>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 6f880b705f..4175e4763b 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -1,13 +1,13 @@
<!-- doc/src/sgml/plpgsql.sgml -->
-<chapter id="plpgsql">
+<sect1 id="plpgsql">
<title><application>PL/pgSQL</application> — <acronym>SQL</acronym> Procedural Language</title>
<indexterm zone="plpgsql">
<primary>PL/pgSQL</primary>
</indexterm>
- <sect1 id="plpgsql-overview">
+ <sect2 id="plpgsql-overview">
<title>Overview</title>
<para>
@@ -65,7 +65,7 @@
administrators could choose to remove it.
</para>
- <sect2 id="plpgsql-advantages">
+ <sect3 id="plpgsql-advantages">
<title>Advantages of Using <application>PL/pgSQL</application></title>
<para>
@@ -112,9 +112,9 @@
Also, with <application>PL/pgSQL</application> you can use all
the data types, operators and functions of SQL.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-args-results">
+ <sect3 id="plpgsql-args-results">
<title>Supported Argument and Result Data Types</title>
<para>
@@ -174,10 +174,10 @@
<xref linkend="plpgsql-declaration-parameters"/> and
<xref linkend="plpgsql-statements-returning"/>.
</para>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plpgsql-structure">
+ <sect2 id="plpgsql-structure">
<title>Structure of <application>PL/pgSQL</application></title>
<para>
@@ -310,9 +310,9 @@ $$ LANGUAGE plpgsql;
outer transaction. For more about that see <xref
linkend="plpgsql-error-trapping"/>.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-declarations">
+ <sect2 id="plpgsql-declarations">
<title>Declarations</title>
<para>
@@ -393,7 +393,7 @@ DECLARE
</programlisting>
</para>
- <sect2 id="plpgsql-declaration-parameters">
+ <sect3 id="plpgsql-declaration-parameters">
<title>Declaring Function Parameters</title>
<para>
@@ -637,9 +637,9 @@ SELECT add_three_values(1, 2, 4.7);
The function using <type>anyelement</type> would require you to
cast the three inputs to the same type manually.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-declaration-alias">
+ <sect3 id="plpgsql-declaration-alias">
<title><literal>ALIAS</literal></title>
<synopsis>
@@ -669,9 +669,9 @@ DECLARE
object, unrestricted use can be confusing. It's best to use it only
for the purpose of overriding predetermined names.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-declaration-type">
+ <sect3 id="plpgsql-declaration-type">
<title>Copying Types</title>
<synopsis>
@@ -724,9 +724,9 @@ user_ids users.user_id%TYPE ARRAY[4]; -- equivalent to the above
arguments or result placeholders.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-declaration-rowtypes">
+ <sect3 id="plpgsql-declaration-rowtypes">
<title>Row Types</title>
<synopsis>
@@ -787,9 +787,9 @@ $$ LANGUAGE plpgsql;
SELECT merge_fields(t.*) FROM table1 t WHERE ... ;
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-declaration-records">
+ <sect3 id="plpgsql-declaration-records">
<title>Record Types</title>
<synopsis>
@@ -817,9 +817,9 @@ SELECT merge_fields(t.*) FROM table1 t WHERE ... ;
calling query is parsed, whereas a record variable can change its row
structure on-the-fly.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-declaration-collation">
+ <sect3 id="plpgsql-declaration-collation">
<title>Collation of <application>PL/pgSQL</application> Variables</title>
<indexterm>
@@ -910,10 +910,10 @@ $$ LANGUAGE plpgsql;
parameters, or local variables used in the expression, just as would
happen in a plain SQL command.
</para>
+ </sect3>
</sect2>
- </sect1>
- <sect1 id="plpgsql-expressions">
+ <sect2 id="plpgsql-expressions">
<title>Expressions</title>
<para>
@@ -972,9 +972,9 @@ IF count(*) > 0 FROM my_table THEN ...
more than one row. (If it produces no rows, the result is taken as
NULL.)
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-statements">
+ <sect2 id="plpgsql-statements">
<title>Basic Statements</title>
<para>
@@ -986,7 +986,7 @@ IF count(*) > 0 FROM my_table THEN ...
as described in <xref linkend="plpgsql-statements-general-sql"/>.
</para>
- <sect2 id="plpgsql-statements-assignment">
+ <sect3 id="plpgsql-statements-assignment">
<title>Assignment</title>
<para>
@@ -1027,9 +1027,9 @@ my_array[1:3] := array[1,2,3];
complex_array[n].realpart = 12.3;
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-general-sql">
+ <sect3 id="plpgsql-statements-general-sql">
<title>Executing SQL Commands</title>
<para>
@@ -1146,9 +1146,9 @@ PERFORM <replaceable>query</replaceable>;
PERFORM create_mv('cs_session_page_requests_mv', my_query);
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-sql-onerow">
+ <sect3 id="plpgsql-statements-sql-onerow">
<title>Executing a Command with a Single-Row Result</title>
<indexterm zone="plpgsql-statements-sql-onerow">
@@ -1307,9 +1307,9 @@ CONTEXT: PL/pgSQL function get_userid(text) line 6 at SQL statement
</para>
</note>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-executing-dyn">
+ <sect3 id="plpgsql-statements-executing-dyn">
<title>Executing Dynamic Commands</title>
<para>
@@ -1608,9 +1608,9 @@ EXECUTE format('UPDATE tbl SET %I = $1 WHERE key = $2', colname)
linkend="plpgsql-porting-ex2"/>, which builds and executes a
<command>CREATE FUNCTION</command> command to define a new function.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-diagnostics">
+ <sect3 id="plpgsql-statements-diagnostics">
<title>Obtaining the Result Status</title>
<para>
@@ -1749,9 +1749,9 @@ GET DIAGNOSTICS integer_var = ROW_COUNT;
affect only the current function.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-null">
+ <sect3 id="plpgsql-statements-null">
<title>Doing Nothing At All</title>
<para>
@@ -1795,10 +1795,10 @@ END;
</para>
</note>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plpgsql-control-structures">
+ <sect2 id="plpgsql-control-structures">
<title>Control Structures</title>
<para>
@@ -1809,7 +1809,7 @@ END;
flexible and powerful way.
</para>
- <sect2 id="plpgsql-statements-returning">
+ <sect3 id="plpgsql-statements-returning">
<title>Returning from a Function</title>
<para>
@@ -1818,7 +1818,7 @@ END;
NEXT</command>.
</para>
- <sect3 id="plpgsql-statements-returning-return">
+ <sect4 id="plpgsql-statements-returning-return">
<title><command>RETURN</command></title>
<synopsis>
@@ -1877,9 +1877,9 @@ RETURN composite_type_var;
RETURN (1, 2, 'three'::text); -- must cast columns to correct types
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-statements-returning-return-next">
+ <sect4 id="plpgsql-statements-returning-return-next">
<title><command>RETURN NEXT</command> and <command>RETURN QUERY</command></title>
<indexterm>
<primary>RETURN NEXT</primary>
@@ -2026,10 +2026,10 @@ SELECT * FROM get_available_flightid(CURRENT_DATE);
increasing this parameter.
</para>
</note>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-statements-returning-procedure">
+ <sect3 id="plpgsql-statements-returning-procedure">
<title>Returning from a Procedure</title>
<para>
@@ -2043,9 +2043,9 @@ SELECT * FROM get_available_flightid(CURRENT_DATE);
If the procedure has output parameters, the final values of the output
parameter variables will be returned to the caller.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-calling-procedure">
+ <sect3 id="plpgsql-statements-calling-procedure">
<title>Calling a Procedure</title>
<para>
@@ -2079,9 +2079,9 @@ $$;
variable or a field of a composite-type variable. Currently,
it cannot be an element of an array.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-conditionals">
+ <sect3 id="plpgsql-conditionals">
<title>Conditionals</title>
<para>
@@ -2111,7 +2111,7 @@ $$;
</itemizedlist>
</para>
- <sect3 id="plpgsql-conditionals-if-then">
+ <sect4 id="plpgsql-conditionals-if-then">
<title><literal>IF-THEN</literal></title>
<synopsis>
@@ -2136,9 +2136,9 @@ IF v_user_id <> 0 THEN
END IF;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-conditionals-if-then-else">
+ <sect4 id="plpgsql-conditionals-if-then-else">
<title><literal>IF-THEN-ELSE</literal></title>
<synopsis>
@@ -2177,9 +2177,9 @@ ELSE
END IF;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-conditionals-if-then-elsif">
+ <sect4 id="plpgsql-conditionals-if-then-elsif">
<title><literal>IF-THEN-ELSIF</literal></title>
<synopsis>
@@ -2253,9 +2253,9 @@ END IF;
for each <literal>IF</literal>, so it is much more cumbersome than
using <literal>ELSIF</literal> when there are many alternatives.
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-conditionals-simple-case">
+ <sect4 id="plpgsql-conditionals-simple-case">
<title>Simple <literal>CASE</literal></title>
<synopsis>
@@ -2296,9 +2296,9 @@ CASE x
END CASE;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-conditionals-searched-case">
+ <sect4 id="plpgsql-conditionals-searched-case">
<title>Searched <literal>CASE</literal></title>
<synopsis>
@@ -2347,10 +2347,10 @@ END CASE;
than doing nothing.
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-control-structures-loops">
+ <sect3 id="plpgsql-control-structures-loops">
<title>Simple Loops</title>
<indexterm zone="plpgsql-control-structures-loops">
@@ -2365,7 +2365,7 @@ END CASE;
<application>PL/pgSQL</application> function to repeat a series of commands.
</para>
- <sect3 id="plpgsql-control-structures-loops-loop">
+ <sect4 id="plpgsql-control-structures-loops-loop">
<title><literal>LOOP</literal></title>
<synopsis>
@@ -2383,9 +2383,9 @@ END LOOP <optional> <replaceable>label</replaceable> </optional>;
and <literal>CONTINUE</literal> statements within nested loops to
specify which loop those statements refer to.
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-control-structures-loops-exit">
+ <sect4 id="plpgsql-control-structures-loops-exit">
<title><literal>EXIT</literal></title>
<indexterm>
@@ -2455,9 +2455,9 @@ BEGIN
END;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-control-structures-loops-continue">
+ <sect4 id="plpgsql-control-structures-loops-continue">
<title><literal>CONTINUE</literal></title>
<indexterm>
@@ -2503,10 +2503,10 @@ LOOP
END LOOP;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-control-structures-loops-while">
+ <sect4 id="plpgsql-control-structures-loops-while">
<title><literal>WHILE</literal></title>
<indexterm>
@@ -2541,9 +2541,9 @@ WHILE NOT done LOOP
END LOOP;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-integer-for">
+ <sect4 id="plpgsql-integer-for">
<title><literal>FOR</literal> (Integer Variant)</title>
<synopsis>
@@ -2597,10 +2597,10 @@ END LOOP;
referenced with a qualified name, using that
<replaceable>label</replaceable>.
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-records-iterating">
+ <sect3 id="plpgsql-records-iterating">
<title>Looping through Query Results</title>
<para>
@@ -2694,9 +2694,9 @@ END LOOP <optional> <replaceable>label</replaceable> </optional>;
through is to declare it as a cursor. This is described in
<xref linkend="plpgsql-cursor-for-loop"/>.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-foreach-array">
+ <sect3 id="plpgsql-foreach-array">
<title>Looping through Arrays</title>
<para>
@@ -2778,9 +2778,9 @@ NOTICE: row = {7,8,9}
NOTICE: row = {10,11,12}
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-error-trapping">
+ <sect3 id="plpgsql-error-trapping">
<title>Trapping Errors</title>
<indexterm>
@@ -2943,7 +2943,7 @@ SELECT merge_db(1, 'dennis');
</para>
</example>
- <sect3 id="plpgsql-exception-diagnostics">
+ <sect4 id="plpgsql-exception-diagnostics">
<title>Obtaining Information about an Error</title>
<para>
@@ -3069,10 +3069,10 @@ EXCEPTION WHEN OTHERS THEN
END;
</programlisting>
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-call-stack">
+ <sect3 id="plpgsql-call-stack">
<title>Obtaining Execution Location Information</title>
<para>
@@ -3124,10 +3124,10 @@ CONTEXT: PL/pgSQL function outer_func() line 3 at RETURN
returns the same sort of stack trace, but describing the location
at which an error was detected, rather than the current location.
</para>
+ </sect3>
</sect2>
- </sect1>
- <sect1 id="plpgsql-cursors">
+ <sect2 id="plpgsql-cursors">
<title>Cursors</title>
<indexterm zone="plpgsql-cursors">
@@ -3148,7 +3148,7 @@ CONTEXT: PL/pgSQL function outer_func() line 3 at RETURN
large row sets from functions.
</para>
- <sect2 id="plpgsql-cursor-declarations">
+ <sect3 id="plpgsql-cursor-declarations">
<title>Declaring Cursor Variables</title>
<para>
@@ -3200,9 +3200,9 @@ DECLARE
assumes that re-reading the query's output will give consistent
results, which a volatile function might not do.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-cursor-opening">
+ <sect3 id="plpgsql-cursor-opening">
<title>Opening Cursors</title>
<para>
@@ -3242,7 +3242,7 @@ DECLARE
<xref linkend="plpgsql-cursor-returning"/>.
</para>
- <sect3 id="plpgsql-cursor-opening-open-for-query">
+ <sect4 id="plpgsql-cursor-opening-open-for-query">
<title><command>OPEN FOR</command> <replaceable>query</replaceable></title>
<synopsis>
@@ -3274,9 +3274,9 @@ OPEN <replaceable>unbound_cursorvar</replaceable> <optional> <optional> NO </opt
OPEN curs1 FOR SELECT * FROM foo WHERE key = mykey;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-cursor-opening-open-for-execute">
+ <sect4 id="plpgsql-cursor-opening-open-for-execute">
<title><command>OPEN FOR EXECUTE</command></title>
<synopsis>
@@ -3311,9 +3311,9 @@ OPEN curs1 FOR EXECUTE format('SELECT * FROM %I WHERE col1 = $1',tabname) USING
is inserted via a <literal>USING</literal> parameter, so it needs
no quoting.
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-open-bound-cursor">
+ <sect4 id="plpgsql-open-bound-cursor">
<title>Opening a Bound Cursor</title>
<synopsis>
@@ -3374,10 +3374,10 @@ BEGIN
OPEN curs4;
</programlisting>
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-cursor-using">
+ <sect3 id="plpgsql-cursor-using">
<title>Using Cursors</title>
<para>
@@ -3401,7 +3401,7 @@ BEGIN
only until the end of the transaction.
</para>
- <sect3 id="plpgsql-cursor-using-fetch">
+ <sect4 id="plpgsql-cursor-using-fetch">
<title><literal>FETCH</literal></title>
<synopsis>
@@ -3456,9 +3456,9 @@ FETCH LAST FROM curs3 INTO x, y;
FETCH RELATIVE -2 FROM curs4 INTO x;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-cursor-using-move">
+ <sect4 id="plpgsql-cursor-using-move">
<title><literal>MOVE</literal></title>
<synopsis>
@@ -3483,9 +3483,9 @@ MOVE RELATIVE -2 FROM curs4;
MOVE FORWARD 2 FROM curs4;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-cursor-using-update-delete">
+ <sect4 id="plpgsql-cursor-using-update-delete">
<title><literal>UPDATE/DELETE WHERE CURRENT OF</literal></title>
<synopsis>
@@ -3509,9 +3509,9 @@ DELETE FROM <replaceable>table</replaceable> WHERE CURRENT OF <replaceable>curso
UPDATE foo SET dataval = myval WHERE CURRENT OF curs1;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-cursor-using-close">
+ <sect4 id="plpgsql-cursor-using-close">
<title><literal>CLOSE</literal></title>
<synopsis>
@@ -3530,9 +3530,9 @@ CLOSE <replaceable>cursor</replaceable>;
CLOSE curs1;
</programlisting>
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-cursor-returning">
+ <sect4 id="plpgsql-cursor-returning">
<title>Returning Cursors</title>
<para>
@@ -3643,10 +3643,10 @@ FETCH ALL FROM b;
COMMIT;
</programlisting>
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-cursor-for-loop">
+ <sect3 id="plpgsql-cursor-for-loop">
<title>Looping through a Cursor's Result</title>
<para>
@@ -3677,11 +3677,11 @@ END LOOP <optional> <replaceable>label</replaceable> </optional>;
Each row returned by the cursor is successively assigned to this
record variable and the loop body is executed.
</para>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-transactions">
+ <sect2 id="plpgsql-transactions">
<title>Transaction Management</title>
<para>
@@ -3782,12 +3782,12 @@ CALL transaction_test2();
<para>
A transaction cannot be ended inside a block with exception handlers.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-errors-and-messages">
+ <sect2 id="plpgsql-errors-and-messages">
<title>Errors and Messages</title>
- <sect2 id="plpgsql-statements-raise">
+ <sect3 id="plpgsql-statements-raise">
<title>Reporting Errors and Messages</title>
<indexterm>
@@ -3984,9 +3984,9 @@ RAISE unique_violation USING MESSAGE = 'Duplicate user ID: ' || user_id;
</para>
</note>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-statements-assert">
+ <sect3 id="plpgsql-statements-assert">
<title>Checking Assertions</title>
<indexterm>
@@ -4043,11 +4043,11 @@ ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <repl
the <command>RAISE</command> statement, described above, for that.
</para>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-trigger">
+ <sect2 id="plpgsql-trigger">
<title>Trigger Functions</title>
<indexterm zone="plpgsql-trigger">
@@ -4066,7 +4066,7 @@ ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <repl
automatically defined to describe the condition that triggered the call.
</para>
- <sect2 id="plpgsql-dml-trigger">
+ <sect3 id="plpgsql-dml-trigger">
<title>Triggers on Data Changes</title>
<para>
@@ -4680,9 +4680,9 @@ CREATE TRIGGER emp_audit_del
</programlisting>
</example>
-</sect2>
+</sect3>
- <sect2 id="plpgsql-event-trigger">
+ <sect3 id="plpgsql-event-trigger">
<title>Triggers on Events</title>
<para>
@@ -4742,11 +4742,11 @@ $$ LANGUAGE plpgsql;
CREATE EVENT TRIGGER snitch ON ddl_command_start EXECUTE FUNCTION snitch();
</programlisting>
</example>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-implementation">
+ <sect2 id="plpgsql-implementation">
<title><application>PL/pgSQL</application> under the Hood</title>
<para>
@@ -4754,7 +4754,7 @@ CREATE EVENT TRIGGER snitch ON ddl_command_start EXECUTE FUNCTION snitch();
frequently important for <application>PL/pgSQL</application> users to know.
</para>
- <sect2 id="plpgsql-var-subst">
+ <sect3 id="plpgsql-var-subst">
<title>Variable Substitution</title>
<para>
@@ -4930,9 +4930,9 @@ $$ LANGUAGE plpgsql;
the utility statement as a string and <command>EXECUTE</command> it.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-plan-caching">
+ <sect3 id="plpgsql-plan-caching">
<title>Plan Caching</title>
<para>
@@ -5083,11 +5083,11 @@ $$ LANGUAGE plpgsql;
use of the <literal>now()</literal> function would still be a better idea.
</para>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
- <sect1 id="plpgsql-development-tips">
+ <sect2 id="plpgsql-development-tips">
<title>Tips for Developing in <application>PL/pgSQL</application></title>
<para>
@@ -5124,7 +5124,7 @@ $$ LANGUAGE plpgsql;
making it easier to recreate and debug functions.
</para>
- <sect2 id="plpgsql-quote-tips">
+ <sect3 id="plpgsql-quote-tips">
<title>Handling of Quotation Marks</title>
<para>
@@ -5279,8 +5279,8 @@ a_output := a_output || $$ if v_$$ || referrer_keys.kind || $$ like '$$
</varlistentry>
</variablelist>
- </sect2>
- <sect2 id="plpgsql-extra-checks">
+ </sect3>
+ <sect3 id="plpgsql-extra-checks">
<title>Additional Compile-Time and Run-Time Checks</title>
<para>
@@ -5400,12 +5400,12 @@ HINT: Make sure the query returns the exact list of columns.
(1 row)
</programlisting>
</para>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
<!-- **** Porting from Oracle PL/SQL **** -->
- <sect1 id="plpgsql-porting">
+ <sect2 id="plpgsql-porting">
<title>Porting from <productname>Oracle</productname> PL/SQL</title>
<indexterm zone="plpgsql-porting">
@@ -5519,7 +5519,7 @@ HINT: Make sure the query returns the exact list of columns.
</itemizedlist>
</para>
- <sect2 id="plpgsql-porting-examples">
+ <sect3 id="plpgsql-porting-examples">
<title>Porting Examples</title>
<para>
@@ -5912,9 +5912,9 @@ $$ LANGUAGE plpgsql;
</calloutlist>
</para>
</example>
- </sect2>
+ </sect3>
- <sect2 id="plpgsql-porting-other">
+ <sect3 id="plpgsql-porting-other">
<title>Other Things to Watch For</title>
<para>
@@ -5923,7 +5923,7 @@ $$ LANGUAGE plpgsql;
<productname>PostgreSQL</productname>.
</para>
- <sect3 id="plpgsql-porting-exceptions">
+ <sect4 id="plpgsql-porting-exceptions">
<title>Implicit Rollback after Exceptions</title>
<para>
@@ -5953,9 +5953,9 @@ END;
<command>SAVEPOINT</command> and <command>ROLLBACK TO</command> in a different way
then some actual thought will be required.
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-porting-other-execute">
+ <sect4 id="plpgsql-porting-other-execute">
<title><command>EXECUTE</command></title>
<para>
@@ -5968,9 +5968,9 @@ END;
type <literal>EXECUTE 'SELECT * FROM $1';</literal> will not work
reliably unless you use these functions.
</para>
- </sect3>
+ </sect4>
- <sect3 id="plpgsql-porting-optimization">
+ <sect4 id="plpgsql-porting-optimization">
<title>Optimizing <application>PL/pgSQL</application> Functions</title>
<para>
@@ -5994,10 +5994,10 @@ CREATE FUNCTION foo(...) RETURNS integer AS $$
$$ LANGUAGE plpgsql STRICT IMMUTABLE;
</programlisting>
</para>
- </sect3>
- </sect2>
+ </sect4>
+ </sect3>
- <sect2 id="plpgsql-porting-appendix">
+ <sect3 id="plpgsql-porting-appendix">
<title>Appendix</title>
<para>
@@ -6126,8 +6126,8 @@ END;
$$ LANGUAGE plpgsql STRICT IMMUTABLE;
]]>
</programlisting>
- </sect2>
+ </sect3>
- </sect1>
+ </sect2>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index e5d51d6e9f..aaedb30d2e 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/doc/src/sgml/plpython.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/plpython.sgml -->
-<chapter id="plpython">
+<sect1 id="plpython">
<title>PL/Python — Python Procedural Language</title>
<indexterm zone="plpython"><primary>PL/Python</primary></indexterm>
@@ -46,7 +46,7 @@
</para>
</note>
- <sect1 id="plpython-funcs">
+ <sect2 id="plpython-funcs">
<title>PL/Python Functions</title>
<para>
@@ -142,9 +142,9 @@ $$ LANGUAGE plpython3u;
PL/Python. It is better to treat the function parameters as
read-only.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-data">
+ <sect2 id="plpython-data">
<title>Data Values</title>
<para>
Generally speaking, the aim of PL/Python is to provide
@@ -153,7 +153,7 @@ $$ LANGUAGE plpython3u;
below.
</para>
- <sect2 id="plpython-data-type-mapping">
+ <sect3 id="plpython-data-type-mapping">
<title>Data Type Mapping</title>
<para>
When a PL/Python function is called, its arguments are converted from
@@ -267,9 +267,9 @@ $$ LANGUAGE plpython3u;
return type and the Python data type of the actual return object
are not flagged; the value will be converted in any case.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpython-data-null">
+ <sect3 id="plpython-data-null">
<title>Null, None</title>
<para>
If an SQL null value<indexterm><primary>null value</primary><secondary
@@ -299,9 +299,9 @@ $$ LANGUAGE plpython3u;
function, return the value <symbol>None</symbol>. This can be done whether the
function is strict or not.
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpython-arrays">
+ <sect3 id="plpython-arrays">
<title>Arrays, Lists</title>
<para>
SQL array values are passed into PL/Python as a Python list. To
@@ -367,9 +367,9 @@ SELECT return_str_arr();
(1 row)
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpython-data-composite-types">
+ <sect3 id="plpython-data-composite-types">
<title>Composite Types</title>
<para>
Composite-type arguments are passed to the function as Python mappings. The
@@ -514,9 +514,9 @@ $$ LANGUAGE plpython3u;
CALL python_triple(5, 10);
</programlisting>
</para>
- </sect2>
+ </sect3>
- <sect2 id="plpython-data-set-returning-funcs">
+ <sect3 id="plpython-data-set-returning-funcs">
<title>Set-Returning Functions</title>
<para>
A <application>PL/Python</application> function can also return sets of
@@ -613,10 +613,10 @@ $$ LANGUAGE plpython3u;
SELECT * FROM multiout_simple_setof(3);
</programlisting>
</para>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plpython-sharing">
+ <sect2 id="plpython-sharing">
<title>Sharing Data</title>
<para>
The global dictionary <varname>SD</varname> is available to store
@@ -634,9 +634,9 @@ SELECT * FROM multiout_simple_setof(3);
<function>myfunc2</function>. The exception is the data in the
<varname>GD</varname> dictionary, as mentioned above.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-do">
+ <sect2 id="plpython-do">
<title>Anonymous Code Blocks</title>
<para>
@@ -652,9 +652,9 @@ $$ LANGUAGE plpython3u;
An anonymous code block receives no arguments, and whatever value it
might return is discarded. Otherwise it behaves just like a function.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-trigger">
+ <sect2 id="plpython-trigger">
<title>Trigger Functions</title>
<indexterm zone="plpython-trigger">
@@ -767,9 +767,9 @@ $$ LANGUAGE plpython3u;
<literal>"MODIFY"</literal> to indicate you've modified the new row.
Otherwise the return value is ignored.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-database">
+ <sect2 id="plpython-database">
<title>Database Access</title>
<para>
@@ -779,7 +779,7 @@ $$ LANGUAGE plpython3u;
<literal>plpy.<replaceable>foo</replaceable></literal>.
</para>
- <sect2 id="plpython-database-access-funcs">
+ <sect3 id="plpython-database-access-funcs">
<title>Database Access Functions</title>
<para>
@@ -1037,9 +1037,9 @@ $$ LANGUAGE plpython3u;
</varlistentry>
</variablelist>
- </sect2>
+ </sect3>
- <sect2 id="plpython-trapping">
+ <sect3 id="plpython-trapping">
<title>Trapping Errors</title>
<para>
@@ -1109,10 +1109,10 @@ $$ LANGUAGE plpython3u;
the <quote>SQLSTATE</quote> error code. This approach provides
approximately the same functionality
</para>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plpython-subtransaction">
+ <sect2 id="plpython-subtransaction">
<title>Explicit Subtransactions</title>
<para>
@@ -1124,7 +1124,7 @@ $$ LANGUAGE plpython3u;
the form of explicit subtransactions.
</para>
- <sect2 id="plpython-subtransaction-context-managers">
+ <sect3 id="plpython-subtransaction-context-managers">
<title>Subtransaction Context Managers</title>
<para>
@@ -1189,10 +1189,10 @@ $$ LANGUAGE plpython3u;
explicit subtransaction block would also cause the subtransaction
to be rolled back.
</para>
- </sect2>
- </sect1>
+ </sect3>
+ </sect2>
- <sect1 id="plpython-transactions">
+ <sect2 id="plpython-transactions">
<title>Transaction Management</title>
<para>
@@ -1229,9 +1229,9 @@ CALL transaction_test1();
<para>
Transactions cannot be ended when an explicit subtransaction is active.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-util">
+ <sect2 id="plpython-util">
<title>Utility Functions</title>
<para>
The <literal>plpy</literal> module also provides the functions
@@ -1317,9 +1317,9 @@ plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
plpy.quote_literal(keyvalue)))
</programlisting>
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-python23">
+ <sect2 id="plpython-python23">
<title>Python 2 vs. Python 3</title>
<para>
@@ -1328,9 +1328,9 @@ plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
<literal>plpythonu</literal> and <literal>plpython2u</literal> language
names.
</para>
- </sect1>
+ </sect2>
- <sect1 id="plpython-envar">
+ <sect2 id="plpython-envar">
<title>Environment Variables</title>
<para>
@@ -1393,5 +1393,5 @@ plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
the <command>python</command> man page are only effective in a
command-line interpreter and not an embedded Python interpreter.)
</para>
- </sect1>
-</chapter>
+ </sect2>
+</sect1>
diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml
index b31f2c1330..9e12df3816 100644
--- a/doc/src/sgml/pltcl.sgml
+++ b/doc/src/sgml/pltcl.sgml
@@ -1,6 +1,6 @@
<!-- doc/src/sgml/pltcl.sgml -->
- <chapter id="pltcl">
+ <sect1 id="pltcl">
<title>PL/Tcl — Tcl Procedural Language</title>
<indexterm zone="pltcl">
@@ -21,7 +21,7 @@
<!-- **** PL/Tcl overview **** -->
- <sect1 id="pltcl-overview">
+ <sect2 id="pltcl-overview">
<title>Overview</title>
<para>
@@ -70,11 +70,11 @@
<literal>CREATE EXTENSION pltcl</literal> or
<literal>CREATE EXTENSION pltclu</literal>.
</para>
- </sect1>
+ </sect2>
<!-- **** PL/Tcl description **** -->
- <sect1 id="pltcl-functions">
+ <sect2 id="pltcl-functions">
<title>PL/Tcl Functions and Arguments</title>
<para>
@@ -238,9 +238,9 @@ $$ LANGUAGE pltcl;
</programlisting>
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-data">
+ <sect2 id="pltcl-data">
<title>Data Values in PL/Tcl</title>
<para>
@@ -252,9 +252,9 @@ $$ LANGUAGE pltcl;
result type, or for the specified column of a composite result type.
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-global">
+ <sect2 id="pltcl-global">
<title>Global Data in PL/Tcl</title>
<indexterm zone="pltcl-global">
@@ -314,9 +314,9 @@ $$ LANGUAGE pltcl;
An example of using <literal>GD</literal> appears in the
<function>spi_execp</function> example below.
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-dbaccess">
+ <sect2 id="pltcl-dbaccess">
<title>Database Access from PL/Tcl</title>
<para>
@@ -570,9 +570,9 @@ SELECT 'doesn''t' AS ret
</variablelist>
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-trigger">
+ <sect2 id="pltcl-trigger">
<title>Trigger Functions in PL/Tcl</title>
<indexterm>
@@ -782,9 +782,9 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
name; that's supplied from the trigger arguments. This lets the
trigger function be reused with different tables.
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-event-trigger">
+ <sect2 id="pltcl-event-trigger">
<title>Event Trigger Functions in PL/Tcl</title>
<indexterm>
@@ -841,9 +841,9 @@ $$ LANGUAGE pltcl;
CREATE EVENT TRIGGER tcl_a_snitch ON ddl_command_start EXECUTE FUNCTION tclsnitch();
</programlisting>
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-error-handling">
+ <sect2 id="pltcl-error-handling">
<title>Error Handling in PL/Tcl</title>
<indexterm>
@@ -916,9 +916,9 @@ if {[catch { spi_exec $sql_command }]} {
(The double colons explicitly specify that <varname>errorCode</varname>
is a global variable.)
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-subtransactions">
+ <sect2 id="pltcl-subtransactions">
<title>Explicit Subtransactions in PL/Tcl</title>
<indexterm>
@@ -998,9 +998,9 @@ $$ LANGUAGE pltcl;
contained Tcl code (for instance, due to <function>return</function>) do
not cause a rollback.
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-transactions">
+ <sect2 id="pltcl-transactions">
<title>Transaction Management</title>
<para>
@@ -1039,9 +1039,9 @@ CALL transaction_test1();
<para>
Transactions cannot be ended when an explicit subtransaction is active.
</para>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-config">
+ <sect2 id="pltcl-config">
<title>PL/Tcl Configuration</title>
<para>
@@ -1113,9 +1113,9 @@ CALL transaction_test1();
</varlistentry>
</variablelist>
- </sect1>
+ </sect2>
- <sect1 id="pltcl-procnames">
+ <sect2 id="pltcl-procnames">
<title>Tcl Procedure Names</title>
<para>
@@ -1131,5 +1131,5 @@ CALL transaction_test1();
when debugging.
</para>
- </sect1>
- </chapter>
+ </sect2>
+ </sect1>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 5bc47a9e71..f841570bc8 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -215,13 +215,7 @@ break is not needed in a wider output rendering.
&trigger;
&event-trigger;
&rules;
-
- &xplang;
- &plsql;
- &pltcl;
- &plperl;
- &plpython;
-
+ &plang;
&spi;
&bgworker;
&logicaldecoding;
diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml
index 31d403c480..2c0acdc0f7 100644
--- a/doc/src/sgml/xplang.sgml
+++ b/doc/src/sgml/xplang.sgml
@@ -1,44 +1,6 @@
<!-- doc/src/sgml/xplang.sgml -->
- <chapter id="xplang">
- <title>Procedural Languages</title>
-
- <indexterm zone="xplang">
- <primary>procedural language</primary>
- </indexterm>
-
- <para>
- <productname>PostgreSQL</productname> allows user-defined functions
- to be written in other languages besides SQL and C. These other
- languages are generically called <firstterm>procedural
- languages</firstterm> (<acronym>PL</acronym>s). For a function
- written in a procedural language, the database server has
- no built-in knowledge about how to interpret the function's source
- text. Instead, the task is passed to a special handler that knows
- the details of the language. The handler could either do all the
- work of parsing, syntax analysis, execution, etc. itself, or it
- could serve as <quote>glue</quote> between
- <productname>PostgreSQL</productname> and an existing implementation
- of a programming language. The handler itself is a
- C language function compiled into a shared object and
- loaded on demand, just like any other C function.
- </para>
-
- <para>
- There are currently four procedural languages available in the
- standard <productname>PostgreSQL</productname> distribution:
- <application>PL/pgSQL</application> (<xref linkend="plpgsql"/>),
- <application>PL/Tcl</application> (<xref linkend="pltcl"/>),
- <application>PL/Perl</application> (<xref linkend="plperl"/>), and
- <application>PL/Python</application> (<xref linkend="plpython"/>).
- There are additional procedural languages available that are not
- included in the core distribution. <xref linkend="external-projects"/>
- has information about finding them. In addition other languages can
- be defined by users; the basics of developing a new procedural
- language are covered in <xref linkend="plhandler"/>.
- </para>
-
- <sect1 id="xplang-install">
+ <sect1 id="xplang">
<title>Installing Procedural Languages</title>
<para>
@@ -226,5 +188,3 @@ CREATE TRUSTED LANGUAGE plperl
</para>
</sect1>
-
-</chapter>
--
2.39.3 (Apple Git-145)
Re: documentation structure
On Thu, Mar 21, 2024 at 10:31 AM Robert Haas <robertmhaas@gmail.com> wrote:
0001 and 0002 are changed. Should 0002 use the include-an-entity
approach as well?
Woops. I meant to say that 0001 and 0002 are *unchanged*.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On 2024-Mar-21, Robert Haas wrote:
On Thu, Mar 21, 2024 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'd follow the extend.sgml precedent: have a file corresponding to the
chapter and containing any top-level text we need, then that includes
a file per sect1.OK, here's a new patch set. I've revised 0003 and 0004 to use this
approach,
Great, thanks. Looking at the index in the PDF after (only) 0003, we
now have this structure
62. Table Access Method Interface Definition ....................................................... 2475
63. Index Access Method Interface Definition ....................................................... 2476
63.1. Basic API Structure for Indexes .......................................................... 2476
63.2. Index Access Method Functions .......................................................... 2479
63.3. Index Scanning ................................................................................ 2485
63.4. Index Locking Considerations ............................................................. 2486
63.5. Index Uniqueness Checks .................................................................. 2487
63.6. Index Cost Estimation Functions ......................................................... 2489
64. Generic WAL Records ................................................................................. 2492
65. Custom WAL Resource Managers ................................................................. 2494
66. Built-in Index Access Methods ...................................................................... 2496
which is a bit odd: why are the two WAL chapters in the middle of the
chapters 62 and 63 talking about AMs? Maybe put 66 right after 63
instead. Also, is it really better to have 62/63 first and 66
later? It sounds to me like 66 is more user-oriented and the other two
are developer-oriented, so I'm inclined to suggest putting them the
other way around, but I'm not really sure about this. (Also, starting
chapter 66 straight with 66.1 BTree without any intro text looks a bit
odd; maybe one short introductory paragraph is sufficient?)
and I've added a new 0005 that does essentially the same
thing for the PL chapters.
I was looking at the PL chapters earlier today too, wondering whether
this would be valuable; but I worry that there are too many
sub-sub-sections there, so it could end up being a bit messy. I didn't
look at the resulting output though.
0001 and 0002 are [un]changed. Should 0002 use the include-an-entity
approach as well?
Shrug, I wouldn't, doesn't look worth it.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No es bueno caminar con un hombre muerto"
Re: documentation structure
On Thu, Mar 21, 2024 at 12:43 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
which is a bit odd: why are the two WAL chapters in the middle of the
chapters 62 and 63 talking about AMs? Maybe put 66 right after 63
instead. Also, is it really better to have 62/63 first and 66
later? It sounds to me like 66 is more user-oriented and the other two
are developer-oriented, so I'm inclined to suggest putting them the
other way around, but I'm not really sure about this. (Also, starting
chapter 66 straight with 66.1 BTree without any intro text looks a bit
odd; maybe one short introductory paragraph is sufficient?)
I had similar thoughts. I think that we should consider some changes
to the chapter ordering, but I didn't want to try to change too many
things all at once, since somebody only has to hate one thing about
the patch to sink the whole thing.
But since you brought it up, what I've been thinking about is that the
whole division into parts might need to be rethought a bit. I feel
like "VII. Internals" is a mix of about four different kinds of
content. First, the biggest portion of it is information about
developing certain kinds of C extensions -- all the "Writing a
Whatever" chapters, the "Whatever Access Method Interface Definition"
chapters, "Generic WAL Records", "Custom WAL Resource Managers", and
all the index-related chapters. Second, we've got some information
that I think is mainly of interest to people developing PostgreSQL
itself, namely, "PostgreSQL Coding Conventions", "Native Language
Support", and "System Catalog Declarations and Initial Contents". You
*might* care about these if you're developing extensions, or even if
you're not a developer at all, but then again you might not. Third,
we've got some reference material, namely "System Catalogs", "System
Views", and perhaps "Frontend/Backend Protocol". I distinguish these
from the previous two categories because I think you could care about
this stuff as a random user, or a developer of products that
interoperate with PostgreSQL but don't link with it or share any
common code. Finally, there's just a bunch of random bits and bobs
that we've decided to document here for one reason or another, either
because somebody else did a bunch of the work, like "Overview of
PostgreSQL Internals", or because some developer did something and
someone said "hey, that should be documented!", like "Backup Manifest
Format."
So my first thought is to pull out the stuff that's mainly for
PostgreSQL core developers and move it to an appendix. I propose we
create an appendix called "Developer Guide" and that it absorb the
existing appendix I, "The Source Code Repository", possibly all or
part of appendix J, "Documentation", and the chapters from "VII.
Internals" that are mostly of developer interest. I think that
possibly some of what's in "J. Documentation" should actually be moved
into the "Installation" chapter where we talk about building the
source code, because it doesn't make much sense to document the build
tool chain in one part of the documentation and the documentation
toolchain someplace else entirely, but "J.6. Style Guide" is developer
information, not build instructions.
My second thought is that the stuff from "VII. Internals" that I
categorized as reference material should move into section "VI.
Reference". I think we should also consider moving appendix F,
"Additional Supplied Modules and Extensions," and appendix G,
"Additional Supplied Programs" to the reference section. However,
prior to doing that, I think that appendix G needs some cleanup or
possibly we should just find a way to remove it outright. We're
shipping an appendix G with two major subsections, one of which is
completely empty and has been since v14, and the other of which
contains only two things. I think we should just remove the empty
sub-section entirely. I'm not sure what to do about the only with only
2 things in it (vacuumlo and oid2name). Would it be a bad idea to just
merge those bits into the client applications reference section?
My third thought is about what to do with the material in "VII.
Internals" that is about developing specific kind of extensions, like,
say, "Writing a Foreign Data Wrapper." If you look at "V. Server
Programming", you see that we actually have some very similar sections
there, like chapter 47, "Background Worker Processes" and chapter 50,
"Archive Modules". I think it's not very clear in the current
structure where topics that are relevant for extension developers
should go under "Server Programming" or under "Internals", and it
looks to me like different people have just done different things and
it's all a bit haphazard. One idea is to decide that the correct
answer is "Server Programming" and move all of the internals chapters
that fall into this category over to there. I don't think this is the
right answer, because that section also contains information about a
bunch of stuff that's strictly SQL-level, like rules and triggers. So
what I think we should do is create either [A] a new top-level part,
just before or just after what's currently called "VI. Reference" or
[B] a new appendix or [C] a new "Reference" section, that is
specifically for documentation of server APIs intended for extension
use. And then all the chapters under "V. Server Programming" or "VII.
Internals" that are documenting APIs would get moved there.
If we adopted all of the patches that I proposed in my previous email
and all of the suggestions that I just dropped in the preceding wall
of text, then the internals section would be left with only these
chapters:
- Overview of PostgreSQL Internals
- Genetic Query Optimizer
- Database Physical Storage
- Transaction Processing
- How the Planner Uses Statistics
- Backup Manifest Format
A lot of those chapters are pretty dated and maybe not that useful in
2024, but this email is already long enough and full of
sufficiently-aggressive proposals that I'm not inclined to opine too
much further on what we might want to do if and when we've done
everything I just proposed. For now, suffice it to say that I think we
might choose to either rewrite and expand some of these to make them
more useful, or demote some of them to some less prominent place in
the documentation, or just delete some of them entirely; but we can
figure that out if and when we get there.
I was looking at the PL chapters earlier today too, wondering whether
this would be valuable; but I worry that there are too many
sub-sub-sections there, so it could end up being a bit messy. I didn't
look at the resulting output though.
That thought occurred to me as well. I certainly think that if we
perform the sort of aggressive purging of the top-level index for
which I'm advocating, there are going to be some people who are grumpy
that the stuff they're trying to find isn't where it used to be, or
who legitimately had trouble finding the content that they want. It
seems to me that if you're looking for the documentation on one of the
individual procedural languages and you don't see it, you'll try
clicking on "Procedural Languages" and then you'll find that it's now
under there. Now, what's maybe a bit unfortunate is that chapter
indexes only show two levels of section headings, and the PL/pgsql
chapter in particular has a lot of <sect2> items. If those get demoted
to <sect3> as I am proposing, they won't show up the chapter index any
more. I do think there's a possibility that this could be a problem
for someone.
On the other hand, the table of contents for
https://www.postgresql.org/docs/devel/plpgsql.html is so long right
now that it doesn't fit on the page, so maybe losing a level of
subsections won't be so bad. Alternately, maybe we could revise the
structure of the section a bit to ameliorate the problem. It seems to
me that most of the first-level section headers are actually pretty
clear about what you're likely to find underneath. If you're looking
for WHILE and you see a section called "Control Structures", it seems
like you're chances of guessing that WHILE will be underneath that
section are pretty good. The major exception that I see is 45.2,
"Basic Statements," which isn't very clear about what might be covered
there. But what if we split that apart into separate sections called
"Assignment", "Executing SQL", and "Doing Nothing at All"? And maybe
we'd even pull "Returning" out of "Control Structures" as well. I
think that would be clear enough for people to find what they need
without the extra level of headers.
(For the sake of completeness, let me note that PL/python and PL/perl
have a few <sect2> headings as well, but I don't think it would create
a problem for users if all of those got changed to <sect3>. PL/Tcl has
no <sect2> headings.)
I'm not sure if this kind of rearrangement is actually necessary or
not; but my point here is that if we think that people will have
problems or we find out that they actually did have problems, we can
look at doing this kind of stuff to compensate. What I don't think we
should do is decide that the only workable solution is to keep having
so many separate chapters at the top level. We're way, way beyond the
point where you can easily find anything on that page, and trying to
emphasize everything just ends up emphasizing nothing. We need to push
in a direction where every chapter and every appendix is expected to
have a large amount of content under it, so that the top-level index
becomes a way of finding the kind of content you want (SQL reference
pages, extension APIs, built-in SQL-callable functions, whatever) and
then you use that page to find the specific content that you want
within that category.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Wed, Mar 20, 2024 at 9:43 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Mar 19, 2024 at 5:39 PM Andrew Dunstan <andrew@dunslane.net>
wrote:+many for improving the index.
Here's a series of four patches.
I reviewed the most recent set of 5 patches.
Taken together, they cut down the
number of numbered chapters from 76 to 68. I think we could easily
save that much again if I wrote a few more patches along similar
lines, but I'm posting these first to see what people think.0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from Source Code" chapter and retitled it
"Installation".
Makes sense
0002 removes the "Monitoring Disk Usage" chapter by folding it into
the immediately-preceding "Monitoring Database Activity" chapter. I
kind of feel like the "Monitoring Disk Usage" chapter might be in need
of a bigger rewrite or just outright removal, but there's surely not
enough content here to justify making it a top-level chapter.
Just going to note that the section on the cumulative statistics views
being a single page is still a strongly bothersome issue here. Though the
quick fix actually requires upgrading the section to chapter status...
Maybe we can stub out that section in the "Monitoring Database Activity"
chapter and move that entire section after "System Views" in the Internals
part?
I agree with subordinating Monitoring Disk Usage.
0003 merges all of the "Internals" chapters whose names are the names
of built-in index access methods (Btree, Gin, etc.) into a single
chapter called "Built-In Index Access Methods". All of these chapters
have a very similar structure and none of them are very long, so it
makes a lot of sense, at least in my mind, to consolidate them into
one.
One of the more impactful and wanted improvements, IMO.
0004 merges the "Generic WAL Records" and "Custom WAL Resource
Managers" chapter together, creating a new chapter called "Write Ahead
Logging for Extensions".
The positioning of this and the preceding Built-in Index Access Methods
chapter seem like they should be switched.
If this sticks we should add an introductory paragraph for the chapter.
and I've added a new 0005 that does essentially the same
thing for the PL chapters.
The following page needs to be reworded to take the new structure into
account:
https://www.postgresql.org/docs/current/xfunc-pl.html
Not having pl/pgsql appear on the main ToC seems like a loss but the others
make sense and a special exception for it probably isn't warranted.
Maybe "pl/pgsql and Other Procedural Languages" as the title?
David J.
Re: documentation structure
On Thu, Mar 21, 2024 at 11:30 AM Robert Haas <robertmhaas@gmail.com> wrote:
My second thought is that the stuff from "VII. Internals" that I
categorized as reference material should move into section "VI.
Reference". I think we should also consider moving appendix F,
"Additional Supplied Modules and Extensions," and appendix G,
"Additional Supplied Programs" to the reference section.
For "VI. Reference" I propose the following Chapters:
SQL Commands
PL/pgSQL
Cumulative Statistics Views
System Views
System Catalogs
Client Applications
Server Applications
Modules and Extensions
-- Remove Appendix G (Programs) altogether and just note for the two that
are listed that they are in contrib as opposed to core.
-- The PostgreSQL qualifier doesn't seem helpful and once you add the
additional chapters its unusual presence stands out even more.
-- PL/pgSQL gets its own reference chapter since we wrote it. Stuff like
Perl and Python have entire books that the user can consult as reference
material for those languages.
David J.
Re: documentation structure
On 19.03.24 14:50, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
It's actually not very odd, the reference section is using <reference> elements
and we had missed the arabic numerals setting on those. The attached fixes
that for me. That being said, we've had roman numerals for the reference
section since forever (all the way down to the 7.2 docs online has it) so maybe
it was intentional?I'm quite sure it *was* intentional. Maybe it was a bad idea, but
it's not that way simply because nobody thought about it.
Looks to me it was just that way because it's the default setting of the
stylesheets.
Re: documentation structure
On 20.03.24 17:43, Robert Haas wrote:
0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from Source Code" chapter and retitled it
"Installation".
But this separation was explicitly added a few years ago, because most
people just want to read about the binaries.
Re: documentation structure
On 21.03.24 15:31, Robert Haas wrote:
On Thu, Mar 21, 2024 at 9:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'd follow the extend.sgml precedent: have a file corresponding to the
chapter and containing any top-level text we need, then that includes
a file per sect1.OK, here's a new patch set. I've revised 0003 and 0004 to use this
approach, and I've added a new 0005 that does essentially the same
thing for the PL chapters.
I'm highly against this. If I want to read about PL/Python, why should
I have to wade through PL/Perl and PL/Tcl?
I think, abstractly, in a book, PL/Python should be a chapter of its
own. Just like GiST should be a chapter of its own. Because they are
self-contained topics.
Re: documentation structure
On 22 Mar 2024, at 00:33, Peter Eisentraut <peter@eisentraut.org> wrote:
On 19.03.24 14:50, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
It's actually not very odd, the reference section is using <reference> elements
and we had missed the arabic numerals setting on those. The attached fixes
that for me. That being said, we've had roman numerals for the reference
section since forever (all the way down to the 7.2 docs online has it) so maybe
it was intentional?I'm quite sure it *was* intentional. Maybe it was a bad idea, but
it's not that way simply because nobody thought about it.Looks to me it was just that way because it's the default setting of the stylesheets.
That's quite possible. I don't have strong opinions on whether we should
change, or keep it the way it is.
--
Daniel Gustafsson
Re: documentation structure
On Fri, Mar 22, 2024 at 01:12:30AM +0100, Daniel Gustafsson wrote:
On 22 Mar 2024, at 00:33, Peter Eisentraut <peter@eisentraut.org> wrote:
On 19.03.24 14:50, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
It's actually not very odd, the reference section is using <reference> elements
and we had missed the arabic numerals setting on those. The attached fixes
that for me. That being said, we've had roman numerals for the reference
section since forever (all the way down to the 7.2 docs online has it) so maybe
it was intentional?I'm quite sure it *was* intentional. Maybe it was a bad idea, but
it's not that way simply because nobody thought about it.Looks to me it was just that way because it's the default setting of the stylesheets.
That's quite possible. I don't have strong opinions on whether we should
change, or keep it the way it is.
If we can't justify why it should be different, it should be like the
surrounding sections.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
On Thu, Mar 21, 2024 at 6:32 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
Just going to note that the section on the cumulative statistics views being a single page is still a strongly bothersome issue here. Though the quick fix actually requires upgrading the section to chapter status...
Yeah, I've been bothered by this in the past, too. I'm not very keen
to start promoting things to the top-level, though. I think we need a
more thoughtful fix than that.
One question I have is why all of these views are documented here
rather than in chapter 53, "System Views," because surely they are
system views. I feel like if our documentation index weren't a mile
long and if you could easily find the entry for "System Views," that's
where you would naturally look for these details. I don't think it's
natural for a user to expect that most of the system views are going
to be documented in section VII, chapter 53 but one particular kind is
going to be documented in section III, chapter 27, under a chapter
title that gives no hint that it will document any views.
Maybe "pl/pgsql and Other Procedural Languages" as the title?
I guess I have a hard time seeing this as an improvement. It would
help someone who knows that plpgsql exists but doesn't know that it
falls into the general category called procedural languages, but I
suspect that's not a very common confusion. I think it's better to
keep the chapter titles short and to the point.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Thu, Mar 21, 2024 at 7:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
On 20.03.24 17:43, Robert Haas wrote:
0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from Source Code" chapter and retitled it
"Installation".But this separation was explicitly added a few years ago, because most
people just want to read about the binaries.
I really doubt that this is true. I've been installing software on
UNIX-like operating systems for more than 30 years now, and I don't
think there's been a single time when I have ever consulted the
documentation for a software package to find the download location for
that package. When I first started out, everything was ftp rather than
www, so you went to ftp.whatever.{com,org,net,gov,edu} and tried to
download the distribution bundle, and then you untarred it and ran
configure and make. Then you read the README or the documentation or
whatever afterward. These days, I think what people do is either (a)
use their package manager to install PostgreSQL and then come to the
documentation afterward to find out how to use it or (b) do a search
for "PostgreSQL download" and click on whatever comes up. I'm not
saying there's never been a user who made use of this section of the
documentation to find the download location, but surely the normal
thing to do if you come to www.postgresql.org and you want to download
the software is to click "Download" on the nav bar, not
"Documentation," then a specific version, then chapter 16, then the
exact same download link that's already there on the nav bar.
I do agree that it is very questionable whether "Installation from
Source Code" is of sufficient interest to ordinary users to justify
including it in "III. Server Administration." Most people, probably
including many extension developers, are only going to install the
binary packages. But the solution to that isn't to have a
four-sentence chapter telling me about a download location that I
likely found long before I looked at the documentation, and that I can
certainly find very easily without needing the documentation. Rather,
what we should do if we think that installing from source code is of
marginal interest is move it to an appendix. As I said to Alvaro
yesterday, I think that a "Developer Guide" appendix could be a good
place to house a number of things that currently have toplevel
chapters but don't really need them because they're only of interest
to a small minority of users. This might be another thing that could
go there.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On 22.03.24 13:50, Robert Haas wrote:
On Thu, Mar 21, 2024 at 7:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
On 20.03.24 17:43, Robert Haas wrote:
0001 removes the "Installation from Binaries" chapter. The whole thing
is four sentences. I moved the most important information into the
"Installation from Source Code" chapter and retitled it
"Installation".But this separation was explicitly added a few years ago, because most
people just want to read about the binaries.I really doubt that this is true.
Here is the thread:
/messages/by-id/CABUevExRCf8waYOsrCO-QxQL50XGapMf5dnWScOXj7X=MXW--g@mail.gmail.com
Re: documentation structure
On Thu, Mar 21, 2024 at 7:40 PM Peter Eisentraut <peter@eisentraut.org> wrote:
I'm highly against this. If I want to read about PL/Python, why should
I have to wade through PL/Perl and PL/Tcl?I think, abstractly, in a book, PL/Python should be a chapter of its
own. Just like GiST should be a chapter of its own. Because they are
self-contained topics.
On the other hand, in a book, chapters tend to be of relatively
uniform length. People don't usually write a book with some chapters
that are 100+ pages long, and others that are a single page, or even
just a couple of sentences. I mean, I'm sure it's been done, but it's
not a normal way to write a book.
And I don't believe that if someone were writing a physical book about
PostgreSQL from scratch, they'd ever end up with a top-level chapter
that looks anything like our GiST chapter. All of the index AM
chapters are quite obviously clones of each other, and they're all
quite short. Surely you'd make them sections within a chapter, not
entire chapters.
I do agree that PL/pgsql is more arguable. I can imagine somebody
writing a book about PostgreSQL and choosing to make that topic into a
whole chapter.
However, I also think that people don't make decisions about what
should be a chapter in a vacuum. If you've got 100 people writing a
book together, which is essentially what we actually do have, and each
of those people makes decisions in isolation about what is worthy of
being a chapter, then you end up with exactly the kind of mess that we
now have. Some chapters are long and some are short. Some are
well-written and some are poorly written. Some are updated regularly
and others have hardly been touched in a decade. Books have editors to
straighten out those kinds of inconsistencies so that there's some
uniformity to the product as a whole.
The problem with that, of course, is that it invites bike-shedding. As
you say, every decision that is reflected in our documentation was
made for some reason, and most of them will have been made by
prominent, active committers. So discussions about how to improve
things can easily bog down even when people agree on the overall
goals, simply because few individual changes find consensus. I hope
that doesn't happen here, because I think most people who have
commented so far agree that there is a problem here and that we should
try to fix it. Let's not let the perfect be the enemy of the good.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 22, 2024 at 9:35 AM Peter Eisentraut <peter@eisentraut.org> wrote:
But this separation was explicitly added a few years ago, because most
people just want to read about the binaries.I really doubt that this is true.
Here is the thread:
/messages/by-id/CABUevExRCf8waYOsrCO-QxQL50XGapMf5dnWScOXj7X=MXW--g@mail.gmail.com
Sorry. I didn't mean to dispute the point that the section was added a
few years ago, nor the point that most people just want to read about
the binaries. I am confident that both of those things are true. What
I do want to dispute is that having a four-sentence chapter in the
documentation index that tells people something they can find much
more easily without using the documentation at all is a good plan. I
agree with the concern that Magnus expressed on the thread, i.e:
It's kind of strange that if you start your PostgreSQL journey by reading our instructions, you get nothing useful about installing PostgreSQL from binary packages other than "go ask somebody else about it".
But I don't agree that this was the right way to address that problem.
I think it would have been better to just add the download link to the
existing installation chapter. That's actually what we had in chapter
18, "Installation from Source Code on Windows", since removed. But for
some reason we decided that on non-Windows platforms, it needed a
whole new chapter rather than an extra sentence in the existing one. I
think that's massively overkill.
Alternately, I think it would be reasonable to address the concern by
just moving all the stuff about building from source code to an
appendix, and assume people can figure out how to download the
software without us needing to say anything in the documentation at
all. What was weird about the state before that patch, IMHO, was that
we both talked about building from source code and didn't talk about
binary packages. That can be addressed either by adding a mention of
binary packages, or by deemphasizing the idea of installing from
source code.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 22, 2024 at 7:10 AM Robert Haas <robertmhaas@gmail.com> wrote:
That's actually what we had in chapter
18, "Installation from Source Code on Windows", since removed. But for
some reason we decided that on non-Windows platforms, it needed a
whole new chapter rather than an extra sentence in the existing one. I
think that's massively overkill.
I agree with the premise that we should have a single chapter, in the main
documentation flow, named "Installation". It should cover the
architectural overview and point people to where they can find the stuff
they need to install PostgreSQL in the various ways available to them. I
agree with moving the source installation material to the appendix. None
of the sections under Installation would then actually detail how to
install the software since that isn't something the project itself handles
but has delegated to packagers for the vast majority of cases and the
source install details are in the appendix for the one "supported"
mechanism that most people do not use.
David J.
Re: documentation structure
On Fri, Mar 22, 2024 at 11:50 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
On Fri, Mar 22, 2024 at 7:10 AM Robert Haas <robertmhaas@gmail.com> wrote:
That's actually what we had in chapter
18, "Installation from Source Code on Windows", since removed. But for
some reason we decided that on non-Windows platforms, it needed a
whole new chapter rather than an extra sentence in the existing one. I
think that's massively overkill.I agree with the premise that we should have a single chapter, in the main documentation flow, named "Installation". It should cover the architectural overview and point people to where they can find the stuff they need to install PostgreSQL in the various ways available to them. I agree with moving the source installation material to the appendix. None of the sections under Installation would then actually detail how to install the software since that isn't something the project itself handles but has delegated to packagers for the vast majority of cases and the source install details are in the appendix for the one "supported" mechanism that most people do not use.
Hmm, that's not quite the same as my position. I'm fine with either
moving the installation from source material to an appendix, or
leaving it where it is. But I'm strongly against continuing to have a
chapter with four sentences in it that says to use the same download
link that is on the main navigation bar of every page on the
postgresql.org web site. We're never going to get the chapter index
down to a reasonable size if we insist on having chapters that have a
totally de minimis amount of content.
So my feeling is that if we keep the installation from source material
where it is, then we can make it also mention the download link, just
as we used to do in the installation-on-windows chapter. But if we
banish installation from source to the appendixes, then we shouldn't
keep a whole chapter in the main documentation to tell people
something that is anyway obvious. I don't really think that material
needs to be there at all, but if we want to have it, surely we can
find someplace to put it such that it doesn't require a whole chapter
to say that and nothing else. It could for example go at the beginning
of the "Server Setup and Operation" chapter, for instance; if that
were the first chapter of section III, I think that would be natural
enough.
I notice that you say that the "Installation" section should "cover
the architectural overview and point people to where they can find the
stuff they need to install PostgreSQL in the various ways available to
them" so maybe you're not imagining a four-sentence chapter, either.
But this project is going to be impossible unless we stick to limited
goals. We can, and should, rewrite some sections of the documentation
to be more useful; but if we try to do that as part of the same
project that aims to tidy up the index, the chances of us getting
stuck in an endless bikeshedding loop go from "high" to "certain". So
I don't want to hypothesize the existence of an installation chapter
that isn't any of the things we have today. Let's try to get the
things we have into places that make sense, and then consider other
improvements separately.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 22, 2024, 09:32 Robert Haas <robertmhaas@gmail.com> wrote:
I notice that you say that the "Installation" section should "cover
the architectural overview and point people to where they can find the
stuff they need to install PostgreSQL in the various ways available to
them" so maybe you're not imagining a four-sentence chapter, either.
Fair point but I posit that new users are looking for a chapter named
Installation in the documentation. At least the ones willing to read
documentation. Having two of them isn't needed but having zero doesn't
make sense either.
The current proposal does that so I'm ok as-is but it can be further
improved by moving source install talk elsewhere and having the
installation chapter redirect the reader there for details. I'm not
concerned with how long or short the resultant installation chapter is.
David J.
Show quoted text
Re: documentation structure
On Fri, Mar 22, 2024 at 08:32:14AM -0400, Robert Haas wrote:
On Thu, Mar 21, 2024 at 6:32 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:Just going to note that the section on the cumulative statistics views being a single page is still a strongly bothersome issue here. Though the quick fix actually requires upgrading the section to chapter status...
Yeah, I've been bothered by this in the past, too. I'm not very keen
to start promoting things to the top-level, though. I think we need a
more thoughtful fix than that.One question I have is why all of these views are documented here
rather than in chapter 53, "System Views," because surely they are
system views. I feel like if our documentation index weren't a mile
long and if you could easily find the entry for "System Views," that's
where you would naturally look for these details. I don't think it's
natural for a user to expect that most of the system views are going
to be documented in section VII, chapter 53 but one particular kind is
going to be documented in section III, chapter 27, under a chapter
Well, until this commit in 2022, the system views were _under_ the
system catalogs chapter:
commit 64d364bb39c
Author: Bruce Momjian <bruce@momjian.us>
Date: Thu Jul 14 16:07:12 2022 -0400
doc: move system views section to its own chapter
Previously it was inside the system catalogs chapter.
Reported-by: Peter Smith
Discussion: /messages/by-id/CAHut+PsMc18QP60D+L0hJBOXrLQT5m88yVaCDyxLq34gfPHsow@mail.gmail.com
Backpatch-through: 15
The thread contains more discussion the issue, and I think it still needs help:
/messages/by-id/CAHut+PsMc18QP60D+L0hJBOXrLQT5m88yVaCDyxLq34gfPHsow@mail.gmail.com
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
On Fri, Mar 22, 2024 at 1:35 PM Bruce Momjian <bruce@momjian.us> wrote:
One question I have is why all of these views are documented here
rather than in chapter 53, "System Views," because surely they are
system views. I feel like if our documentation index weren't a mile
long and if you could easily find the entry for "System Views," that's
where you would naturally look for these details. I don't think it's
natural for a user to expect that most of the system views are going
to be documented in section VII, chapter 53 but one particular kind is
going to be documented in section III, chapter 27, under a chapterWell, until this commit in 2022, the system views were _under_ the
system catalogs chapter:
Even before that commit, the statistics collector views were
documented in a completely separate part of the documentation from all
of the other system views.
I think that commit was a good idea, even though it made the top-level
documentation index bigger, because in v14, the "System Catalogs"
chapter looks like this:
...
52.61. pg_ts_template
52.62. pg_type
52.63. pg_user_mapping
52.64. System Views
52.65. pg_available_extensions
52.66. pg_available_extension_versions
52.67. pg_backend_memory_contexts
...
If you were actually looking for the section called "System Views",
you weren't likely to see it here unless you already knew it was
there, because it was 64 items into a 97-item list. Having one of
these two sections inside the other just doesn't work at all. We could
have alternatively chosen to have one chapter with two <sect1> tags
inside of it, but I think what you actually did was perfectly fine.
IMHO, "System Views" is important enough (and big enough) that giving
it its own chapter is perfectly reasonable.
But that all seems like a separate question from why we have the
statistic collector views in a completely different part of the
documentation from the rest of the system views. My guess is that it's
just kind of a historical accident, but maybe there was some other
logic to it.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 22, 2024 at 02:19:29PM -0400, Robert Haas wrote:
If you were actually looking for the section called "System Views",
you weren't likely to see it here unless you already knew it was
there, because it was 64 items into a 97-item list. Having one of
these two sections inside the other just doesn't work at all. We could
have alternatively chosen to have one chapter with two <sect1> tags
inside of it, but I think what you actually did was perfectly fine.
IMHO, "System Views" is important enough (and big enough) that giving
it its own chapter is perfectly reasonable.But that all seems like a separate question from why we have the
statistic collector views in a completely different part of the
documentation from the rest of the system views. My guess is that it's
just kind of a historical accident, but maybe there was some other
logic to it.
I assume statistics collector views are in "Monitoring Database
Activity" because that is their purpose.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
On Fri, Mar 22, 2024 at 11:19 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Mar 22, 2024 at 1:35 PM Bruce Momjian <bruce@momjian.us> wrote:
But that all seems like a separate question from why we have the
statistic collector views in a completely different part of the
documentation from the rest of the system views. My guess is that it's
just kind of a historical accident, but maybe there was some other
logic to it.
The details under-pinning the cumulative statistics subsystem are
definitely large enough to warrant their own subsection. And it isn't like
placing them into the monitoring chapter is wrong and aside from a couple
of views those under System Views don't fit into what we've defined as
monitoring. I don't have any desire to lump them under the generic system
views; which itself could probably use a level of categorization since the
nature of pg_locks and pg_cursors is decidedly different than pg_indexes
and pg_config. This all becomes more appealing to work on once we solve
the problem of all sect2 entries being placed on a single page.
I struggled for a long while where I'd always look for pg_stat_activity
under system views instead of monitoring. Amending my prior suggestion in
light of this I would suggest we move the Cumulative Statistics Views into
Reference but as its own Chapter, not part of System Views, and change its
name to "Monitoring Views" (going more generalized here feels like a win to
me). I'd move pg_locks, pg_cursors, pg_backend_memory_contexts,
pg_prepared_*, pg_shmem_allocations, and pg_replication_*. Those all have
the same general monitoring nature to them compared to the others that
basically provide details regarding schema and static or session
configuration.
The original server admin monitoring section can go into detail regarding
Cumulative Statistics versus other kinds of monitoring. We can use
section ordering to fulfill logical grouping desires until we are able to
make section3 entries appear on their own pages.
David J.
Re: documentation structure
On Fri, Mar 22, 2024 at 2:59 PM Bruce Momjian <bruce@momjian.us> wrote:
I assume statistics collector views are in "Monitoring Database
Activity" because that is their purpose.
Well, yes. :-)
But the point is that all other statistics views are in a single
section regardless of their purpose. We don't document pg_roles in the
"Database Roles" chapter, for example.
And on the flip side, pg_locks and pg_replication_origin_status are
also for monitoring database activity, but they're in the "System
Views" chapter anyway. The only system views that are in "Monitoring
Database Activity" rather than "System Views" are the ones where the
name starts with "pg_stat_".
So the reason you state is why these views are under "Monitoring
Database Activity" rather than a chapter chosen at random. But it
doesn't really explain why they're separate from the other system
views at all. That seems to be a pretty much random choice, AFAICT.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 22, 2024 at 03:13:29PM -0400, Robert Haas wrote:
On Fri, Mar 22, 2024 at 2:59 PM Bruce Momjian <bruce@momjian.us> wrote:
I assume statistics collector views are in "Monitoring Database
Activity" because that is their purpose.Well, yes. :-)
But the point is that all other statistics views are in a single
section regardless of their purpose. We don't document pg_roles in the
"Database Roles" chapter, for example.And on the flip side, pg_locks and pg_replication_origin_status are
also for monitoring database activity, but they're in the "System
Views" chapter anyway. The only system views that are in "Monitoring
Database Activity" rather than "System Views" are the ones where the
name starts with "pg_stat_".So the reason you state is why these views are under "Monitoring
Database Activity" rather than a chapter chosen at random. But it
doesn't really explain why they're separate from the other system
views at all. That seems to be a pretty much random choice, AFAICT.
I agree and they should be with the other views. I was just explaining
why, at the time, I didn't touch them.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
On Fri, Mar 22, 2024 at 3:17 PM Bruce Momjian <bruce@momjian.us> wrote:
I agree and they should be with the other views. I was just explaining
why, at the time, I didn't touch them.
Ah, OK. That makes total sense.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On 22.03.24 14:59, Robert Haas wrote:
And I don't believe that if someone were writing a physical book about
PostgreSQL from scratch, they'd ever end up with a top-level chapter
that looks anything like our GiST chapter. All of the index AM
chapters are quite obviously clones of each other, and they're all
quite short. Surely you'd make them sections within a chapter, not
entire chapters.I do agree that PL/pgsql is more arguable. I can imagine somebody
writing a book about PostgreSQL and choosing to make that topic into a
whole chapter.
Yeah, I think there is probably a range of of things from pretty obvious
to mostly controversial.
Re: documentation structure
On 22.03.24 15:10, Robert Haas wrote:
Sorry. I didn't mean to dispute the point that the section was added a
few years ago, nor the point that most people just want to read about
the binaries. I am confident that both of those things are true. What
I do want to dispute is that having a four-sentence chapter in the
documentation index that tells people something they can find much
more easily without using the documentation at all is a good plan.
I think a possible problem we need to consider with these proposals to
combine chapters is that they could make the chapters themselves too
deep and harder to navigate. For example, if we combined the
installation from source and binaries chapters, the structure of the new
chapter would presumably be
<chapter> Installation
<sect1> Installation from Binaries
<sect1> Installation from Source
<sect2> Requirements
<sect2> Getting the Source
<sect2> Building and Installation with Autoconf and Make
<sect2> Building and Installation with Meson
etc.
This would mean that the entire "Installation from Source" part would be
rendered on a single HTML page.
The rendering can be adjusted to some degree, but then we also need to
make sure any new chunking makes sense in other chapters. (And it might
also change a bunch of externally known HTML links.)
I think maybe more could also be done at the top-level structure, too.
Right now, we have <book> -> <part> -> <chapter>. We could add <set> on
top of that.
We could also play with CSS or JavaScript to make the top-level table of
contents more navigable, with collapsing subsections or whatever.
We could also render additional tables of contents or indexes, so there
is more than one way to navigate into the content from the top.
We could also build better search.
Re: documentation structure
On Mon, Mar 25, 2024 at 11:40 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I think a possible problem we need to consider with these proposals to
combine chapters is that they could make the chapters themselves too
deep and harder to navigate. For example, if we combined the
installation from source and binaries chapters, the structure of the new
chapter would presumably be
I agree with this in theory, but in practice I think the patches that
I posted don't have this issue to a degree that is problematic, and I
posted some specific proposals on adjustments that we could make to
ameliorate the problem if other people feel differently.
I think maybe more could also be done at the top-level structure, too.
Right now, we have <book> -> <part> -> <chapter>. We could add <set> on
top of that.We could also play with CSS or JavaScript to make the top-level table of
contents more navigable, with collapsing subsections or whatever.We could also render additional tables of contents or indexes, so there
is more than one way to navigate into the content from the top.We could also build better search.
These are all reasonable ideas. I think some better CSS and JavaScript
could definitely help, and I also wondered whether the entrypoint to
the documentation has to be the index page, or whether it could maybe
be a page we've crafted specifically for that purpose, that might
include some text as well as a bunch of links.
But that having been said, I don't believe that any of those ideas (or
anything else we do) will obviate the need for some curation of the
toplevel index. If you're going to add another level, as you propose
in the first point, you still need to make decisions about which
things properly go at which levels. If you're going to allow for
collapsing subsections, you still want the overall tree in which
subsections are be expanded and collapsed to make logical sense. If
you have multiple ways to navigate to the content, one of them will
probably be still the index, and it should be good. And good search is
good, but it shouldn't be the only convenient way to find the content.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
OK, so I'm coming back to this thread after giving it a few days to
cool off. My last series of patches proposed to do five things:
1. Merge the four-sentence "Installation from Binaries" chapter back
into "Installation from Source". I thought this was a slam-dunk, but
Peter pointed out that exactly the opposite of this was done a few
years ago to create the "Installation from Binaries" chapter in the
first place. Based on subsequent discussion, what I'm now inclined to
do is come up with a new proposal that involves moving the information
about compiling from source to an appendix. So never mind about this
one for now.
2. Demote "Monitoring Disk Usage" from a chapter on its own to a
section of the "Monitoring Database Activity" chapter. I haven't seen
any objections to this, and I'd like to move ahead with it.
3. Merge the separate chapters on various built-in index AMs into one.
Peter didn't think this was a good idea, but Tom and Alvaro's comments
focused on how to do it mechanically, and on whether the chapters
needed to be reordered afterwards, which I took to mean that they were
OK with the basic concept. David Johnston was also clearly in favor of
it. So I'd like to move ahead with this one, too.
4. Consolidate the "Generic WAL Records" and "Custom WAL Resource
Managers" chapters, which cover related topics, into a single one. I
didn't see anyone object to this, but David Johnston pointed out that
the patch I posted was a few bricks short of a load, because it really
needed to put some introductory text into the new chapter. I'll study
this a bit more and propose a new patch that does the same thing a bit
more carefully than my previous version did.
5. Consolidate all of the procedural language chapters into one. This
was clearly the most controversial part of the proposal. I'm going to
lay this one aside for now and possibly come back to it at a later
time.
I hope that this way of proceeding makes sense to people.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Mar 29, 2024 at 9:40 AM Robert Haas <robertmhaas@gmail.com> wrote:
2. Demote "Monitoring Disk Usage" from a chapter on its own to a
section of the "Monitoring Database Activity" chapter. I haven't seen
any objections to this, and I'd like to move ahead with it.3. Merge the separate chapters on various built-in index AMs into one.
Peter didn't think this was a good idea, but Tom and Alvaro's comments
focused on how to do it mechanically, and on whether the chapters
needed to be reordered afterwards, which I took to mean that they were
OK with the basic concept. David Johnston was also clearly in favor of
it. So I'd like to move ahead with this one, too.
I committed these two patches.
4. Consolidate the "Generic WAL Records" and "Custom WAL Resource
Managers" chapters, which cover related topics, into a single one. I
didn't see anyone object to this, but David Johnston pointed out that
the patch I posted was a few bricks short of a load, because it really
needed to put some introductory text into the new chapter. I'll study
this a bit more and propose a new patch that does the same thing a bit
more carefully than my previous version did.
Here is a new version of this patch. I think this is v18 material at
this point, absent an outcry to the contrary. Sometimes we're flexible
about doc patches.
--
Robert Haas
EDB: http://www.enterprisedb.com
Attachments:
v3-0001-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchapplication/octet-stream; name=v3-0001-docs-Consolidate-into-new-WAL-for-Extensions-chap.patchDownload
From 8a57b79219e2c400532af11046400814816de391 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Mon, 1 Apr 2024 11:25:29 -0400
Subject: [PATCH v3] docs: Consolidate into new "WAL for Extensions" chapter.
Previously, we had consecutive, very short chapters called "Generic
WAL" and "Custom WAL Resource Managers," explaining different approaches
to the same problem. Merge them into a single chapter. Explain most
of the differences between the approaches in the chapter's
introductory text, rather than in the individual sections.
Per discussion, don't consolidate all of the SGML into a single file;
instead, each <sect1> has its own file, and there's an additional one
for the chapter as a whole.
---
doc/src/sgml/custom-rmgr.sgml | 11 ++++------
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/generic-wal.sgml | 14 +++---------
doc/src/sgml/postgres.sgml | 3 +--
doc/src/sgml/wal-for-extensions.sgml | 32 ++++++++++++++++++++++++++++
5 files changed, 41 insertions(+), 20 deletions(-)
create mode 100644 doc/src/sgml/wal-for-extensions.sgml
diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
index 0d98229295..3032b2dc0d 100644
--- a/doc/src/sgml/custom-rmgr.sgml
+++ b/doc/src/sgml/custom-rmgr.sgml
@@ -1,10 +1,10 @@
<!-- doc/src/sgml/custom-rmgr.sgml -->
-<chapter id="custom-rmgr">
+<sect1 id="custom-rmgr">
<title>Custom WAL Resource Managers</title>
<para>
- This chapter explains the interface between the core
+ This section explains the interface between the core
<productname>PostgreSQL</productname> system and custom WAL resource
managers, which enable extensions to integrate directly with the <link
linkend="wal"><acronym>WAL</acronym></link>.
@@ -13,10 +13,7 @@
An extension, especially a <link linkend="tableam">Table Access
Method</link> or <link linkend="indexam">Index Access Method</link>, may
need to use WAL for recovery, replication, and/or <link
- linkend="logicaldecoding">Logical Decoding</link>. Custom resource managers
- are a more flexible alternative to <link linkend="generic-wal">Generic
- WAL</link> (which does not support logical decoding), but more complex for
- an extension to implement.
+ linkend="logicaldecoding">Logical Decoding</link>.
</para>
<para>
To create a new custom WAL resource manager, first define an
@@ -102,4 +99,4 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
the custom WAL records, which may prevent the server from starting.
</para>
</note>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3fb0709f5d..38ec362d8f 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -107,6 +107,7 @@
<!ENTITY storage SYSTEM "storage.sgml">
<!ENTITY transaction SYSTEM "xact.sgml">
<!ENTITY tablesample-method SYSTEM "tablesample-method.sgml">
+<!ENTITY wal-for-extensions SYSTEM "wal-for-extensions.sgml">
<!ENTITY generic-wal SYSTEM "generic-wal.sgml">
<!ENTITY custom-rmgr SYSTEM "custom-rmgr.sgml">
<!ENTITY backup-manifest SYSTEM "backup-manifest.sgml">
diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml
index a028856d2e..41f97ad7dc 100644
--- a/doc/src/sgml/generic-wal.sgml
+++ b/doc/src/sgml/generic-wal.sgml
@@ -1,20 +1,12 @@
<!-- doc/src/sgml/generic-wal.sgml -->
-<chapter id="generic-wal">
+<sect1 id="generic-wal">
<title>Generic WAL Records</title>
<para>
Although all built-in WAL-logged modules have their own types of WAL
records, there is also a generic WAL record type, which describes changes
- to pages in a generic way. This is useful for extensions that provide
- custom access methods.
- </para>
-
- <para>
- In comparison with <link linkend="custom-rmgr">Custom WAL Resource
- Managers</link>, Generic WAL is simpler for an extension to implement and
- does not require the extension library to be loaded in order to apply the
- records.
+ to pages in a generic way.
</para>
<note>
@@ -171,4 +163,4 @@
</listitem>
</itemizedlist>
</para>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index e9a350234e..ec9f90e283 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -256,8 +256,7 @@ break is not needed in a wider output rendering.
&geqo;
&tableam;
&indexam;
- &generic-wal;
- &custom-rmgr;
+ &wal-for-extensions;
&indextypes;
&storage;
&transaction;
diff --git a/doc/src/sgml/wal-for-extensions.sgml b/doc/src/sgml/wal-for-extensions.sgml
new file mode 100644
index 0000000000..4c4fb29dd1
--- /dev/null
+++ b/doc/src/sgml/wal-for-extensions.sgml
@@ -0,0 +1,32 @@
+<!-- doc/src/sgml/wal-for-extensions.sgml -->
+
+<chapter id="wal-for-extensions">
+ <title>Write Ahead Logging for Extensions</title>
+
+ <para>
+ Certain extensions, principally extensions that implement custom access
+ methods, may need to perform write-ahead logging in order to ensure
+ crash-safety. <productname>PostgreSQL</productname> provides two ways
+ for extensions to achieve this goal.
+ </para>
+
+ <para>
+ First, extensions can choose to use <link linkend="generic-wal">generic
+ WAL</link>, a special type of WAL record which describes changes to pages
+ in a generic way. This method is simple to implement and does not require
+ that an extension library be loaded in order to apply the records. However,
+ generic WAL records will be ignored when performing logical decoding.
+ </para>
+
+ <para>
+ Second, extensions can choose to use a <link linkend="custom-rmgr">custom
+ resource manager</link>. This method is more flexible, supports logical
+ decoding, and can sometimes generate much smaller write-ahead log records
+ than would be possible with generic WAL. However, it is more complex for an
+ extension to implement.
+ </para>
+
+&generic-wal;
+&custom-rmgr;
+
+</chapter>
--
2.39.3 (Apple Git-145)
Re: documentation structure
On Mon, Mar 25, 2024 at 11:40 AM Peter Eisentraut <peter@eisentraut.org> wrote:
I think a possible problem we need to consider with these proposals to
combine chapters is that they could make the chapters themselves too
deep and harder to navigate.
I looked into various options for further combining chapters and/or
appendixes and found that this is indeed a huge problem. For example,
I had thought of creating a Developer Information chapter in the
appendix and moving various existing chapters and appendixes inside of
it, but that means that the <sect1> elements in those chapters get
demoted to <sect2>, and what used to be a whole chapter or appendix
becomes a <sect1>. And since you get one HTML page per <sect1>, that
means that instead of a bunch of individual HTML pages of very
pleasant length, you suddenly get one very long HTML page that is,
exactly as you say, hard to navigate.
The rendering can be adjusted to some degree, but then we also need to
make sure any new chunking makes sense in other chapters. (And it might
also change a bunch of externally known HTML links.)
I looked into this and I'm unclear how much customization is possible.
I gather that the current scheme comes from having chunk.section.depth
of 1, and I guess you can change that to 2 to get an HTML page per
<sect2>, but it seems like it would take a LOT of restructuring to
make that work. It would be much easier if you could vary this across
different parts of the documentation; for instance, if you could say,
well, in this particular chapter or appendix, I want
chunk.section.depth of 2, but elsewhere 1, that would be quite handy,
but after several hours reading various things about DocBook on the
Internet, I was still unable to determine conclusively whether this
was possible. There's an interesting comment in
stylesheet-speedup-xhtml.xsl that says "Since we set a fixed
$chunk.section.depth, we can do away with a bunch of complicated XPath
searches for the previous and next sections at various levels." That
sounds like it's suggesting that it is in fact possible for this
setting to vary, but I don't know if that's true, or how to do it, and
it sounds like there might be performance consequences, too.
I think maybe more could also be done at the top-level structure, too.
Right now, we have <book> -> <part> -> <chapter>. We could add <set> on
top of that.
Does this let you create structures of non-uniform depth? i.e. is
there a way that we can group some chapters into sets while leaving
others as standalone chapters, or somesuch?
I'm not 100% confident that non-uniform depth (either via <set> or via
chunk.section.depth or via some other mechanism) is a good idea.
There's a sort of uniformity to our navigation right now that does
have some real appeal. The downside, though, is that if you want
something to be a single HTML page, it's got to either be a chapter
(or appendix) by itself with no sections inside of it, or it's got to
be a <sect1> inside of a chapter, and so anything that's long enough
that it should be an HTML page by itself can never be more than one
level below the index. And that seems to make it quite difficult to
keep the index small.
Without some kind of variable-depth structure, the only other ways
that I can see to improve things are:
1. Make chunk.section.depth 2 and restructure the entire documentation
until the results look reasonable. This might be possible but I bet
it's difficult. We have, at present, chapters of *wildly* varying
length, from a few sentences to many, many pages. That is perhaps a
bad thing; you most likely wouldn't do that in a printed book. But
fixing it is a huge project. We don't necessarily have the same amount
of content about each topic, and there isn't necessarily a way of
grouping related topics together that produces units of relatively
uniform length. I think it's sensible to try to make improvements
where we can, by pushing stuff down that's short and not that
important, but finding our way to a chunk.section.depth=2 world that
feels good to most people compared to what we have today seems like
it's going to be challening.
2. Replace the current index with a custom index or landing page of
some kind. Or keep the current index and add a new landing page
alongside it. Something that isn't derived automatically from the
documentation structure but is created by hand.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Apr 5, 2024 at 9:01 AM Robert Haas <robertmhaas@gmail.com> wrote:
The rendering can be adjusted to some degree, but then we also need to
make sure any new chunking makes sense in other chapters. (And it might
also change a bunch of externally known HTML links.)I looked into this and I'm unclear how much customization is possible.
Here is a link to my attempt at this a couple of years ago. It basically
"abuses" refentry.
/messages/by-id/CAKFQuwaVm=6d_sw9Wrp4cdSm5_k=8ZVx0--v2v4BH4KnJtqXqg@mail.gmail.com
I never did dive into the man page or PDF dynamics of this
particular change but it seemed to solve HTML pagination without negative
consequences and with minimal risk of unintended consequences since only
the markup on the pages we want to alter is changed, not global
configuration.
David J.
Re: documentation structure
On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
Here is a link to my attempt at this a couple of years ago. It basically "abuses" refentry.
/messages/by-id/CAKFQuwaVm=6d_sw9Wrp4cdSm5_k=8ZVx0--v2v4BH4KnJtqXqg@mail.gmail.com
I never did dive into the man page or PDF dynamics of this particular change but it seemed to solve HTML pagination without negative consequences and with minimal risk of unintended consequences since only the markup on the pages we want to alter is changed, not global configuration.
Hmm, but it seems like that might have generated some man page entries
that we don't want?
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
On Fri, Apr 5, 2024 at 9:18 AM Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:Here is a link to my attempt at this a couple of years ago. It
basically "abuses" refentry.
/messages/by-id/CAKFQuwaVm=6d_sw9Wrp4cdSm5_k=8ZVx0--v2v4BH4KnJtqXqg@mail.gmail.com
I never did dive into the man page or PDF dynamics of this particular
change but it seemed to solve HTML pagination without negative consequences
and with minimal risk of unintended consequences since only the markup on
the pages we want to alter is changed, not global configuration.Hmm, but it seems like that might have generated some man page entries
that we don't want?
If so (didn't check) maybe just remove them in post?
David J.
Re: documentation structure
On 05.04.24 17:11, Robert Haas wrote:
4. Consolidate the "Generic WAL Records" and "Custom WAL Resource
Managers" chapters, which cover related topics, into a single one. I
didn't see anyone object to this, but David Johnston pointed out that
the patch I posted was a few bricks short of a load, because it really
needed to put some introductory text into the new chapter. I'll study
this a bit more and propose a new patch that does the same thing a bit
more carefully than my previous version did.Here is a new version of this patch. I think this is v18 material at
this point, absent an outcry to the contrary. Sometimes we're flexible
about doc patches.
Looks good to me. I think this could go into PG17.
Re: documentation structure
On Wed, Mar 20, 2024 at 5:40 AM Andrew Dunstan <andrew@dunslane.net> wrote:
+many for improving the index.
My own pet docs peeve is a purely editorial one: func.sgml is a 30k line beast, and I think there's a good case for splitting out at least the larger chunks of it.
I think I successfully reduced func.sgml from 311322 lines to 13167 lines.
(base-commit: 93582974315174d544592185d797a2b44696d1e5)
writing a patch would be unreviewable.
key gotcha is put the contents between opening `<sect1>` and closing
`</sect1>` (both inclusive)
into a new file.
in func.sgml, using `&entity` to refernce the new file.
also update filelist.sgml
here is how I do it:
I found out these build html files are the biggest one:
doc/src/sgml/html/functions-string.html
doc/src/sgml/html/functions-matching.html
doc/src/sgml/html/functions-datetime.html
doc/src/sgml/html/functions-json.html
doc/src/sgml/html/functions-aggregate.html
doc/src/sgml/html/functions-info.html
doc/src/sgml/html/functions-admin.html
so create these new sgml files hold corrspedoning content:
func-string.sgml
func-matching.sgml
func-datetime.sgml
func-json.sgml
func-aggregate.sgml
func-info.sgml
func-admin.sgml
based on funs.sgml structure pattern:
<sect1 id="functions-string">
next section1 line number:
<sect1 id="functions-binarystring">
<sect1 id="functions-matching">
next section1 line number:
<sect1 id="functions-formatting">
<sect1 id="functions-datetime">
next section1 line number:
<sect1 id="functions-enum">
<sect1 id="functions-json">
next section1 line number:
<sect1 id="functions-sequence">
<sect1 id="functions-aggregate">
next section1 line number:
<sect1 id="functions-window">
<sect1 id="functions-info">
next section1 line number:
<sect1 id="functions-admin">
<sect1 id="functions-admin">
next section1 line number:
<sect1 id="functions-trigger">
------------------------------------
step1: pipe the relative line range contents to new sgml files.
(example: line 2407 to line 4177 include all the content correspond to
functions-string.html)
sed -n '2407,4177 p' func.sgml > func-string.sgml
sed -n '5328,7756 p' func.sgml > func-matching.sgml
sed -n '8939,11122 p' func.sgml > func-datetime.sgml
sed -n '15498,19348 p' func.sgml > func-json.sgml
sed -n '21479,22896 p' func.sgml > func-aggregate.sgml
sed -n '24257,27896 p' func.sgml > func-info.sgml
sed -n '27898,30579 p' func.sgml > func-admin.sgml
step2:
in place delete these line ranges in func.sgml
sed --in-place "2407,4177d ; 5328,7756d ; 8939,11122d ; 15498,19348d
; 21479,22896d ; 24257,27896d ; 27898,30579d" \
func.sgml
reference: https://unix.stackexchange.com/questions/676210/matching-multiple-ranges-with-sed-range-expressions
https://www.gnu.org/software/sed/manual/sed.html#Command_002dLine-Options
step3:
put following lines into relative position in func.sgml:
(based on above structure pattern, quickly location line position)
`
&func-string
&func-matching
&func-datetime
&func-json
&func-aggregate
&func-info
&func-admin
`
step4: update filelist.sgml:
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 3fb0709f..0b78a361 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -18,6 +18,13 @@
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml"> doc/src/sgml/filelist.sgml | 7 +
doc/src/sgml/func-admin.sgml | 2682 +++++
doc/src/sgml/func-aggregate.sgml | 1418 +++
doc/src/sgml/func-datetime.sgml | 2184 ++++
doc/src/sgml/func-info.sgml | 3640 ++++++
doc/src/sgml/func-json.sgml | 3851 ++++++
doc/src/sgml/func-matching.sgml | 2429 ++++
doc/src/sgml/func-string.sgml | 1771 +++
doc/src/sgml/func.sgml | 17979 +----------------------------
we can do it one by one, but it's still worth it.
Re: documentation structure
On Mon, Apr 8, 2024 at 10:15 AM Peter Eisentraut <peter@eisentraut.org> wrote:
Here is a new version of this patch. I think this is v18 material at
this point, absent an outcry to the contrary. Sometimes we're flexible
about doc patches.Looks good to me. I think this could go into PG17.
Hearing no objections, done.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: documentation structure
Hi,
On 2024-03-19 17:39:39 -0400, Andrew Dunstan wrote:
My own pet docs peeve is a purely editorial one: func.sgml is a 30k line
beast, and I think there's a good case for splitting out at least the
larger chunks of it.
I think we should work on generating a lot of func.sgml. Particularly the
signature etc should just come from pg_proc.dat, it's pointlessly painful to
generate that by hand. And for a lot of the functions we should probably move
the existing func.sgml comments to the description in pg_proc.dat.
I suspect that we can't just generate all the documentation from pg_proc,
because of xrefs etc. Although perhaps we could just strip those out for
pg_proc.
We'd need to add some more metadata to pg_proc, for grouping kinds of
functions together. But that seems doable.
Greetings,
Andres Freund
Re: documentation structure
Andres Freund <andres@anarazel.de> writes:
I think we should work on generating a lot of func.sgml. Particularly the
signature etc should just come from pg_proc.dat, it's pointlessly painful to
generate that by hand. And for a lot of the functions we should probably move
the existing func.sgml comments to the description in pg_proc.dat.
Where are you going to get the examples and text descriptions from?
(And no, I don't agree that the pg_description string should match
what's in the docs. The description string has to be a short
one-liner in just about every case.)
This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.
I do agree with Andrew that splitting func.sgml into multiple files
would be beneficial.
regards, tom lane
Re: documentation structure
On Tue, Apr 16, 2024 at 03:05:32PM -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
I think we should work on generating a lot of func.sgml. Particularly the
signature etc should just come from pg_proc.dat, it's pointlessly painful to
generate that by hand. And for a lot of the functions we should probably move
the existing func.sgml comments to the description in pg_proc.dat.Where are you going to get the examples and text descriptions from?
(And no, I don't agree that the pg_description string should match
what's in the docs. The description string has to be a short
one-liner in just about every case.)This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.
Maybe we could _verify_ the contents of func.sgml against pg_proc.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Re: documentation structure
Hi,
On 2024-04-16 15:05:32 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
I think we should work on generating a lot of func.sgml. Particularly the
signature etc should just come from pg_proc.dat, it's pointlessly painful to
generate that by hand. And for a lot of the functions we should probably move
the existing func.sgml comments to the description in pg_proc.dat.Where are you going to get the examples and text descriptions from?
I think there's a few different way to do that. E.g. having long_desc, example
fields in pg_proc.dat. Or having examples and description in a separate file
and "enriching" that with auto-generated function signatures.
(And no, I don't agree that the pg_description string should match
what's in the docs. The description string has to be a short
one-liner in just about every case.)
Definitely shouldn't be the same in all cases, but I think there's a decent
number of cases where they can be the same. The differences between the two is
often minimal today.
Entirely randomly chosen example:
{ oid => '2825',
descr => 'slope of the least-squares-fit linear equation determined by the (X, Y) pairs',
proname => 'regr_slope', prokind => 'a', proisstrict => 'f',
prorettype => 'float8', proargtypes => 'float8 float8',
prosrc => 'aggregate_dummy' },
and
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>regression slope</primary>
</indexterm>
<indexterm>
<primary>regr_slope</primary>
</indexterm>
<function>regr_slope</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
<returnvalue>double precision</returnvalue>
</para>
<para>
Computes the slope of the least-squares-fit linear equation determined
by the (<parameter>X</parameter>, <parameter>Y</parameter>)
pairs.
</para></entry>
<entry>Yes</entry>
</row>
The description is quite similar, the pg_proc entry lacks argument names.
This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.
I think the manual work for writing signatures in sgml is not insignificant,
nor is the volume of sgml for them. Manually maintaining the signatures makes
it impractical to significantly improve the presentation - which I don't think
is all that great today.
And the lack of argument names in the pg_proc entries is occasionally fairly
annoying, because a \df+ doesn't provide enough information to use functions.
It'd also be quite useful if clients could render more of the documentation
for functions. People are used to language servers providing full
documentation for functions etc...
Greetings,
Andres Freund
Re: documentation structure
This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.Maybe we could _verify_ the contents of func.sgml against pg_proc.
All of the functions redefined in catalog/system_functions.sql complicate
using pg_proc.dat as a doc generator or source of validation. We'd probably
do better to validate against a live instance, and even then the benefit
wouldn't be great.
Re: documentation structure
Andres Freund <andres@anarazel.de> writes:
Definitely shouldn't be the same in all cases, but I think there's a decent
number of cases where they can be the same. The differences between the two is
often minimal today.Entirely randomly chosen example:
{ oid => '2825',
descr => 'slope of the least-squares-fit linear equation determined by the (X, Y) pairs',
proname => 'regr_slope', prokind => 'a', proisstrict => 'f',
prorettype => 'float8', proargtypes => 'float8 float8',
prosrc => 'aggregate_dummy' },and
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>regression slope</primary>
</indexterm>
<indexterm>
<primary>regr_slope</primary>
</indexterm>
<function>regr_slope</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
<returnvalue>double precision</returnvalue>
</para>
<para>
Computes the slope of the least-squares-fit linear equation determined
by the (<parameter>X</parameter>, <parameter>Y</parameter>)
pairs.
</para></entry>
<entry>Yes</entry>
</row>The description is quite similar, the pg_proc entry lacks argument names.
This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.I think the manual work for writing signatures in sgml is not insignificant,
nor is the volume of sgml for them. Manually maintaining the signatures makes
it impractical to significantly improve the presentation - which I don't think
is all that great today.
And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).
And the lack of argument names in the pg_proc entries is occasionally fairly
annoying, because a \df+ doesn't provide enough information to use functions.
I was also annoyed by this the other day (specifically wrt. the boolean
arguments to pg_ls_dir), and started whipping up a Perl script to parse
func.sgml and generate missing proargnames values for pg_proc.dat, which
is how I discovered the above. The script currently has a pile of hacky
regexes to cope with that, so I'd be happy to submit a doc patch to turn
it into actual markup to get rid of that, if people think that's a
worhtwhile use of time and won't clash with any other plans for the
documentation.
It'd also be quite useful if clients could render more of the documentation
for functions. People are used to language servers providing full
documentation for functions etc...
A more user-friendly version of \df+ (maybe spelled \hf, for symmetry
with \h for commands?) would certainly be nice.
Greetings,
Andres Freund
- ilmari
Re: documentation structure
And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).
Having just written a couple of those functions, I wasn't able to find any
guidance on how to document them with regards to <optional> vs [], etc.
Having such a thing would be helpful.
While we're throwing out ideas, does it make sense to have function
parameters and return values be things that can accept COMMENTs? Like so:
COMMENT ON FUNCTION function_name [ ( [ [ argmode ] [ argname ] argtype [,
...] ] ) ] ARGUMENT argname IS '....';
COMMENT ON FUNCTION function_name [ ( [ [ argmode ] [ argname ] argtype [,
...] ] ) ] RETURN VALUE IS '....';
I don't think this is a great idea, but if we're going to auto-generate
documentation then we've got to store the metadata somewhere, and
pg_proc.dat is already lacking relevant details.
Re: documentation structure
Hi,
On 2024-04-17 02:46:53 -0400, Corey Huinker wrote:
This sounds to me like it would be a painful exercise with not a
lot of benefit in the end.Maybe we could _verify_ the contents of func.sgml against pg_proc.
All of the functions redefined in catalog/system_functions.sql complicate
using pg_proc.dat as a doc generator or source of validation. We'd probably
do better to validate against a live instance, and even then the benefit
wouldn't be great.
There are 80 'CREATE OR REPLACE's in system_functions.sql, 1016 occurrences of
func_table_entry in funcs.sgml and 3.3k functions in pg_proc. I'm not saying
that differences due to system_functions.sql wouldn't be annoying to deal
with, but it'd also be far from the end of the world.
Greetings,
Andres Freund
Re: documentation structure
Hi,
On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Manns�ker wrote:
Andres Freund <andres@anarazel.de> writes:
I think the manual work for writing signatures in sgml is not insignificant,
nor is the volume of sgml for them. Manually maintaining the signatures makes
it impractical to significantly improve the presentation - which I don't think
is all that great today.And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).
That seems almost inevitably the outcome of many people having to manually
infer the recommended semantics, for writing something boring but nontrivial,
from a 30k line file.
And the lack of argument names in the pg_proc entries is occasionally fairly
annoying, because a \df+ doesn't provide enough information to use functions.I was also annoyed by this the other day (specifically wrt. the boolean
arguments to pg_ls_dir),
My bane is regexp_match et al, I have given up on remembering the argument
order.
and started whipping up a Perl script to parse func.sgml and generate
missing proargnames values for pg_proc.dat, which is how I discovered the
above.
Nice.
The script currently has a pile of hacky regexes to cope with that,
so I'd be happy to submit a doc patch to turn it into actual markup to get
rid of that, if people think that's a worhtwhile use of time and won't clash
with any other plans for the documentation.
I guess it's a bit hard to say without knowing how voluminious the changes
would be. If we end up rewriting the whole file the tradeoff is less clear
than if it's a dozen inconsistent entries.
It'd also be quite useful if clients could render more of the documentation
for functions. People are used to language servers providing full
documentation for functions etc...A more user-friendly version of \df+ (maybe spelled \hf, for symmetry
with \h for commands?) would certainly be nice.
Indeed.
Greetings,
Andres Freund
Re: documentation structure
Andres Freund <andres@anarazel.de> writes:
Hi,
On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote:
Andres Freund <andres@anarazel.de> writes:
I think the manual work for writing signatures in sgml is not insignificant,
nor is the volume of sgml for them. Manually maintaining the signatures makes
it impractical to significantly improve the presentation - which I don't think
is all that great today.And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).That seems almost inevitably the outcome of many people having to manually
infer the recommended semantics, for writing something boring but nontrivial,
from a 30k line file.
As Corey mentioned elsethread, having a markup style guide (maybe a
comment at the top of the file?) would be nice.
And the lack of argument names in the pg_proc entries is occasionally fairly
annoying, because a \df+ doesn't provide enough information to use functions.I was also annoyed by this the other day (specifically wrt. the boolean
arguments to pg_ls_dir),My bane is regexp_match et al, I have given up on remembering the argument
order.
There's a thread elsewhere about those specifically, but I can't be
bothered to find the link right now.
and started whipping up a Perl script to parse func.sgml and generate
missing proargnames values for pg_proc.dat, which is how I discovered the
above.Nice.
The script currently has a pile of hacky regexes to cope with that,
so I'd be happy to submit a doc patch to turn it into actual markup to get
rid of that, if people think that's a worhtwhile use of time and won't clash
with any other plans for the documentation.I guess it's a bit hard to say without knowing how voluminious the changes
would be. If we end up rewriting the whole file the tradeoff is less clear
than if it's a dozen inconsistent entries.
It turned out to not be that many that used [] for optional parameters,
see the attached patch.
I havent dealt with variadic yet, since the two styles are visually
different, not just markup (<optional>...</optional> renders as [...]).
The two styles for variadic are the what I call caller-style:
concat ( val1 "any" [, val2 "any" [, ...] ] )
format(formatstr text [, formatarg "any" [, ...] ])
which shows more clearly how you'd call it, versus definition-style:
num_nonnulls ( VARIADIC "any" )
jsonb_extract_path ( from_json jsonb, VARIADIC path_elems text[] )
which matches the CREATE FUNCTION statement. I don't have a strong
opinion on which we should use, but we should be consistent.
Greetings,
Andres Freund
- ilmari
Attachments:
0001-func.sgml-Consistently-use-optional-to-indicate-opti.patchtext/x-diffDownload
From f71e0669eb25b205bd5065f15657ba6d749261f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilmari@ilmari.org>
Date: Wed, 17 Apr 2024 16:00:52 +0100
Subject: [PATCH] func.sgml: Consistently use <optional> to indicate optional
parameters
Some functions were using square brackets instead.
---
doc/src/sgml/func.sgml | 54 +++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 8dfb42ad4d..afaaf61d69 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -3036,7 +3036,7 @@
<primary>concat</primary>
</indexterm>
<function>concat</function> ( <parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>val2</parameter> <type>"any"</type> [, ...] </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3056,7 +3056,7 @@
</indexterm>
<function>concat_ws</function> ( <parameter>sep</parameter> <type>text</type>,
<parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>val2</parameter> <type>"any"</type> [, ...] </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3076,7 +3076,7 @@
<primary>format</primary>
</indexterm>
<function>format</function> ( <parameter>formatstr</parameter> <type>text</type>
- [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>formatarg</parameter> <type>"any"</type> [, ...] </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3170,7 +3170,7 @@
<primary>parse_ident</primary>
</indexterm>
<function>parse_ident</function> ( <parameter>qualified_identifier</parameter> <type>text</type>
- [, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> ] )
+ <optional>, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3309,8 +3309,8 @@
<primary>regexp_count</primary>
</indexterm>
<function>regexp_count</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type> ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> </optional> )
<returnvalue>integer</returnvalue>
</para>
<para>
@@ -3331,11 +3331,11 @@
<primary>regexp_instr</primary>
</indexterm>
<function>regexp_instr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>endoption</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>N</parameter> <type>integer</type>
+ <optional>, <parameter>endoption</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type>
+ <optional>, <parameter>subexpr</parameter> <type>integer</type> </optional> </optional> </optional> </optional> </optional> )
<returnvalue>integer</returnvalue>
</para>
<para>
@@ -3360,7 +3360,7 @@
<primary>regexp_like</primary>
</indexterm>
<function>regexp_like</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>flags</parameter> <type>text</type> ] )
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>boolean</returnvalue>
</para>
<para>
@@ -3380,7 +3380,7 @@
<indexterm>
<primary>regexp_match</primary>
</indexterm>
- <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3400,7 +3400,7 @@
<indexterm>
<primary>regexp_matches</primary>
</indexterm>
- <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>setof text[]</returnvalue>
</para>
<para>
@@ -3426,8 +3426,8 @@
<primary>regexp_replace</primary>
</indexterm>
<function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type> ]
- [, <parameter>flags</parameter> <type>text</type> ] )
+ <optional>, <parameter>start</parameter> <type>integer</type> </optional>
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3447,7 +3447,7 @@
<function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>,
<parameter>start</parameter> <type>integer</type>,
<parameter>N</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type> ] )
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3467,7 +3467,7 @@
<indexterm>
<primary>regexp_split_to_array</primary>
</indexterm>
- <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3486,7 +3486,7 @@
<indexterm>
<primary>regexp_split_to_table</primary>
</indexterm>
- <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>setof text</returnvalue>
</para>
<para>
@@ -3510,10 +3510,10 @@
<primary>regexp_substr</primary>
</indexterm>
<function>regexp_substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>N</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type>
+ <optional>, <parameter>subexpr</parameter> <type>integer</type> </optional> </optional> </optional> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3980,7 +3980,7 @@
<para>
<synopsis>
-<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ])
+<function>format</function>(<parameter>formatstr</parameter> <type>text</type> <optional>, <parameter>formatarg</parameter> <type>"any"</type> [, ...] </optional>)
</synopsis>
<parameter>formatstr</parameter> is a format string that specifies how the
result should be formatted. Text in the format string is copied
@@ -10568,7 +10568,7 @@
<para>
<synopsis>
-date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> [, <replaceable>time_zone</replaceable> ])
+date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> <optional>, <replaceable>time_zone</replaceable> </optional>)
</synopsis>
<replaceable>source</replaceable> is a value expression of type
<type>timestamp</type>, <type>timestamp with time zone</type>,
@@ -29308,11 +29308,11 @@
<indexterm>
<primary>pg_logical_emit_message</primary>
</indexterm>
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> <optional>, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal></optional> )
<returnvalue>pg_lsn</returnvalue>
</para>
<para role="func_signature">
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> <optional>, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal></optional> )
<returnvalue>pg_lsn</returnvalue>
</para>
<para>
--
2.39.2
Re: documentation structure
On Thu, Apr 18, 2024 at 2:37 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
Andres Freund <andres@anarazel.de> writes:
Hi,
On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote:
Andres Freund <andres@anarazel.de> writes:
I think the manual work for writing signatures in sgml is not insignificant,
nor is the volume of sgml for them. Manually maintaining the signatures makes
it impractical to significantly improve the presentation - which I don't think
is all that great today.And it's very inconsistent. For example, some functions use <optional>
tags for optional parameters, others use square brackets, and some use
<literal>VARIADIC</literal> to indicate variadic parameters, others use
ellipses (sometimes in <optional> tags or brackets).That seems almost inevitably the outcome of many people having to manually
infer the recommended semantics, for writing something boring but nontrivial,
from a 30k line file.As Corey mentioned elsethread, having a markup style guide (maybe a
comment at the top of the file?) would be nice.And the lack of argument names in the pg_proc entries is occasionally fairly
annoying, because a \df+ doesn't provide enough information to use functions.I was also annoyed by this the other day (specifically wrt. the boolean
arguments to pg_ls_dir),My bane is regexp_match et al, I have given up on remembering the argument
order.There's a thread elsewhere about those specifically, but I can't be
bothered to find the link right now.and started whipping up a Perl script to parse func.sgml and generate
missing proargnames values for pg_proc.dat, which is how I discovered the
above.Nice.
The script currently has a pile of hacky regexes to cope with that,
so I'd be happy to submit a doc patch to turn it into actual markup to get
rid of that, if people think that's a worhtwhile use of time and won't clash
with any other plans for the documentation.I guess it's a bit hard to say without knowing how voluminious the changes
would be. If we end up rewriting the whole file the tradeoff is less clear
than if it's a dozen inconsistent entries.It turned out to not be that many that used [] for optional parameters,
see the attached patch.
hi.
I manually checked the html output. It looks good to me.
Re: documentation structure
I havent dealt with variadic yet, since the two styles are visually
different, not just markup (<optional>...</optional> renders as [...]).The two styles for variadic are the what I call caller-style:
concat ( val1 "any" [, val2 "any" [, ...] ] )
format(formatstr text [, formatarg "any" [, ...] ])
While this style is obviously clumsier for us to compose, it does avoid
relying on the user understanding what the word variadic means. Searching
through online documentation of the python *args parameter, the word
variadic never comes up, the closest they get is "variable length
argument". I realize that python is not SQL, but I think it's a good point
of reference for what concepts the average reader is likely to know.
Looking at the patch, I think it is good, though I'd consider doing some
indentation for the nested <optional>s to allow the author to do more
visual tag-matching. The ']'s were sufficiently visually distinct that we
didn't really need or want nesting, but <optional> is just another tag to
my eyes in a sea of tags.
Re: documentation structure
Corey Huinker <corey.huinker@gmail.com> writes:
I havent dealt with variadic yet, since the two styles are visually
different, not just markup (<optional>...</optional> renders as [...]).The two styles for variadic are the what I call caller-style:
concat ( val1 "any" [, val2 "any" [, ...] ] )
format(formatstr text [, formatarg "any" [, ...] ])While this style is obviously clumsier for us to compose, it does avoid
relying on the user understanding what the word variadic means. Searching
through online documentation of the python *args parameter, the word
variadic never comes up, the closest they get is "variable length
argument". I realize that python is not SQL, but I think it's a good point
of reference for what concepts the average reader is likely to know.
Yeah, we can't expect everyone wanting to call a built-in function to
know how they would define an equivalent one themselves. In that case I
propos marking it up like this:
<function>format</function> (
<parameter>formatstr</parameter> <type>text</type>
<optional>, <parameter>formatarg</parameter> <type>"any"</type>
<optional>, ...</optional> </optional> )
<returnvalue>text</returnvalue>
Looking at the patch, I think it is good, though I'd consider doing some
indentation for the nested <optional>s to allow the author to do more
visual tag-matching. The ']'s were sufficiently visually distinct that we
didn't really need or want nesting, but <optional> is just another tag to
my eyes in a sea of tags.
The requisite nesting when there are multiple optional parameters makes
it annoying to wrap and indent it "properly" per XML convention, but how
about something like this, with each parameter on a line of its own, and
all the closing </optional> tags on one line?
<function>regexp_substr</function> (
<parameter>string</parameter> <type>text</type>,
<parameter>pattern</parameter> <type>text</type>
<optional>, <parameter>start</parameter> <type>integer</type>
<optional>, <parameter>N</parameter> <type>integer</type>
<optional>, <parameter>flags</parameter> <type>text</type>
<optional>, <parameter>subexpr</parameter> <type>integer</type>
</optional> </optional> </optional> </optional> )
<returnvalue>text</returnvalue>
A lot of functions mostly follow this style, except they tend to put the
first parameter on the same line of the function namee, even when that
makes the line overly long. I propose going the other way, with each
parameter on a line of its own, even if the first one would fit after
the function name, except the whole parameter list fits after the
function name.
Also, when there's only one optional argument, or they're independently
optional, not nested, the </optional> tag should go on the same line as
the parameter.
<function>substring</function> (
<parameter>bits</parameter> <type>bit</type>
<optional> <literal>FROM</literal> <parameter>start</parameter> <type>integer</type> </optional>
<optional> <literal>FOR</literal> <parameter>count</parameter> <type>integer</type> </optional> )
<returnvalue>bit</returnvalue>
I'm not quite sure what to with things like json_object which have even
more complex nexting of optional parameters, but I do think the current
200+ character lines are too long.
- ilmari
Re: documentation structure
Yeah, we can't expect everyone wanting to call a built-in function to
know how they would define an equivalent one themselves. In that case I
propos marking it up like this:<function>format</function> (
<parameter>formatstr</parameter> <type>text</type>
<optional>, <parameter>formatarg</parameter> <type>"any"</type>
<optional>, ...</optional> </optional> )
<returnvalue>text</returnvalue>
Looks good, but I guess I have to ask: is there a parameter-list tag out
there instead of (, and should we be using that?
The requisite nesting when there are multiple optional parameters makes
it annoying to wrap and indent it "properly" per XML convention, but how
about something like this, with each parameter on a line of its own, and
all the closing </optional> tags on one line?<function>regexp_substr</function> (
<parameter>string</parameter> <type>text</type>,
<parameter>pattern</parameter> <type>text</type>
<optional>, <parameter>start</parameter> <type>integer</type>
<optional>, <parameter>N</parameter> <type>integer</type>
<optional>, <parameter>flags</parameter> <type>text</type>
<optional>, <parameter>subexpr</parameter> <type>integer</type>
</optional> </optional> </optional> </optional> )
<returnvalue>text</returnvalue>
Yes, that has an easy count-the-vertical, count-the-horizontal,
do-they-match flow to it.
A lot of functions mostly follow this style, except they tend to put the
first parameter on the same line of the function namee, even when that
makes the line overly long. I propose going the other way, with each
parameter on a line of its own, even if the first one would fit after
the function name, except the whole parameter list fits after the
function name.
+1
Also, when there's only one optional argument, or they're independently
optional, not nested, the </optional> tag should go on the same line as
the parameter.<function>substring</function> (
<parameter>bits</parameter> <type>bit</type>
<optional> <literal>FROM</literal> <parameter>start</parameter>
<type>integer</type> </optional>
<optional> <literal>FOR</literal> <parameter>count</parameter>
<type>integer</type> </optional> )
<returnvalue>bit</returnvalue>
+1
Re: documentation structure
On Wed, Apr 17, 2024 at 7:07 PM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
It'd also be quite useful if clients could render more of the documentation
for functions. People are used to language servers providing full
documentation for functions etc...A more user-friendly version of \df+ (maybe spelled \hf, for symmetry
with \h for commands?) would certainly be nice.
I think `\hf` is useful.
otherwise people first need google to find out the function html page,
then need Ctrl + F to locate specific function entry.
for \hf
we may need to offer a doc url link.
but currently many functions are unlinkable in the doc.
Also one section can have many sections.
I guess just linking directly to a nearby position in a html page
should be fine.
We can also add a url for functions decorated as underscore
like mysql (https://dev.mysql.com/doc/refman/8.3/en/string-functions.html#function_concat).
I am not sure it is an elegant solution.
Re: documentation structure
On Mon, Apr 15, 2024 at 1:00 PM jian he <jian.universality@gmail.com> wrote:
On Wed, Mar 20, 2024 at 5:40 AM Andrew Dunstan <andrew@dunslane.net> wrote:
+many for improving the index.
My own pet docs peeve is a purely editorial one: func.sgml is a 30k line beast, and I think there's a good case for splitting out at least the larger chunks of it.
I think I successfully reduced func.sgml from 311322 lines to 13167 lines.
(base-commit: 93582974315174d544592185d797a2b44696d1e5)writing a patch would be unreviewable.
I've splitted it to7 patches.
each patch split one <sect1> into separate new files.
func-string.sgml
func-matching.sgml
func-datetime.sgml
func-json.sgml
func-aggregate.sgml
func-info.sgml
func-admin.sgml
the above will be newly created files, each corresponding to related
individual patches.
Attachments:
v1-0001-split-sect1-functions-string-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0001-split-sect1-functions-string-from-func.sgml.patchDownload
From abb5912f21b5e8c026e694d8778922d18cd794c7 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 14:14:16 +0800
Subject: [PATCH v1 1/7] split sect1 "functions-string" from func.sgml
"functions-string" will live in a new file: doc/src/sgml/func-string.sgml,
it will hold functions-string.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-string.sgml | 1771 ++++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 1773 +--------------------------------
3 files changed, 1773 insertions(+), 1772 deletions(-)
create mode 100644 doc/src/sgml/func-string.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 38ec362d..c795833b 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -18,6 +18,7 @@
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-string.sgml b/doc/src/sgml/func-string.sgml
new file mode 100644
index 00000000..697f3de7
--- /dev/null
+++ b/doc/src/sgml/func-string.sgml
@@ -0,0 +1,1771 @@
+ <sect1 id="functions-string">
+ <title>String Functions and Operators</title>
+
+ <para>
+ This section describes functions and operators for examining and
+ manipulating string values. Strings in this context include values
+ of the types <type>character</type>, <type>character varying</type>,
+ and <type>text</type>. Except where noted, these functions and operators
+ are declared to accept and return type <type>text</type>. They will
+ interchangeably accept <type>character varying</type> arguments.
+ Values of type <type>character</type> will be converted
+ to <type>text</type> before the function or operator is applied, resulting
+ in stripping any trailing spaces in the <type>character</type> value.
+ </para>
+
+ <para>
+ <acronym>SQL</acronym> defines some string functions that use
+ key words, rather than commas, to separate
+ arguments. Details are in
+ <xref linkend="functions-string-sql"/>.
+ <productname>PostgreSQL</productname> also provides versions of these functions
+ that use the regular function invocation syntax
+ (see <xref linkend="functions-string-other"/>).
+ </para>
+
+ <note>
+ <para>
+ The string concatenation operator (<literal>||</literal>) will accept
+ non-string input, so long as at least one input is of string type, as shown
+ in <xref linkend="functions-string-sql"/>. For other cases, inserting an
+ explicit coercion to <type>text</type> can be used to have non-string input
+ accepted.
+ </para>
+ </note>
+
+ <table id="functions-string-sql">
+ <title><acronym>SQL</acronym> String Functions and Operators</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function/Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>character string</primary>
+ <secondary>concatenation</secondary>
+ </indexterm>
+ <type>text</type> <literal>||</literal> <type>text</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Concatenates the two strings.
+ </para>
+ <para>
+ <literal>'Post' || 'greSQL'</literal>
+ <returnvalue>PostgreSQL</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>text</type> <literal>||</literal> <type>anynonarray</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>anynonarray</type> <literal>||</literal> <type>text</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the non-string input to text, then concatenates the two
+ strings. (The non-string input cannot be of an array type, because
+ that would create ambiguity with the array <literal>||</literal>
+ operators. If you want to concatenate an array's text equivalent,
+ cast it to <type>text</type> explicitly.)
+ </para>
+ <para>
+ <literal>'Value: ' || 42</literal>
+ <returnvalue>Value: 42</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>btrim</primary>
+ </indexterm>
+ <function>btrim</function> ( <parameter>string</parameter> <type>text</type>
+ <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Removes the longest string containing only characters
+ in <parameter>characters</parameter> (a space by default)
+ from the start and end of <parameter>string</parameter>.
+ </para>
+ <para>
+ <literal>btrim('xyxtrimyyx', 'xyz')</literal>
+ <returnvalue>trim</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>normalized</primary>
+ </indexterm>
+ <indexterm>
+ <primary>Unicode normalization</primary>
+ </indexterm>
+ <type>text</type> <literal>IS</literal> <optional><literal>NOT</literal></optional> <optional><parameter>form</parameter></optional> <literal>NORMALIZED</literal>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Checks whether the string is in the specified Unicode normalization
+ form. The optional <parameter>form</parameter> key word specifies the
+ form: <literal>NFC</literal> (the default), <literal>NFD</literal>,
+ <literal>NFKC</literal>, or <literal>NFKD</literal>. This expression can
+ only be used when the server encoding is <literal>UTF8</literal>. Note
+ that checking for normalization using this expression is often faster
+ than normalizing possibly already normalized strings.
+ </para>
+ <para>
+ <literal>U&'\0061\0308bc' IS NFD NORMALIZED</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bit_length</primary>
+ </indexterm>
+ <function>bit_length</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns number of bits in the string (8
+ times the <function>octet_length</function>).
+ </para>
+ <para>
+ <literal>bit_length('jose')</literal>
+ <returnvalue>32</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>char_length</primary>
+ </indexterm>
+ <indexterm>
+ <primary>character string</primary>
+ <secondary>length</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>length</primary>
+ <secondary sortas="character string">of a character string</secondary>
+ <see>character string, length</see>
+ </indexterm>
+ <function>char_length</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>character_length</primary>
+ </indexterm>
+ <function>character_length</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns number of characters in the string.
+ </para>
+ <para>
+ <literal>char_length('josé')</literal>
+ <returnvalue>4</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>lower</primary>
+ </indexterm>
+ <function>lower</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the string to all lower case, according to the rules of the
+ database's locale.
+ </para>
+ <para>
+ <literal>lower('TOM')</literal>
+ <returnvalue>tom</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>lpad</primary>
+ </indexterm>
+ <function>lpad</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>length</parameter> <type>integer</type>
+ <optional>, <parameter>fill</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extends the <parameter>string</parameter> to length
+ <parameter>length</parameter> by prepending the characters
+ <parameter>fill</parameter> (a space by default). If the
+ <parameter>string</parameter> is already longer than
+ <parameter>length</parameter> then it is truncated (on the right).
+ </para>
+ <para>
+ <literal>lpad('hi', 5, 'xy')</literal>
+ <returnvalue>xyxhi</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>ltrim</primary>
+ </indexterm>
+ <function>ltrim</function> ( <parameter>string</parameter> <type>text</type>
+ <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Removes the longest string containing only characters in
+ <parameter>characters</parameter> (a space by default) from the start of
+ <parameter>string</parameter>.
+ </para>
+ <para>
+ <literal>ltrim('zzzytest', 'xyz')</literal>
+ <returnvalue>test</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>normalize</primary>
+ </indexterm>
+ <indexterm>
+ <primary>Unicode normalization</primary>
+ </indexterm>
+ <function>normalize</function> ( <type>text</type>
+ <optional>, <parameter>form</parameter> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the string to the specified Unicode
+ normalization form. The optional <parameter>form</parameter> key word
+ specifies the form: <literal>NFC</literal> (the default),
+ <literal>NFD</literal>, <literal>NFKC</literal>, or
+ <literal>NFKD</literal>. This function can only be used when the
+ server encoding is <literal>UTF8</literal>.
+ </para>
+ <para>
+ <literal>normalize(U&'\0061\0308bc', NFC)</literal>
+ <returnvalue>U&'\00E4bc'</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>octet_length</primary>
+ </indexterm>
+ <function>octet_length</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns number of bytes in the string.
+ </para>
+ <para>
+ <literal>octet_length('josé')</literal>
+ <returnvalue>5</returnvalue> (if server encoding is UTF8)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>octet_length</primary>
+ </indexterm>
+ <function>octet_length</function> ( <type>character</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns number of bytes in the string. Since this version of the
+ function accepts type <type>character</type> directly, it will not
+ strip trailing spaces.
+ </para>
+ <para>
+ <literal>octet_length('abc '::character(4))</literal>
+ <returnvalue>4</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>overlay</primary>
+ </indexterm>
+ <function>overlay</function> ( <parameter>string</parameter> <type>text</type> <literal>PLACING</literal> <parameter>newsubstring</parameter> <type>text</type> <literal>FROM</literal> <parameter>start</parameter> <type>integer</type> <optional> <literal>FOR</literal> <parameter>count</parameter> <type>integer</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Replaces the substring of <parameter>string</parameter> that starts at
+ the <parameter>start</parameter>'th character and extends
+ for <parameter>count</parameter> characters
+ with <parameter>newsubstring</parameter>.
+ If <parameter>count</parameter> is omitted, it defaults to the length
+ of <parameter>newsubstring</parameter>.
+ </para>
+ <para>
+ <literal>overlay('Txxxxas' placing 'hom' from 2 for 4)</literal>
+ <returnvalue>Thomas</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>position</primary>
+ </indexterm>
+ <function>position</function> ( <parameter>substring</parameter> <type>text</type> <literal>IN</literal> <parameter>string</parameter> <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns first starting index of the specified
+ <parameter>substring</parameter> within
+ <parameter>string</parameter>, or zero if it's not present.
+ </para>
+ <para>
+ <literal>position('om' in 'Thomas')</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>rpad</primary>
+ </indexterm>
+ <function>rpad</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>length</parameter> <type>integer</type>
+ <optional>, <parameter>fill</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extends the <parameter>string</parameter> to length
+ <parameter>length</parameter> by appending the characters
+ <parameter>fill</parameter> (a space by default). If the
+ <parameter>string</parameter> is already longer than
+ <parameter>length</parameter> then it is truncated.
+ </para>
+ <para>
+ <literal>rpad('hi', 5, 'xy')</literal>
+ <returnvalue>hixyx</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>rtrim</primary>
+ </indexterm>
+ <function>rtrim</function> ( <parameter>string</parameter> <type>text</type>
+ <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Removes the longest string containing only characters in
+ <parameter>characters</parameter> (a space by default) from the end of
+ <parameter>string</parameter>.
+ </para>
+ <para>
+ <literal>rtrim('testxxzx', 'xyz')</literal>
+ <returnvalue>test</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>substring</primary>
+ </indexterm>
+ <function>substring</function> ( <parameter>string</parameter> <type>text</type> <optional> <literal>FROM</literal> <parameter>start</parameter> <type>integer</type> </optional> <optional> <literal>FOR</literal> <parameter>count</parameter> <type>integer</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts the substring of <parameter>string</parameter> starting at
+ the <parameter>start</parameter>'th character if that is specified,
+ and stopping after <parameter>count</parameter> characters if that is
+ specified. Provide at least one of <parameter>start</parameter>
+ and <parameter>count</parameter>.
+ </para>
+ <para>
+ <literal>substring('Thomas' from 2 for 3)</literal>
+ <returnvalue>hom</returnvalue>
+ </para>
+ <para>
+ <literal>substring('Thomas' from 3)</literal>
+ <returnvalue>omas</returnvalue>
+ </para>
+ <para>
+ <literal>substring('Thomas' for 2)</literal>
+ <returnvalue>Th</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>FROM</literal> <parameter>pattern</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts the first substring matching POSIX regular expression; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>substring('Thomas' from '...$')</literal>
+ <returnvalue>mas</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>SIMILAR</literal> <parameter>pattern</parameter> <type>text</type> <literal>ESCAPE</literal> <parameter>escape</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>FROM</literal> <parameter>pattern</parameter> <type>text</type> <literal>FOR</literal> <parameter>escape</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts the first substring matching <acronym>SQL</acronym> regular expression;
+ see <xref linkend="functions-similarto-regexp"/>. The first form has
+ been specified since SQL:2003; the second form was only in SQL:1999
+ and should be considered obsolete.
+ </para>
+ <para>
+ <literal>substring('Thomas' similar '%#"o_a#"_' escape '#')</literal>
+ <returnvalue>oma</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>trim</primary>
+ </indexterm>
+ <function>trim</function> ( <optional> <literal>LEADING</literal> | <literal>TRAILING</literal> | <literal>BOTH</literal> </optional>
+ <optional> <parameter>characters</parameter> <type>text</type> </optional> <literal>FROM</literal>
+ <parameter>string</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Removes the longest string containing only characters in
+ <parameter>characters</parameter> (a space by default) from the
+ start, end, or both ends (<literal>BOTH</literal> is the default)
+ of <parameter>string</parameter>.
+ </para>
+ <para>
+ <literal>trim(both 'xyz' from 'yxTomxx')</literal>
+ <returnvalue>Tom</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>trim</function> ( <optional> <literal>LEADING</literal> | <literal>TRAILING</literal> | <literal>BOTH</literal> </optional> <optional> <literal>FROM</literal> </optional>
+ <parameter>string</parameter> <type>text</type> <optional>,
+ <parameter>characters</parameter> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ This is a non-standard syntax for <function>trim()</function>.
+ </para>
+ <para>
+ <literal>trim(both from 'yxTomxx', 'xyz')</literal>
+ <returnvalue>Tom</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>unicode_assigned</primary>
+ </indexterm>
+ <function>unicode_assigned</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns <literal>true</literal> if all characters in the string are
+ assigned Unicode codepoints; <literal>false</literal> otherwise. This
+ function can only be used when the server encoding is
+ <literal>UTF8</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>upper</primary>
+ </indexterm>
+ <function>upper</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the string to all upper case, according to the rules of the
+ database's locale.
+ </para>
+ <para>
+ <literal>upper('tom')</literal>
+ <returnvalue>TOM</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Additional string manipulation functions and operators are available
+ and are listed in <xref linkend="functions-string-other"/>. (Some of
+ these are used internally to implement
+ the <acronym>SQL</acronym>-standard string functions listed in
+ <xref linkend="functions-string-sql"/>.)
+ There are also pattern-matching operators, which are described in
+ <xref linkend="functions-matching"/>, and operators for full-text
+ search, which are described in <xref linkend="textsearch"/>.
+ </para>
+
+ <table id="functions-string-other">
+ <title>Other String Functions and Operators</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function/Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>character string</primary>
+ <secondary>prefix test</secondary>
+ </indexterm>
+ <type>text</type> <literal>^@</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if the first string starts with the second string
+ (equivalent to the <function>starts_with()</function> function).
+ </para>
+ <para>
+ <literal>'alphabet' ^@ 'alph'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>ascii</primary>
+ </indexterm>
+ <function>ascii</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the numeric code of the first character of the argument.
+ In <acronym>UTF8</acronym> encoding, returns the Unicode code point
+ of the character. In other multibyte encodings, the argument must
+ be an <acronym>ASCII</acronym> character.
+ </para>
+ <para>
+ <literal>ascii('x')</literal>
+ <returnvalue>120</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>chr</primary>
+ </indexterm>
+ <function>chr</function> ( <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the character with the given code. In <acronym>UTF8</acronym>
+ encoding the argument is treated as a Unicode code point. In other
+ multibyte encodings the argument must designate
+ an <acronym>ASCII</acronym> character. <literal>chr(0)</literal> is
+ disallowed because text data types cannot store that character.
+ </para>
+ <para>
+ <literal>chr(65)</literal>
+ <returnvalue>A</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>concat</primary>
+ </indexterm>
+ <function>concat</function> ( <parameter>val1</parameter> <type>"any"</type>
+ [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Concatenates the text representations of all the arguments.
+ NULL arguments are ignored.
+ </para>
+ <para>
+ <literal>concat('abcde', 2, NULL, 22)</literal>
+ <returnvalue>abcde222</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>concat_ws</primary>
+ </indexterm>
+ <function>concat_ws</function> ( <parameter>sep</parameter> <type>text</type>,
+ <parameter>val1</parameter> <type>"any"</type>
+ [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Concatenates all but the first argument, with separators. The first
+ argument is used as the separator string, and should not be NULL.
+ Other NULL arguments are ignored.
+ </para>
+ <para>
+ <literal>concat_ws(',', 'abcde', 2, NULL, 22)</literal>
+ <returnvalue>abcde,2,22</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>format</primary>
+ </indexterm>
+ <function>format</function> ( <parameter>formatstr</parameter> <type>text</type>
+ [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Formats arguments according to a format string;
+ see <xref linkend="functions-string-format"/>.
+ This function is similar to the C function <function>sprintf</function>.
+ </para>
+ <para>
+ <literal>format('Hello %s, %1$s', 'World')</literal>
+ <returnvalue>Hello World, World</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>initcap</primary>
+ </indexterm>
+ <function>initcap</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the first letter of each word to upper case and the
+ rest to lower case. Words are sequences of alphanumeric
+ characters separated by non-alphanumeric characters.
+ </para>
+ <para>
+ <literal>initcap('hi THOMAS')</literal>
+ <returnvalue>Hi Thomas</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>left</primary>
+ </indexterm>
+ <function>left</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>n</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns first <parameter>n</parameter> characters in the
+ string, or when <parameter>n</parameter> is negative, returns
+ all but last |<parameter>n</parameter>| characters.
+ </para>
+ <para>
+ <literal>left('abcde', 2)</literal>
+ <returnvalue>ab</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>length</primary>
+ </indexterm>
+ <function>length</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of characters in the string.
+ </para>
+ <para>
+ <literal>length('jose')</literal>
+ <returnvalue>4</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>md5</primary>
+ </indexterm>
+ <function>md5</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Computes the MD5 <link linkend="functions-hash-note">hash</link> of
+ the argument, with the result written in hexadecimal.
+ </para>
+ <para>
+ <literal>md5('abc')</literal>
+ <returnvalue>900150983cd24fb0&zwsp;d6963f7d28e17f72</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>parse_ident</primary>
+ </indexterm>
+ <function>parse_ident</function> ( <parameter>qualified_identifier</parameter> <type>text</type>
+ [, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> ] )
+ <returnvalue>text[]</returnvalue>
+ </para>
+ <para>
+ Splits <parameter>qualified_identifier</parameter> into an array of
+ identifiers, removing any quoting of individual identifiers. By
+ default, extra characters after the last identifier are considered an
+ error; but if the second parameter is <literal>false</literal>, then such
+ extra characters are ignored. (This behavior is useful for parsing
+ names for objects like functions.) Note that this function does not
+ truncate over-length identifiers. If you want truncation you can cast
+ the result to <type>name[]</type>.
+ </para>
+ <para>
+ <literal>parse_ident('"SomeSchema".someTable')</literal>
+ <returnvalue>{SomeSchema,sometable}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_client_encoding</primary>
+ </indexterm>
+ <function>pg_client_encoding</function> ( )
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns current client encoding name.
+ </para>
+ <para>
+ <literal>pg_client_encoding()</literal>
+ <returnvalue>UTF8</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>quote_ident</primary>
+ </indexterm>
+ <function>quote_ident</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the given string suitably quoted to be used as an identifier
+ in an <acronym>SQL</acronym> statement string.
+ Quotes are added only if necessary (i.e., if the string contains
+ non-identifier characters or would be case-folded).
+ Embedded quotes are properly doubled.
+ See also <xref linkend="plpgsql-quote-literal-example"/>.
+ </para>
+ <para>
+ <literal>quote_ident('Foo bar')</literal>
+ <returnvalue>"Foo bar"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>quote_literal</primary>
+ </indexterm>
+ <function>quote_literal</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the given string suitably quoted to be used as a string literal
+ in an <acronym>SQL</acronym> statement string.
+ Embedded single-quotes and backslashes are properly doubled.
+ Note that <function>quote_literal</function> returns null on null
+ input; if the argument might be null,
+ <function>quote_nullable</function> is often more suitable.
+ See also <xref linkend="plpgsql-quote-literal-example"/>.
+ </para>
+ <para>
+ <literal>quote_literal(E'O\'Reilly')</literal>
+ <returnvalue>'O''Reilly'</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>quote_literal</function> ( <type>anyelement</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the given value to text and then quotes it as a literal.
+ Embedded single-quotes and backslashes are properly doubled.
+ </para>
+ <para>
+ <literal>quote_literal(42.5)</literal>
+ <returnvalue>'42.5'</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>quote_nullable</primary>
+ </indexterm>
+ <function>quote_nullable</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the given string suitably quoted to be used as a string literal
+ in an <acronym>SQL</acronym> statement string; or, if the argument
+ is null, returns <literal>NULL</literal>.
+ Embedded single-quotes and backslashes are properly doubled.
+ See also <xref linkend="plpgsql-quote-literal-example"/>.
+ </para>
+ <para>
+ <literal>quote_nullable(NULL)</literal>
+ <returnvalue>NULL</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>quote_nullable</function> ( <type>anyelement</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the given value to text and then quotes it as a literal;
+ or, if the argument is null, returns <literal>NULL</literal>.
+ Embedded single-quotes and backslashes are properly doubled.
+ </para>
+ <para>
+ <literal>quote_nullable(42.5)</literal>
+ <returnvalue>'42.5'</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_count</primary>
+ </indexterm>
+ <function>regexp_count</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
+ [, <parameter>start</parameter> <type>integer</type>
+ [, <parameter>flags</parameter> <type>text</type> ] ] )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of times the POSIX regular
+ expression <parameter>pattern</parameter> matches in
+ the <parameter>string</parameter>; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_count('123456789012', '\d\d\d', 2)</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_instr</primary>
+ </indexterm>
+ <function>regexp_instr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
+ [, <parameter>start</parameter> <type>integer</type>
+ [, <parameter>N</parameter> <type>integer</type>
+ [, <parameter>endoption</parameter> <type>integer</type>
+ [, <parameter>flags</parameter> <type>text</type>
+ [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] ] )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the position within <parameter>string</parameter> where
+ the <parameter>N</parameter>'th match of the POSIX regular
+ expression <parameter>pattern</parameter> occurs, or zero if there is
+ no such match; see <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_instr('ABCDEF', 'c(.)(..)', 1, 1, 0, 'i')</literal>
+ <returnvalue>3</returnvalue>
+ </para>
+ <para>
+ <literal>regexp_instr('ABCDEF', 'c(.)(..)', 1, 1, 0, 'i', 2)</literal>
+ <returnvalue>5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_like</primary>
+ </indexterm>
+ <function>regexp_like</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
+ [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Checks whether a match of the POSIX regular
+ expression <parameter>pattern</parameter> occurs
+ within <parameter>string</parameter>; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_like('Hello World', 'world$', 'i')</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_match</primary>
+ </indexterm>
+ <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>text[]</returnvalue>
+ </para>
+ <para>
+ Returns substrings within the first match of the POSIX regular
+ expression <parameter>pattern</parameter> to
+ the <parameter>string</parameter>; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_match('foobarbequebaz', '(bar)(beque)')</literal>
+ <returnvalue>{bar,beque}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_matches</primary>
+ </indexterm>
+ <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>setof text[]</returnvalue>
+ </para>
+ <para>
+ Returns substrings within the first match of the POSIX regular
+ expression <parameter>pattern</parameter> to
+ the <parameter>string</parameter>, or substrings within all
+ such matches if the <literal>g</literal> flag is used;
+ see <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_matches('foobarbequebaz', 'ba.', 'g')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ {bar}
+ {baz}
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_replace</primary>
+ </indexterm>
+ <function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>
+ [, <parameter>start</parameter> <type>integer</type> ]
+ [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Replaces the substring that is the first match to the POSIX
+ regular expression <parameter>pattern</parameter>, or all such
+ matches if the <literal>g</literal> flag is used; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_replace('Thomas', '.[mN]a.', 'M')</literal>
+ <returnvalue>ThM</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>,
+ <parameter>start</parameter> <type>integer</type>,
+ <parameter>N</parameter> <type>integer</type>
+ [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Replaces the substring that is the <parameter>N</parameter>'th
+ match to the POSIX regular expression <parameter>pattern</parameter>,
+ or all such matches if <parameter>N</parameter> is zero; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_replace('Thomas', '.', 'X', 3, 2)</literal>
+ <returnvalue>ThoXas</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_split_to_array</primary>
+ </indexterm>
+ <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>text[]</returnvalue>
+ </para>
+ <para>
+ Splits <parameter>string</parameter> using a POSIX regular
+ expression as the delimiter, producing an array of results; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_split_to_array('hello world', '\s+')</literal>
+ <returnvalue>{hello,world}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_split_to_table</primary>
+ </indexterm>
+ <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Splits <parameter>string</parameter> using a POSIX regular
+ expression as the delimiter, producing a set of results; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_split_to_table('hello world', '\s+')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ hello
+ world
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regexp_substr</primary>
+ </indexterm>
+ <function>regexp_substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
+ [, <parameter>start</parameter> <type>integer</type>
+ [, <parameter>N</parameter> <type>integer</type>
+ [, <parameter>flags</parameter> <type>text</type>
+ [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the substring within <parameter>string</parameter> that
+ matches the <parameter>N</parameter>'th occurrence of the POSIX
+ regular expression <parameter>pattern</parameter>,
+ or <literal>NULL</literal> if there is no such match; see
+ <xref linkend="functions-posix-regexp"/>.
+ </para>
+ <para>
+ <literal>regexp_substr('ABCDEF', 'c(.)(..)', 1, 1, 'i')</literal>
+ <returnvalue>CDEF</returnvalue>
+ </para>
+ <para>
+ <literal>regexp_substr('ABCDEF', 'c(.)(..)', 1, 1, 'i', 2)</literal>
+ <returnvalue>EF</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>repeat</primary>
+ </indexterm>
+ <function>repeat</function> ( <parameter>string</parameter> <type>text</type>, <parameter>number</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Repeats <parameter>string</parameter> the specified
+ <parameter>number</parameter> of times.
+ </para>
+ <para>
+ <literal>repeat('Pg', 4)</literal>
+ <returnvalue>PgPgPgPg</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>replace</primary>
+ </indexterm>
+ <function>replace</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>from</parameter> <type>text</type>,
+ <parameter>to</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Replaces all occurrences in <parameter>string</parameter> of
+ substring <parameter>from</parameter> with
+ substring <parameter>to</parameter>.
+ </para>
+ <para>
+ <literal>replace('abcdefabcdef', 'cd', 'XX')</literal>
+ <returnvalue>abXXefabXXef</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>reverse</primary>
+ </indexterm>
+ <function>reverse</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reverses the order of the characters in the string.
+ </para>
+ <para>
+ <literal>reverse('abcde')</literal>
+ <returnvalue>edcba</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>right</primary>
+ </indexterm>
+ <function>right</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>n</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns last <parameter>n</parameter> characters in the string,
+ or when <parameter>n</parameter> is negative, returns all but
+ first |<parameter>n</parameter>| characters.
+ </para>
+ <para>
+ <literal>right('abcde', 2)</literal>
+ <returnvalue>de</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>split_part</primary>
+ </indexterm>
+ <function>split_part</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>delimiter</parameter> <type>text</type>,
+ <parameter>n</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Splits <parameter>string</parameter> at occurrences
+ of <parameter>delimiter</parameter> and returns
+ the <parameter>n</parameter>'th field (counting from one),
+ or when <parameter>n</parameter> is negative, returns
+ the |<parameter>n</parameter>|'th-from-last field.
+ </para>
+ <para>
+ <literal>split_part('abc~@~def~@~ghi', '~@~', 2)</literal>
+ <returnvalue>def</returnvalue>
+ </para>
+ <para>
+ <literal>split_part('abc,def,ghi,jkl', ',', -2)</literal>
+ <returnvalue>ghi</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>starts_with</primary>
+ </indexterm>
+ <function>starts_with</function> ( <parameter>string</parameter> <type>text</type>, <parameter>prefix</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if <parameter>string</parameter> starts
+ with <parameter>prefix</parameter>.
+ </para>
+ <para>
+ <literal>starts_with('alphabet', 'alph')</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm id="function-string-to-array">
+ <primary>string_to_array</primary>
+ </indexterm>
+ <function>string_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>delimiter</parameter> <type>text</type> <optional>, <parameter>null_string</parameter> <type>text</type> </optional> )
+ <returnvalue>text[]</returnvalue>
+ </para>
+ <para>
+ Splits the <parameter>string</parameter> at occurrences
+ of <parameter>delimiter</parameter> and forms the resulting fields
+ into a <type>text</type> array.
+ If <parameter>delimiter</parameter> is <literal>NULL</literal>,
+ each character in the <parameter>string</parameter> will become a
+ separate element in the array.
+ If <parameter>delimiter</parameter> is an empty string, then
+ the <parameter>string</parameter> is treated as a single field.
+ If <parameter>null_string</parameter> is supplied and is
+ not <literal>NULL</literal>, fields matching that string are
+ replaced by <literal>NULL</literal>.
+ See also <link linkend="function-array-to-string"><function>array_to_string</function></link>.
+ </para>
+ <para>
+ <literal>string_to_array('xx~~yy~~zz', '~~', 'yy')</literal>
+ <returnvalue>{xx,NULL,zz}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>string_to_table</primary>
+ </indexterm>
+ <function>string_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>delimiter</parameter> <type>text</type> <optional>, <parameter>null_string</parameter> <type>text</type> </optional> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Splits the <parameter>string</parameter> at occurrences
+ of <parameter>delimiter</parameter> and returns the resulting fields
+ as a set of <type>text</type> rows.
+ If <parameter>delimiter</parameter> is <literal>NULL</literal>,
+ each character in the <parameter>string</parameter> will become a
+ separate row of the result.
+ If <parameter>delimiter</parameter> is an empty string, then
+ the <parameter>string</parameter> is treated as a single field.
+ If <parameter>null_string</parameter> is supplied and is
+ not <literal>NULL</literal>, fields matching that string are
+ replaced by <literal>NULL</literal>.
+ </para>
+ <para>
+ <literal>string_to_table('xx~^~yy~^~zz', '~^~', 'yy')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ xx
+ NULL
+ zz
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>strpos</primary>
+ </indexterm>
+ <function>strpos</function> ( <parameter>string</parameter> <type>text</type>, <parameter>substring</parameter> <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns first starting index of the specified <parameter>substring</parameter>
+ within <parameter>string</parameter>, or zero if it's not present.
+ (Same as <literal>position(<parameter>substring</parameter> in
+ <parameter>string</parameter>)</literal>, but note the reversed
+ argument order.)
+ </para>
+ <para>
+ <literal>strpos('high', 'ig')</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>substr</primary>
+ </indexterm>
+ <function>substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>start</parameter> <type>integer</type> <optional>, <parameter>count</parameter> <type>integer</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts the substring of <parameter>string</parameter> starting at
+ the <parameter>start</parameter>'th character,
+ and extending for <parameter>count</parameter> characters if that is
+ specified. (Same
+ as <literal>substring(<parameter>string</parameter>
+ from <parameter>start</parameter>
+ for <parameter>count</parameter>)</literal>.)
+ </para>
+ <para>
+ <literal>substr('alphabet', 3)</literal>
+ <returnvalue>phabet</returnvalue>
+ </para>
+ <para>
+ <literal>substr('alphabet', 3, 2)</literal>
+ <returnvalue>ph</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_ascii</primary>
+ </indexterm>
+ <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>encoding</parameter> <type>name</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>encoding</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts <parameter>string</parameter> to <acronym>ASCII</acronym>
+ from another encoding, which may be identified by name or number.
+ If <parameter>encoding</parameter> is omitted the database encoding
+ is assumed (which in practice is the only useful case).
+ The conversion consists primarily of dropping accents.
+ Conversion is only supported
+ from <literal>LATIN1</literal>, <literal>LATIN2</literal>,
+ <literal>LATIN9</literal>, and <literal>WIN1250</literal> encodings.
+ (See the <xref linkend="unaccent"/> module for another, more flexible
+ solution.)
+ </para>
+ <para>
+ <literal>to_ascii('Karél')</literal>
+ <returnvalue>Karel</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_bin</primary>
+ </indexterm>
+ <function>to_bin</function> ( <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>to_bin</function> ( <type>bigint</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the number to its equivalent two's complement binary
+ representation.
+ </para>
+ <para>
+ <literal>to_bin(2147483647)</literal>
+ <returnvalue>1111111111111111111111111111111</returnvalue>
+ </para>
+ <para>
+ <literal>to_bin(-1234)</literal>
+ <returnvalue>11111111111111111111101100101110</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_hex</primary>
+ </indexterm>
+ <function>to_hex</function> ( <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>to_hex</function> ( <type>bigint</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the number to its equivalent two's complement hexadecimal
+ representation.
+ </para>
+ <para>
+ <literal>to_hex(2147483647)</literal>
+ <returnvalue>7fffffff</returnvalue>
+ </para>
+ <para>
+ <literal>to_hex(-1234)</literal>
+ <returnvalue>fffffb2e</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_oct</primary>
+ </indexterm>
+ <function>to_oct</function> ( <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>to_oct</function> ( <type>bigint</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the number to its equivalent two's complement octal
+ representation.
+ </para>
+ <para>
+ <literal>to_oct(2147483647)</literal>
+ <returnvalue>17777777777</returnvalue>
+ </para>
+ <para>
+ <literal>to_oct(-1234)</literal>
+ <returnvalue>37777775456</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>translate</primary>
+ </indexterm>
+ <function>translate</function> ( <parameter>string</parameter> <type>text</type>,
+ <parameter>from</parameter> <type>text</type>,
+ <parameter>to</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Replaces each character in <parameter>string</parameter> that
+ matches a character in the <parameter>from</parameter> set with the
+ corresponding character in the <parameter>to</parameter>
+ set. If <parameter>from</parameter> is longer than
+ <parameter>to</parameter>, occurrences of the extra characters in
+ <parameter>from</parameter> are deleted.
+ </para>
+ <para>
+ <literal>translate('12345', '143', 'ax')</literal>
+ <returnvalue>a2x5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>unistr</primary>
+ </indexterm>
+ <function>unistr</function> ( <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Evaluate escaped Unicode characters in the argument. Unicode characters
+ can be specified as
+ <literal>\<replaceable>XXXX</replaceable></literal> (4 hexadecimal
+ digits), <literal>\+<replaceable>XXXXXX</replaceable></literal> (6
+ hexadecimal digits),
+ <literal>\u<replaceable>XXXX</replaceable></literal> (4 hexadecimal
+ digits), or <literal>\U<replaceable>XXXXXXXX</replaceable></literal>
+ (8 hexadecimal digits). To specify a backslash, write two
+ backslashes. All other characters are taken literally.
+ </para>
+
+ <para>
+ If the server encoding is not UTF-8, the Unicode code point identified
+ by one of these escape sequences is converted to the actual server
+ encoding; an error is reported if that's not possible.
+ </para>
+
+ <para>
+ This function provides a (non-standard) alternative to string
+ constants with Unicode escapes (see <xref
+ linkend="sql-syntax-strings-uescape"/>).
+ </para>
+
+ <para>
+ <literal>unistr('d\0061t\+000061')</literal>
+ <returnvalue>data</returnvalue>
+ </para>
+ <para>
+ <literal>unistr('d\u0061t\U00000061')</literal>
+ <returnvalue>data</returnvalue>
+ </para></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The <function>concat</function>, <function>concat_ws</function> and
+ <function>format</function> functions are variadic, so it is possible to
+ pass the values to be concatenated or formatted as an array marked with
+ the <literal>VARIADIC</literal> keyword (see <xref
+ linkend="xfunc-sql-variadic-functions"/>). The array's elements are
+ treated as if they were separate ordinary arguments to the function.
+ If the variadic array argument is NULL, <function>concat</function>
+ and <function>concat_ws</function> return NULL, but
+ <function>format</function> treats a NULL as a zero-element array.
+ </para>
+
+ <para>
+ See also the aggregate function <function>string_agg</function> in
+ <xref linkend="functions-aggregate"/>, and the functions for
+ converting between strings and the <type>bytea</type> type in
+ <xref linkend="functions-binarystring-conversions"/>.
+ </para>
+
+ <sect2 id="functions-string-format">
+ <title><function>format</function></title>
+
+ <indexterm>
+ <primary>format</primary>
+ </indexterm>
+
+ <para>
+ The function <function>format</function> produces output formatted according to
+ a format string, in a style similar to the C function
+ <function>sprintf</function>.
+ </para>
+
+ <para>
+<synopsis>
+<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ])
+</synopsis>
+ <parameter>formatstr</parameter> is a format string that specifies how the
+ result should be formatted. Text in the format string is copied
+ directly to the result, except where <firstterm>format specifiers</firstterm> are
+ used. Format specifiers act as placeholders in the string, defining how
+ subsequent function arguments should be formatted and inserted into the
+ result. Each <parameter>formatarg</parameter> argument is converted to text
+ according to the usual output rules for its data type, and then formatted
+ and inserted into the result string according to the format specifier(s).
+ </para>
+
+ <para>
+ Format specifiers are introduced by a <literal>%</literal> character and have
+ the form
+<synopsis>
+%[<parameter>position</parameter>][<parameter>flags</parameter>][<parameter>width</parameter>]<parameter>type</parameter>
+</synopsis>
+ where the component fields are:
+
+ <variablelist>
+ <varlistentry>
+ <term><parameter>position</parameter> (optional)</term>
+ <listitem>
+ <para>
+ A string of the form <literal><parameter>n</parameter>$</literal> where
+ <parameter>n</parameter> is the index of the argument to print.
+ Index 1 means the first argument after
+ <parameter>formatstr</parameter>. If the <parameter>position</parameter> is
+ omitted, the default is to use the next argument in sequence.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><parameter>flags</parameter> (optional)</term>
+ <listitem>
+ <para>
+ Additional options controlling how the format specifier's output is
+ formatted. Currently the only supported flag is a minus sign
+ (<literal>-</literal>) which will cause the format specifier's output to be
+ left-justified. This has no effect unless the <parameter>width</parameter>
+ field is also specified.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><parameter>width</parameter> (optional)</term>
+ <listitem>
+ <para>
+ Specifies the <emphasis>minimum</emphasis> number of characters to use to
+ display the format specifier's output. The output is padded on the
+ left or right (depending on the <literal>-</literal> flag) with spaces as
+ needed to fill the width. A too-small width does not cause
+ truncation of the output, but is simply ignored. The width may be
+ specified using any of the following: a positive integer; an
+ asterisk (<literal>*</literal>) to use the next function argument as the
+ width; or a string of the form <literal>*<parameter>n</parameter>$</literal> to
+ use the <parameter>n</parameter>th function argument as the width.
+ </para>
+
+ <para>
+ If the width comes from a function argument, that argument is
+ consumed before the argument that is used for the format specifier's
+ value. If the width argument is negative, the result is left
+ aligned (as if the <literal>-</literal> flag had been specified) within a
+ field of length <function>abs</function>(<parameter>width</parameter>).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><parameter>type</parameter> (required)</term>
+ <listitem>
+ <para>
+ The type of format conversion to use to produce the format
+ specifier's output. The following types are supported:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>s</literal> formats the argument value as a simple
+ string. A null value is treated as an empty string.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>I</literal> treats the argument value as an SQL
+ identifier, double-quoting it if necessary.
+ It is an error for the value to be null (equivalent to
+ <function>quote_ident</function>).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>L</literal> quotes the argument value as an SQL literal.
+ A null value is displayed as the string <literal>NULL</literal>, without
+ quotes (equivalent to <function>quote_nullable</function>).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ In addition to the format specifiers described above, the special sequence
+ <literal>%%</literal> may be used to output a literal <literal>%</literal> character.
+ </para>
+
+ <para>
+ Here are some examples of the basic format conversions:
+
+<screen>
+SELECT format('Hello %s', 'World');
+<lineannotation>Result: </lineannotation><computeroutput>Hello World</computeroutput>
+
+SELECT format('Testing %s, %s, %s, %%', 'one', 'two', 'three');
+<lineannotation>Result: </lineannotation><computeroutput>Testing one, two, three, %</computeroutput>
+
+SELECT format('INSERT INTO %I VALUES(%L)', 'Foo bar', E'O\'Reilly');
+<lineannotation>Result: </lineannotation><computeroutput>INSERT INTO "Foo bar" VALUES('O''Reilly')</computeroutput>
+
+SELECT format('INSERT INTO %I VALUES(%L)', 'locations', 'C:\Program Files');
+<lineannotation>Result: </lineannotation><computeroutput>INSERT INTO locations VALUES('C:\Program Files')</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ Here are examples using <parameter>width</parameter> fields
+ and the <literal>-</literal> flag:
+
+<screen>
+SELECT format('|%10s|', 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
+
+SELECT format('|%-10s|', 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
+
+SELECT format('|%*s|', 10, 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
+
+SELECT format('|%*s|', -10, 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
+
+SELECT format('|%-*s|', 10, 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
+
+SELECT format('|%-*s|', -10, 'foo');
+<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ These examples show use of <parameter>position</parameter> fields:
+
+<screen>
+SELECT format('Testing %3$s, %2$s, %1$s', 'one', 'two', 'three');
+<lineannotation>Result: </lineannotation><computeroutput>Testing three, two, one</computeroutput>
+
+SELECT format('|%*2$s|', 'foo', 10, 'bar');
+<lineannotation>Result: </lineannotation><computeroutput>| bar|</computeroutput>
+
+SELECT format('|%1$*2$s|', 'foo', 10, 'bar');
+<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ Unlike the standard C function <function>sprintf</function>,
+ <productname>PostgreSQL</productname>'s <function>format</function> function allows format
+ specifiers with and without <parameter>position</parameter> fields to be mixed
+ in the same format string. A format specifier without a
+ <parameter>position</parameter> field always uses the next argument after the
+ last argument consumed.
+ In addition, the <function>format</function> function does not require all
+ function arguments to be used in the format string.
+ For example:
+
+<screen>
+SELECT format('Testing %3$s, %2$s, %s', 'one', 'two', 'three');
+<lineannotation>Result: </lineannotation><computeroutput>Testing three, two, three</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ The <literal>%I</literal> and <literal>%L</literal> format specifiers are particularly
+ useful for safely constructing dynamic SQL statements. See
+ <xref linkend="plpgsql-quote-literal-example"/>.
+ </para>
+ </sect2>
+
+ </sect1>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 1928de57..5c0847f4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -2403,1778 +2403,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
</sect1>
-
- <sect1 id="functions-string">
- <title>String Functions and Operators</title>
-
- <para>
- This section describes functions and operators for examining and
- manipulating string values. Strings in this context include values
- of the types <type>character</type>, <type>character varying</type>,
- and <type>text</type>. Except where noted, these functions and operators
- are declared to accept and return type <type>text</type>. They will
- interchangeably accept <type>character varying</type> arguments.
- Values of type <type>character</type> will be converted
- to <type>text</type> before the function or operator is applied, resulting
- in stripping any trailing spaces in the <type>character</type> value.
- </para>
-
- <para>
- <acronym>SQL</acronym> defines some string functions that use
- key words, rather than commas, to separate
- arguments. Details are in
- <xref linkend="functions-string-sql"/>.
- <productname>PostgreSQL</productname> also provides versions of these functions
- that use the regular function invocation syntax
- (see <xref linkend="functions-string-other"/>).
- </para>
-
- <note>
- <para>
- The string concatenation operator (<literal>||</literal>) will accept
- non-string input, so long as at least one input is of string type, as shown
- in <xref linkend="functions-string-sql"/>. For other cases, inserting an
- explicit coercion to <type>text</type> can be used to have non-string input
- accepted.
- </para>
- </note>
-
- <table id="functions-string-sql">
- <title><acronym>SQL</acronym> String Functions and Operators</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function/Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>character string</primary>
- <secondary>concatenation</secondary>
- </indexterm>
- <type>text</type> <literal>||</literal> <type>text</type>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Concatenates the two strings.
- </para>
- <para>
- <literal>'Post' || 'greSQL'</literal>
- <returnvalue>PostgreSQL</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>text</type> <literal>||</literal> <type>anynonarray</type>
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <type>anynonarray</type> <literal>||</literal> <type>text</type>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the non-string input to text, then concatenates the two
- strings. (The non-string input cannot be of an array type, because
- that would create ambiguity with the array <literal>||</literal>
- operators. If you want to concatenate an array's text equivalent,
- cast it to <type>text</type> explicitly.)
- </para>
- <para>
- <literal>'Value: ' || 42</literal>
- <returnvalue>Value: 42</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>btrim</primary>
- </indexterm>
- <function>btrim</function> ( <parameter>string</parameter> <type>text</type>
- <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Removes the longest string containing only characters
- in <parameter>characters</parameter> (a space by default)
- from the start and end of <parameter>string</parameter>.
- </para>
- <para>
- <literal>btrim('xyxtrimyyx', 'xyz')</literal>
- <returnvalue>trim</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>normalized</primary>
- </indexterm>
- <indexterm>
- <primary>Unicode normalization</primary>
- </indexterm>
- <type>text</type> <literal>IS</literal> <optional><literal>NOT</literal></optional> <optional><parameter>form</parameter></optional> <literal>NORMALIZED</literal>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Checks whether the string is in the specified Unicode normalization
- form. The optional <parameter>form</parameter> key word specifies the
- form: <literal>NFC</literal> (the default), <literal>NFD</literal>,
- <literal>NFKC</literal>, or <literal>NFKD</literal>. This expression can
- only be used when the server encoding is <literal>UTF8</literal>. Note
- that checking for normalization using this expression is often faster
- than normalizing possibly already normalized strings.
- </para>
- <para>
- <literal>U&'\0061\0308bc' IS NFD NORMALIZED</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bit_length</primary>
- </indexterm>
- <function>bit_length</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns number of bits in the string (8
- times the <function>octet_length</function>).
- </para>
- <para>
- <literal>bit_length('jose')</literal>
- <returnvalue>32</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>char_length</primary>
- </indexterm>
- <indexterm>
- <primary>character string</primary>
- <secondary>length</secondary>
- </indexterm>
- <indexterm>
- <primary>length</primary>
- <secondary sortas="character string">of a character string</secondary>
- <see>character string, length</see>
- </indexterm>
- <function>char_length</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>character_length</primary>
- </indexterm>
- <function>character_length</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns number of characters in the string.
- </para>
- <para>
- <literal>char_length('josé')</literal>
- <returnvalue>4</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>lower</primary>
- </indexterm>
- <function>lower</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the string to all lower case, according to the rules of the
- database's locale.
- </para>
- <para>
- <literal>lower('TOM')</literal>
- <returnvalue>tom</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>lpad</primary>
- </indexterm>
- <function>lpad</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>length</parameter> <type>integer</type>
- <optional>, <parameter>fill</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extends the <parameter>string</parameter> to length
- <parameter>length</parameter> by prepending the characters
- <parameter>fill</parameter> (a space by default). If the
- <parameter>string</parameter> is already longer than
- <parameter>length</parameter> then it is truncated (on the right).
- </para>
- <para>
- <literal>lpad('hi', 5, 'xy')</literal>
- <returnvalue>xyxhi</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>ltrim</primary>
- </indexterm>
- <function>ltrim</function> ( <parameter>string</parameter> <type>text</type>
- <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Removes the longest string containing only characters in
- <parameter>characters</parameter> (a space by default) from the start of
- <parameter>string</parameter>.
- </para>
- <para>
- <literal>ltrim('zzzytest', 'xyz')</literal>
- <returnvalue>test</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>normalize</primary>
- </indexterm>
- <indexterm>
- <primary>Unicode normalization</primary>
- </indexterm>
- <function>normalize</function> ( <type>text</type>
- <optional>, <parameter>form</parameter> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the string to the specified Unicode
- normalization form. The optional <parameter>form</parameter> key word
- specifies the form: <literal>NFC</literal> (the default),
- <literal>NFD</literal>, <literal>NFKC</literal>, or
- <literal>NFKD</literal>. This function can only be used when the
- server encoding is <literal>UTF8</literal>.
- </para>
- <para>
- <literal>normalize(U&'\0061\0308bc', NFC)</literal>
- <returnvalue>U&'\00E4bc'</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>octet_length</primary>
- </indexterm>
- <function>octet_length</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns number of bytes in the string.
- </para>
- <para>
- <literal>octet_length('josé')</literal>
- <returnvalue>5</returnvalue> (if server encoding is UTF8)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>octet_length</primary>
- </indexterm>
- <function>octet_length</function> ( <type>character</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns number of bytes in the string. Since this version of the
- function accepts type <type>character</type> directly, it will not
- strip trailing spaces.
- </para>
- <para>
- <literal>octet_length('abc '::character(4))</literal>
- <returnvalue>4</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>overlay</primary>
- </indexterm>
- <function>overlay</function> ( <parameter>string</parameter> <type>text</type> <literal>PLACING</literal> <parameter>newsubstring</parameter> <type>text</type> <literal>FROM</literal> <parameter>start</parameter> <type>integer</type> <optional> <literal>FOR</literal> <parameter>count</parameter> <type>integer</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Replaces the substring of <parameter>string</parameter> that starts at
- the <parameter>start</parameter>'th character and extends
- for <parameter>count</parameter> characters
- with <parameter>newsubstring</parameter>.
- If <parameter>count</parameter> is omitted, it defaults to the length
- of <parameter>newsubstring</parameter>.
- </para>
- <para>
- <literal>overlay('Txxxxas' placing 'hom' from 2 for 4)</literal>
- <returnvalue>Thomas</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>position</primary>
- </indexterm>
- <function>position</function> ( <parameter>substring</parameter> <type>text</type> <literal>IN</literal> <parameter>string</parameter> <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns first starting index of the specified
- <parameter>substring</parameter> within
- <parameter>string</parameter>, or zero if it's not present.
- </para>
- <para>
- <literal>position('om' in 'Thomas')</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>rpad</primary>
- </indexterm>
- <function>rpad</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>length</parameter> <type>integer</type>
- <optional>, <parameter>fill</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extends the <parameter>string</parameter> to length
- <parameter>length</parameter> by appending the characters
- <parameter>fill</parameter> (a space by default). If the
- <parameter>string</parameter> is already longer than
- <parameter>length</parameter> then it is truncated.
- </para>
- <para>
- <literal>rpad('hi', 5, 'xy')</literal>
- <returnvalue>hixyx</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>rtrim</primary>
- </indexterm>
- <function>rtrim</function> ( <parameter>string</parameter> <type>text</type>
- <optional>, <parameter>characters</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Removes the longest string containing only characters in
- <parameter>characters</parameter> (a space by default) from the end of
- <parameter>string</parameter>.
- </para>
- <para>
- <literal>rtrim('testxxzx', 'xyz')</literal>
- <returnvalue>test</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>substring</primary>
- </indexterm>
- <function>substring</function> ( <parameter>string</parameter> <type>text</type> <optional> <literal>FROM</literal> <parameter>start</parameter> <type>integer</type> </optional> <optional> <literal>FOR</literal> <parameter>count</parameter> <type>integer</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts the substring of <parameter>string</parameter> starting at
- the <parameter>start</parameter>'th character if that is specified,
- and stopping after <parameter>count</parameter> characters if that is
- specified. Provide at least one of <parameter>start</parameter>
- and <parameter>count</parameter>.
- </para>
- <para>
- <literal>substring('Thomas' from 2 for 3)</literal>
- <returnvalue>hom</returnvalue>
- </para>
- <para>
- <literal>substring('Thomas' from 3)</literal>
- <returnvalue>omas</returnvalue>
- </para>
- <para>
- <literal>substring('Thomas' for 2)</literal>
- <returnvalue>Th</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>FROM</literal> <parameter>pattern</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts the first substring matching POSIX regular expression; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>substring('Thomas' from '...$')</literal>
- <returnvalue>mas</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>SIMILAR</literal> <parameter>pattern</parameter> <type>text</type> <literal>ESCAPE</literal> <parameter>escape</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>substring</function> ( <parameter>string</parameter> <type>text</type> <literal>FROM</literal> <parameter>pattern</parameter> <type>text</type> <literal>FOR</literal> <parameter>escape</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts the first substring matching <acronym>SQL</acronym> regular expression;
- see <xref linkend="functions-similarto-regexp"/>. The first form has
- been specified since SQL:2003; the second form was only in SQL:1999
- and should be considered obsolete.
- </para>
- <para>
- <literal>substring('Thomas' similar '%#"o_a#"_' escape '#')</literal>
- <returnvalue>oma</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>trim</primary>
- </indexterm>
- <function>trim</function> ( <optional> <literal>LEADING</literal> | <literal>TRAILING</literal> | <literal>BOTH</literal> </optional>
- <optional> <parameter>characters</parameter> <type>text</type> </optional> <literal>FROM</literal>
- <parameter>string</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Removes the longest string containing only characters in
- <parameter>characters</parameter> (a space by default) from the
- start, end, or both ends (<literal>BOTH</literal> is the default)
- of <parameter>string</parameter>.
- </para>
- <para>
- <literal>trim(both 'xyz' from 'yxTomxx')</literal>
- <returnvalue>Tom</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>trim</function> ( <optional> <literal>LEADING</literal> | <literal>TRAILING</literal> | <literal>BOTH</literal> </optional> <optional> <literal>FROM</literal> </optional>
- <parameter>string</parameter> <type>text</type> <optional>,
- <parameter>characters</parameter> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- This is a non-standard syntax for <function>trim()</function>.
- </para>
- <para>
- <literal>trim(both from 'yxTomxx', 'xyz')</literal>
- <returnvalue>Tom</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>unicode_assigned</primary>
- </indexterm>
- <function>unicode_assigned</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns <literal>true</literal> if all characters in the string are
- assigned Unicode codepoints; <literal>false</literal> otherwise. This
- function can only be used when the server encoding is
- <literal>UTF8</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>upper</primary>
- </indexterm>
- <function>upper</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the string to all upper case, according to the rules of the
- database's locale.
- </para>
- <para>
- <literal>upper('tom')</literal>
- <returnvalue>TOM</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Additional string manipulation functions and operators are available
- and are listed in <xref linkend="functions-string-other"/>. (Some of
- these are used internally to implement
- the <acronym>SQL</acronym>-standard string functions listed in
- <xref linkend="functions-string-sql"/>.)
- There are also pattern-matching operators, which are described in
- <xref linkend="functions-matching"/>, and operators for full-text
- search, which are described in <xref linkend="textsearch"/>.
- </para>
-
- <table id="functions-string-other">
- <title>Other String Functions and Operators</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function/Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>character string</primary>
- <secondary>prefix test</secondary>
- </indexterm>
- <type>text</type> <literal>^@</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if the first string starts with the second string
- (equivalent to the <function>starts_with()</function> function).
- </para>
- <para>
- <literal>'alphabet' ^@ 'alph'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>ascii</primary>
- </indexterm>
- <function>ascii</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the numeric code of the first character of the argument.
- In <acronym>UTF8</acronym> encoding, returns the Unicode code point
- of the character. In other multibyte encodings, the argument must
- be an <acronym>ASCII</acronym> character.
- </para>
- <para>
- <literal>ascii('x')</literal>
- <returnvalue>120</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>chr</primary>
- </indexterm>
- <function>chr</function> ( <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the character with the given code. In <acronym>UTF8</acronym>
- encoding the argument is treated as a Unicode code point. In other
- multibyte encodings the argument must designate
- an <acronym>ASCII</acronym> character. <literal>chr(0)</literal> is
- disallowed because text data types cannot store that character.
- </para>
- <para>
- <literal>chr(65)</literal>
- <returnvalue>A</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>concat</primary>
- </indexterm>
- <function>concat</function> ( <parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Concatenates the text representations of all the arguments.
- NULL arguments are ignored.
- </para>
- <para>
- <literal>concat('abcde', 2, NULL, 22)</literal>
- <returnvalue>abcde222</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>concat_ws</primary>
- </indexterm>
- <function>concat_ws</function> ( <parameter>sep</parameter> <type>text</type>,
- <parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Concatenates all but the first argument, with separators. The first
- argument is used as the separator string, and should not be NULL.
- Other NULL arguments are ignored.
- </para>
- <para>
- <literal>concat_ws(',', 'abcde', 2, NULL, 22)</literal>
- <returnvalue>abcde,2,22</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>format</primary>
- </indexterm>
- <function>format</function> ( <parameter>formatstr</parameter> <type>text</type>
- [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Formats arguments according to a format string;
- see <xref linkend="functions-string-format"/>.
- This function is similar to the C function <function>sprintf</function>.
- </para>
- <para>
- <literal>format('Hello %s, %1$s', 'World')</literal>
- <returnvalue>Hello World, World</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>initcap</primary>
- </indexterm>
- <function>initcap</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the first letter of each word to upper case and the
- rest to lower case. Words are sequences of alphanumeric
- characters separated by non-alphanumeric characters.
- </para>
- <para>
- <literal>initcap('hi THOMAS')</literal>
- <returnvalue>Hi Thomas</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>left</primary>
- </indexterm>
- <function>left</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>n</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns first <parameter>n</parameter> characters in the
- string, or when <parameter>n</parameter> is negative, returns
- all but last |<parameter>n</parameter>| characters.
- </para>
- <para>
- <literal>left('abcde', 2)</literal>
- <returnvalue>ab</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>length</primary>
- </indexterm>
- <function>length</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the number of characters in the string.
- </para>
- <para>
- <literal>length('jose')</literal>
- <returnvalue>4</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>md5</primary>
- </indexterm>
- <function>md5</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Computes the MD5 <link linkend="functions-hash-note">hash</link> of
- the argument, with the result written in hexadecimal.
- </para>
- <para>
- <literal>md5('abc')</literal>
- <returnvalue>900150983cd24fb0&zwsp;d6963f7d28e17f72</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>parse_ident</primary>
- </indexterm>
- <function>parse_ident</function> ( <parameter>qualified_identifier</parameter> <type>text</type>
- [, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> ] )
- <returnvalue>text[]</returnvalue>
- </para>
- <para>
- Splits <parameter>qualified_identifier</parameter> into an array of
- identifiers, removing any quoting of individual identifiers. By
- default, extra characters after the last identifier are considered an
- error; but if the second parameter is <literal>false</literal>, then such
- extra characters are ignored. (This behavior is useful for parsing
- names for objects like functions.) Note that this function does not
- truncate over-length identifiers. If you want truncation you can cast
- the result to <type>name[]</type>.
- </para>
- <para>
- <literal>parse_ident('"SomeSchema".someTable')</literal>
- <returnvalue>{SomeSchema,sometable}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_client_encoding</primary>
- </indexterm>
- <function>pg_client_encoding</function> ( )
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns current client encoding name.
- </para>
- <para>
- <literal>pg_client_encoding()</literal>
- <returnvalue>UTF8</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>quote_ident</primary>
- </indexterm>
- <function>quote_ident</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the given string suitably quoted to be used as an identifier
- in an <acronym>SQL</acronym> statement string.
- Quotes are added only if necessary (i.e., if the string contains
- non-identifier characters or would be case-folded).
- Embedded quotes are properly doubled.
- See also <xref linkend="plpgsql-quote-literal-example"/>.
- </para>
- <para>
- <literal>quote_ident('Foo bar')</literal>
- <returnvalue>"Foo bar"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>quote_literal</primary>
- </indexterm>
- <function>quote_literal</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the given string suitably quoted to be used as a string literal
- in an <acronym>SQL</acronym> statement string.
- Embedded single-quotes and backslashes are properly doubled.
- Note that <function>quote_literal</function> returns null on null
- input; if the argument might be null,
- <function>quote_nullable</function> is often more suitable.
- See also <xref linkend="plpgsql-quote-literal-example"/>.
- </para>
- <para>
- <literal>quote_literal(E'O\'Reilly')</literal>
- <returnvalue>'O''Reilly'</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>quote_literal</function> ( <type>anyelement</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the given value to text and then quotes it as a literal.
- Embedded single-quotes and backslashes are properly doubled.
- </para>
- <para>
- <literal>quote_literal(42.5)</literal>
- <returnvalue>'42.5'</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>quote_nullable</primary>
- </indexterm>
- <function>quote_nullable</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the given string suitably quoted to be used as a string literal
- in an <acronym>SQL</acronym> statement string; or, if the argument
- is null, returns <literal>NULL</literal>.
- Embedded single-quotes and backslashes are properly doubled.
- See also <xref linkend="plpgsql-quote-literal-example"/>.
- </para>
- <para>
- <literal>quote_nullable(NULL)</literal>
- <returnvalue>NULL</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>quote_nullable</function> ( <type>anyelement</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the given value to text and then quotes it as a literal;
- or, if the argument is null, returns <literal>NULL</literal>.
- Embedded single-quotes and backslashes are properly doubled.
- </para>
- <para>
- <literal>quote_nullable(42.5)</literal>
- <returnvalue>'42.5'</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_count</primary>
- </indexterm>
- <function>regexp_count</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type> ] ] )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the number of times the POSIX regular
- expression <parameter>pattern</parameter> matches in
- the <parameter>string</parameter>; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_count('123456789012', '\d\d\d', 2)</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_instr</primary>
- </indexterm>
- <function>regexp_instr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>endoption</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] ] )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the position within <parameter>string</parameter> where
- the <parameter>N</parameter>'th match of the POSIX regular
- expression <parameter>pattern</parameter> occurs, or zero if there is
- no such match; see <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_instr('ABCDEF', 'c(.)(..)', 1, 1, 0, 'i')</literal>
- <returnvalue>3</returnvalue>
- </para>
- <para>
- <literal>regexp_instr('ABCDEF', 'c(.)(..)', 1, 1, 0, 'i', 2)</literal>
- <returnvalue>5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_like</primary>
- </indexterm>
- <function>regexp_like</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Checks whether a match of the POSIX regular
- expression <parameter>pattern</parameter> occurs
- within <parameter>string</parameter>; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_like('Hello World', 'world$', 'i')</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_match</primary>
- </indexterm>
- <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>text[]</returnvalue>
- </para>
- <para>
- Returns substrings within the first match of the POSIX regular
- expression <parameter>pattern</parameter> to
- the <parameter>string</parameter>; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_match('foobarbequebaz', '(bar)(beque)')</literal>
- <returnvalue>{bar,beque}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_matches</primary>
- </indexterm>
- <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>setof text[]</returnvalue>
- </para>
- <para>
- Returns substrings within the first match of the POSIX regular
- expression <parameter>pattern</parameter> to
- the <parameter>string</parameter>, or substrings within all
- such matches if the <literal>g</literal> flag is used;
- see <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_matches('foobarbequebaz', 'ba.', 'g')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- {bar}
- {baz}
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_replace</primary>
- </indexterm>
- <function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type> ]
- [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Replaces the substring that is the first match to the POSIX
- regular expression <parameter>pattern</parameter>, or all such
- matches if the <literal>g</literal> flag is used; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_replace('Thomas', '.[mN]a.', 'M')</literal>
- <returnvalue>ThM</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>regexp_replace</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>, <parameter>replacement</parameter> <type>text</type>,
- <parameter>start</parameter> <type>integer</type>,
- <parameter>N</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Replaces the substring that is the <parameter>N</parameter>'th
- match to the POSIX regular expression <parameter>pattern</parameter>,
- or all such matches if <parameter>N</parameter> is zero; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_replace('Thomas', '.', 'X', 3, 2)</literal>
- <returnvalue>ThoXas</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_split_to_array</primary>
- </indexterm>
- <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>text[]</returnvalue>
- </para>
- <para>
- Splits <parameter>string</parameter> using a POSIX regular
- expression as the delimiter, producing an array of results; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_split_to_array('hello world', '\s+')</literal>
- <returnvalue>{hello,world}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_split_to_table</primary>
- </indexterm>
- <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Splits <parameter>string</parameter> using a POSIX regular
- expression as the delimiter, producing a set of results; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_split_to_table('hello world', '\s+')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- hello
- world
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regexp_substr</primary>
- </indexterm>
- <function>regexp_substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the substring within <parameter>string</parameter> that
- matches the <parameter>N</parameter>'th occurrence of the POSIX
- regular expression <parameter>pattern</parameter>,
- or <literal>NULL</literal> if there is no such match; see
- <xref linkend="functions-posix-regexp"/>.
- </para>
- <para>
- <literal>regexp_substr('ABCDEF', 'c(.)(..)', 1, 1, 'i')</literal>
- <returnvalue>CDEF</returnvalue>
- </para>
- <para>
- <literal>regexp_substr('ABCDEF', 'c(.)(..)', 1, 1, 'i', 2)</literal>
- <returnvalue>EF</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>repeat</primary>
- </indexterm>
- <function>repeat</function> ( <parameter>string</parameter> <type>text</type>, <parameter>number</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Repeats <parameter>string</parameter> the specified
- <parameter>number</parameter> of times.
- </para>
- <para>
- <literal>repeat('Pg', 4)</literal>
- <returnvalue>PgPgPgPg</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>replace</primary>
- </indexterm>
- <function>replace</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>from</parameter> <type>text</type>,
- <parameter>to</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Replaces all occurrences in <parameter>string</parameter> of
- substring <parameter>from</parameter> with
- substring <parameter>to</parameter>.
- </para>
- <para>
- <literal>replace('abcdefabcdef', 'cd', 'XX')</literal>
- <returnvalue>abXXefabXXef</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>reverse</primary>
- </indexterm>
- <function>reverse</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reverses the order of the characters in the string.
- </para>
- <para>
- <literal>reverse('abcde')</literal>
- <returnvalue>edcba</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>right</primary>
- </indexterm>
- <function>right</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>n</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns last <parameter>n</parameter> characters in the string,
- or when <parameter>n</parameter> is negative, returns all but
- first |<parameter>n</parameter>| characters.
- </para>
- <para>
- <literal>right('abcde', 2)</literal>
- <returnvalue>de</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>split_part</primary>
- </indexterm>
- <function>split_part</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>delimiter</parameter> <type>text</type>,
- <parameter>n</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Splits <parameter>string</parameter> at occurrences
- of <parameter>delimiter</parameter> and returns
- the <parameter>n</parameter>'th field (counting from one),
- or when <parameter>n</parameter> is negative, returns
- the |<parameter>n</parameter>|'th-from-last field.
- </para>
- <para>
- <literal>split_part('abc~@~def~@~ghi', '~@~', 2)</literal>
- <returnvalue>def</returnvalue>
- </para>
- <para>
- <literal>split_part('abc,def,ghi,jkl', ',', -2)</literal>
- <returnvalue>ghi</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>starts_with</primary>
- </indexterm>
- <function>starts_with</function> ( <parameter>string</parameter> <type>text</type>, <parameter>prefix</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if <parameter>string</parameter> starts
- with <parameter>prefix</parameter>.
- </para>
- <para>
- <literal>starts_with('alphabet', 'alph')</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm id="function-string-to-array">
- <primary>string_to_array</primary>
- </indexterm>
- <function>string_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>delimiter</parameter> <type>text</type> <optional>, <parameter>null_string</parameter> <type>text</type> </optional> )
- <returnvalue>text[]</returnvalue>
- </para>
- <para>
- Splits the <parameter>string</parameter> at occurrences
- of <parameter>delimiter</parameter> and forms the resulting fields
- into a <type>text</type> array.
- If <parameter>delimiter</parameter> is <literal>NULL</literal>,
- each character in the <parameter>string</parameter> will become a
- separate element in the array.
- If <parameter>delimiter</parameter> is an empty string, then
- the <parameter>string</parameter> is treated as a single field.
- If <parameter>null_string</parameter> is supplied and is
- not <literal>NULL</literal>, fields matching that string are
- replaced by <literal>NULL</literal>.
- See also <link linkend="function-array-to-string"><function>array_to_string</function></link>.
- </para>
- <para>
- <literal>string_to_array('xx~~yy~~zz', '~~', 'yy')</literal>
- <returnvalue>{xx,NULL,zz}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>string_to_table</primary>
- </indexterm>
- <function>string_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>delimiter</parameter> <type>text</type> <optional>, <parameter>null_string</parameter> <type>text</type> </optional> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Splits the <parameter>string</parameter> at occurrences
- of <parameter>delimiter</parameter> and returns the resulting fields
- as a set of <type>text</type> rows.
- If <parameter>delimiter</parameter> is <literal>NULL</literal>,
- each character in the <parameter>string</parameter> will become a
- separate row of the result.
- If <parameter>delimiter</parameter> is an empty string, then
- the <parameter>string</parameter> is treated as a single field.
- If <parameter>null_string</parameter> is supplied and is
- not <literal>NULL</literal>, fields matching that string are
- replaced by <literal>NULL</literal>.
- </para>
- <para>
- <literal>string_to_table('xx~^~yy~^~zz', '~^~', 'yy')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- xx
- NULL
- zz
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>strpos</primary>
- </indexterm>
- <function>strpos</function> ( <parameter>string</parameter> <type>text</type>, <parameter>substring</parameter> <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns first starting index of the specified <parameter>substring</parameter>
- within <parameter>string</parameter>, or zero if it's not present.
- (Same as <literal>position(<parameter>substring</parameter> in
- <parameter>string</parameter>)</literal>, but note the reversed
- argument order.)
- </para>
- <para>
- <literal>strpos('high', 'ig')</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>substr</primary>
- </indexterm>
- <function>substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>start</parameter> <type>integer</type> <optional>, <parameter>count</parameter> <type>integer</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts the substring of <parameter>string</parameter> starting at
- the <parameter>start</parameter>'th character,
- and extending for <parameter>count</parameter> characters if that is
- specified. (Same
- as <literal>substring(<parameter>string</parameter>
- from <parameter>start</parameter>
- for <parameter>count</parameter>)</literal>.)
- </para>
- <para>
- <literal>substr('alphabet', 3)</literal>
- <returnvalue>phabet</returnvalue>
- </para>
- <para>
- <literal>substr('alphabet', 3, 2)</literal>
- <returnvalue>ph</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_ascii</primary>
- </indexterm>
- <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>encoding</parameter> <type>name</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>to_ascii</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>encoding</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts <parameter>string</parameter> to <acronym>ASCII</acronym>
- from another encoding, which may be identified by name or number.
- If <parameter>encoding</parameter> is omitted the database encoding
- is assumed (which in practice is the only useful case).
- The conversion consists primarily of dropping accents.
- Conversion is only supported
- from <literal>LATIN1</literal>, <literal>LATIN2</literal>,
- <literal>LATIN9</literal>, and <literal>WIN1250</literal> encodings.
- (See the <xref linkend="unaccent"/> module for another, more flexible
- solution.)
- </para>
- <para>
- <literal>to_ascii('Karél')</literal>
- <returnvalue>Karel</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_bin</primary>
- </indexterm>
- <function>to_bin</function> ( <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>to_bin</function> ( <type>bigint</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the number to its equivalent two's complement binary
- representation.
- </para>
- <para>
- <literal>to_bin(2147483647)</literal>
- <returnvalue>1111111111111111111111111111111</returnvalue>
- </para>
- <para>
- <literal>to_bin(-1234)</literal>
- <returnvalue>11111111111111111111101100101110</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_hex</primary>
- </indexterm>
- <function>to_hex</function> ( <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>to_hex</function> ( <type>bigint</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the number to its equivalent two's complement hexadecimal
- representation.
- </para>
- <para>
- <literal>to_hex(2147483647)</literal>
- <returnvalue>7fffffff</returnvalue>
- </para>
- <para>
- <literal>to_hex(-1234)</literal>
- <returnvalue>fffffb2e</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_oct</primary>
- </indexterm>
- <function>to_oct</function> ( <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>to_oct</function> ( <type>bigint</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the number to its equivalent two's complement octal
- representation.
- </para>
- <para>
- <literal>to_oct(2147483647)</literal>
- <returnvalue>17777777777</returnvalue>
- </para>
- <para>
- <literal>to_oct(-1234)</literal>
- <returnvalue>37777775456</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>translate</primary>
- </indexterm>
- <function>translate</function> ( <parameter>string</parameter> <type>text</type>,
- <parameter>from</parameter> <type>text</type>,
- <parameter>to</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Replaces each character in <parameter>string</parameter> that
- matches a character in the <parameter>from</parameter> set with the
- corresponding character in the <parameter>to</parameter>
- set. If <parameter>from</parameter> is longer than
- <parameter>to</parameter>, occurrences of the extra characters in
- <parameter>from</parameter> are deleted.
- </para>
- <para>
- <literal>translate('12345', '143', 'ax')</literal>
- <returnvalue>a2x5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>unistr</primary>
- </indexterm>
- <function>unistr</function> ( <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Evaluate escaped Unicode characters in the argument. Unicode characters
- can be specified as
- <literal>\<replaceable>XXXX</replaceable></literal> (4 hexadecimal
- digits), <literal>\+<replaceable>XXXXXX</replaceable></literal> (6
- hexadecimal digits),
- <literal>\u<replaceable>XXXX</replaceable></literal> (4 hexadecimal
- digits), or <literal>\U<replaceable>XXXXXXXX</replaceable></literal>
- (8 hexadecimal digits). To specify a backslash, write two
- backslashes. All other characters are taken literally.
- </para>
-
- <para>
- If the server encoding is not UTF-8, the Unicode code point identified
- by one of these escape sequences is converted to the actual server
- encoding; an error is reported if that's not possible.
- </para>
-
- <para>
- This function provides a (non-standard) alternative to string
- constants with Unicode escapes (see <xref
- linkend="sql-syntax-strings-uescape"/>).
- </para>
-
- <para>
- <literal>unistr('d\0061t\+000061')</literal>
- <returnvalue>data</returnvalue>
- </para>
- <para>
- <literal>unistr('d\u0061t\U00000061')</literal>
- <returnvalue>data</returnvalue>
- </para></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <function>concat</function>, <function>concat_ws</function> and
- <function>format</function> functions are variadic, so it is possible to
- pass the values to be concatenated or formatted as an array marked with
- the <literal>VARIADIC</literal> keyword (see <xref
- linkend="xfunc-sql-variadic-functions"/>). The array's elements are
- treated as if they were separate ordinary arguments to the function.
- If the variadic array argument is NULL, <function>concat</function>
- and <function>concat_ws</function> return NULL, but
- <function>format</function> treats a NULL as a zero-element array.
- </para>
-
- <para>
- See also the aggregate function <function>string_agg</function> in
- <xref linkend="functions-aggregate"/>, and the functions for
- converting between strings and the <type>bytea</type> type in
- <xref linkend="functions-binarystring-conversions"/>.
- </para>
-
- <sect2 id="functions-string-format">
- <title><function>format</function></title>
-
- <indexterm>
- <primary>format</primary>
- </indexterm>
-
- <para>
- The function <function>format</function> produces output formatted according to
- a format string, in a style similar to the C function
- <function>sprintf</function>.
- </para>
-
- <para>
-<synopsis>
-<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ])
-</synopsis>
- <parameter>formatstr</parameter> is a format string that specifies how the
- result should be formatted. Text in the format string is copied
- directly to the result, except where <firstterm>format specifiers</firstterm> are
- used. Format specifiers act as placeholders in the string, defining how
- subsequent function arguments should be formatted and inserted into the
- result. Each <parameter>formatarg</parameter> argument is converted to text
- according to the usual output rules for its data type, and then formatted
- and inserted into the result string according to the format specifier(s).
- </para>
-
- <para>
- Format specifiers are introduced by a <literal>%</literal> character and have
- the form
-<synopsis>
-%[<parameter>position</parameter>][<parameter>flags</parameter>][<parameter>width</parameter>]<parameter>type</parameter>
-</synopsis>
- where the component fields are:
-
- <variablelist>
- <varlistentry>
- <term><parameter>position</parameter> (optional)</term>
- <listitem>
- <para>
- A string of the form <literal><parameter>n</parameter>$</literal> where
- <parameter>n</parameter> is the index of the argument to print.
- Index 1 means the first argument after
- <parameter>formatstr</parameter>. If the <parameter>position</parameter> is
- omitted, the default is to use the next argument in sequence.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><parameter>flags</parameter> (optional)</term>
- <listitem>
- <para>
- Additional options controlling how the format specifier's output is
- formatted. Currently the only supported flag is a minus sign
- (<literal>-</literal>) which will cause the format specifier's output to be
- left-justified. This has no effect unless the <parameter>width</parameter>
- field is also specified.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><parameter>width</parameter> (optional)</term>
- <listitem>
- <para>
- Specifies the <emphasis>minimum</emphasis> number of characters to use to
- display the format specifier's output. The output is padded on the
- left or right (depending on the <literal>-</literal> flag) with spaces as
- needed to fill the width. A too-small width does not cause
- truncation of the output, but is simply ignored. The width may be
- specified using any of the following: a positive integer; an
- asterisk (<literal>*</literal>) to use the next function argument as the
- width; or a string of the form <literal>*<parameter>n</parameter>$</literal> to
- use the <parameter>n</parameter>th function argument as the width.
- </para>
-
- <para>
- If the width comes from a function argument, that argument is
- consumed before the argument that is used for the format specifier's
- value. If the width argument is negative, the result is left
- aligned (as if the <literal>-</literal> flag had been specified) within a
- field of length <function>abs</function>(<parameter>width</parameter>).
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><parameter>type</parameter> (required)</term>
- <listitem>
- <para>
- The type of format conversion to use to produce the format
- specifier's output. The following types are supported:
- <itemizedlist>
- <listitem>
- <para>
- <literal>s</literal> formats the argument value as a simple
- string. A null value is treated as an empty string.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>I</literal> treats the argument value as an SQL
- identifier, double-quoting it if necessary.
- It is an error for the value to be null (equivalent to
- <function>quote_ident</function>).
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>L</literal> quotes the argument value as an SQL literal.
- A null value is displayed as the string <literal>NULL</literal>, without
- quotes (equivalent to <function>quote_nullable</function>).
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>
- In addition to the format specifiers described above, the special sequence
- <literal>%%</literal> may be used to output a literal <literal>%</literal> character.
- </para>
-
- <para>
- Here are some examples of the basic format conversions:
-
-<screen>
-SELECT format('Hello %s', 'World');
-<lineannotation>Result: </lineannotation><computeroutput>Hello World</computeroutput>
-
-SELECT format('Testing %s, %s, %s, %%', 'one', 'two', 'three');
-<lineannotation>Result: </lineannotation><computeroutput>Testing one, two, three, %</computeroutput>
-
-SELECT format('INSERT INTO %I VALUES(%L)', 'Foo bar', E'O\'Reilly');
-<lineannotation>Result: </lineannotation><computeroutput>INSERT INTO "Foo bar" VALUES('O''Reilly')</computeroutput>
-
-SELECT format('INSERT INTO %I VALUES(%L)', 'locations', 'C:\Program Files');
-<lineannotation>Result: </lineannotation><computeroutput>INSERT INTO locations VALUES('C:\Program Files')</computeroutput>
-</screen>
- </para>
-
- <para>
- Here are examples using <parameter>width</parameter> fields
- and the <literal>-</literal> flag:
-
-<screen>
-SELECT format('|%10s|', 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
-
-SELECT format('|%-10s|', 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
-
-SELECT format('|%*s|', 10, 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
-
-SELECT format('|%*s|', -10, 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
-
-SELECT format('|%-*s|', 10, 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
-
-SELECT format('|%-*s|', -10, 'foo');
-<lineannotation>Result: </lineannotation><computeroutput>|foo |</computeroutput>
-</screen>
- </para>
-
- <para>
- These examples show use of <parameter>position</parameter> fields:
-
-<screen>
-SELECT format('Testing %3$s, %2$s, %1$s', 'one', 'two', 'three');
-<lineannotation>Result: </lineannotation><computeroutput>Testing three, two, one</computeroutput>
-
-SELECT format('|%*2$s|', 'foo', 10, 'bar');
-<lineannotation>Result: </lineannotation><computeroutput>| bar|</computeroutput>
-
-SELECT format('|%1$*2$s|', 'foo', 10, 'bar');
-<lineannotation>Result: </lineannotation><computeroutput>| foo|</computeroutput>
-</screen>
- </para>
-
- <para>
- Unlike the standard C function <function>sprintf</function>,
- <productname>PostgreSQL</productname>'s <function>format</function> function allows format
- specifiers with and without <parameter>position</parameter> fields to be mixed
- in the same format string. A format specifier without a
- <parameter>position</parameter> field always uses the next argument after the
- last argument consumed.
- In addition, the <function>format</function> function does not require all
- function arguments to be used in the format string.
- For example:
-
-<screen>
-SELECT format('Testing %3$s, %2$s, %s', 'one', 'two', 'three');
-<lineannotation>Result: </lineannotation><computeroutput>Testing three, two, three</computeroutput>
-</screen>
- </para>
-
- <para>
- The <literal>%I</literal> and <literal>%L</literal> format specifiers are particularly
- useful for safely constructing dynamic SQL statements. See
- <xref linkend="plpgsql-quote-literal-example"/>.
- </para>
- </sect2>
-
- </sect1>
+&func-string;
<sect1 id="functions-binarystring">
base-commit: 1713e3d6cd393fcc1d4873e75c7fa1f6c7023d75
--
2.34.1
v1-0006-split-sect1-functions-info-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0006-split-sect1-functions-info-from-func.sgml.patchDownload
From e0dd23cd9bbfcae5af64ccc248564176826617d9 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 15:12:49 +0800
Subject: [PATCH v1 6/7] split sect1: "functions-info" from func.sgml
"functions-info" lives in a new file: doc/src/sgml/func-info.sgml,
it will hold doc/src/sgml/html/functions-info.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-info.sgml | 3640 ++++++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 3641 +----------------------------------
3 files changed, 3642 insertions(+), 3640 deletions(-)
create mode 100644 doc/src/sgml/func-info.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 13694aca..4e80d2b4 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -23,6 +23,7 @@
<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
<!ENTITY func-json SYSTEM "func-json.sgml">
<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-info.sgml b/doc/src/sgml/func-info.sgml
new file mode 100644
index 00000000..c77302ff
--- /dev/null
+++ b/doc/src/sgml/func-info.sgml
@@ -0,0 +1,3640 @@
+ <sect1 id="functions-info">
+ <title>System Information Functions and Operators</title>
+
+ <para>
+ The functions described in this section are used to obtain various
+ information about a <productname>PostgreSQL</productname> installation.
+ </para>
+
+ <sect2 id="functions-info-session">
+ <title>Session Information Functions</title>
+
+ <para>
+ <xref linkend="functions-info-session-table"/> shows several
+ functions that extract session and system information.
+ </para>
+
+ <para>
+ In addition to the functions listed in this section, there are a number of
+ functions related to the statistics system that also provide system
+ information. See <xref linkend="monitoring-stats-functions"/> for more
+ information.
+ </para>
+
+ <table id="functions-info-session-table">
+ <title>Session Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_catalog</primary>
+ </indexterm>
+ <function>current_catalog</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>current_database</primary>
+ </indexterm>
+ <function>current_database</function> ()
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns the name of the current database. (Databases are
+ called <quote>catalogs</quote> in the SQL standard,
+ so <function>current_catalog</function> is the standard's
+ spelling.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_query</primary>
+ </indexterm>
+ <function>current_query</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the text of the currently executing query, as submitted
+ by the client (which might contain more than one statement).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_role</primary>
+ </indexterm>
+ <function>current_role</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ This is equivalent to <function>current_user</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_schema</primary>
+ </indexterm>
+ <indexterm>
+ <primary>schema</primary>
+ <secondary>current</secondary>
+ </indexterm>
+ <function>current_schema</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>current_schema</function> ()
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns the name of the schema that is first in the search path (or a
+ null value if the search path is empty). This is the schema that will
+ be used for any tables or other named objects that are created without
+ specifying a target schema.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_schemas</primary>
+ </indexterm>
+ <indexterm>
+ <primary>search path</primary>
+ <secondary>current</secondary>
+ </indexterm>
+ <function>current_schemas</function> ( <parameter>include_implicit</parameter> <type>boolean</type> )
+ <returnvalue>name[]</returnvalue>
+ </para>
+ <para>
+ Returns an array of the names of all schemas presently in the
+ effective search path, in their priority order. (Items in the current
+ <xref linkend="guc-search-path"/> setting that do not correspond to
+ existing, searchable schemas are omitted.) If the Boolean argument
+ is <literal>true</literal>, then implicitly-searched system schemas
+ such as <literal>pg_catalog</literal> are included in the result.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_user</primary>
+ </indexterm>
+ <indexterm>
+ <primary>user</primary>
+ <secondary>current</secondary>
+ </indexterm>
+ <function>current_user</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns the user name of the current execution context.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>inet_client_addr</primary>
+ </indexterm>
+ <function>inet_client_addr</function> ()
+ <returnvalue>inet</returnvalue>
+ </para>
+ <para>
+ Returns the IP address of the current client,
+ or <literal>NULL</literal> if the current connection is via a
+ Unix-domain socket.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>inet_client_port</primary>
+ </indexterm>
+ <function>inet_client_port</function> ()
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the IP port number of the current client,
+ or <literal>NULL</literal> if the current connection is via a
+ Unix-domain socket.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>inet_server_addr</primary>
+ </indexterm>
+ <function>inet_server_addr</function> ()
+ <returnvalue>inet</returnvalue>
+ </para>
+ <para>
+ Returns the IP address on which the server accepted the current
+ connection,
+ or <literal>NULL</literal> if the current connection is via a
+ Unix-domain socket.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>inet_server_port</primary>
+ </indexterm>
+ <function>inet_server_port</function> ()
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the IP port number on which the server accepted the current
+ connection,
+ or <literal>NULL</literal> if the current connection is via a
+ Unix-domain socket.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_backend_pid</primary>
+ </indexterm>
+ <function>pg_backend_pid</function> ()
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the process ID of the server process attached to the current
+ session.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_blocking_pids</primary>
+ </indexterm>
+ <function>pg_blocking_pids</function> ( <type>integer</type> )
+ <returnvalue>integer[]</returnvalue>
+ </para>
+ <para>
+ Returns an array of the process ID(s) of the sessions that are
+ blocking the server process with the specified process ID from
+ acquiring a lock, or an empty array if there is no such server process
+ or it is not blocked.
+ </para>
+ <para>
+ One server process blocks another if it either holds a lock that
+ conflicts with the blocked process's lock request (hard block), or is
+ waiting for a lock that would conflict with the blocked process's lock
+ request and is ahead of it in the wait queue (soft block). When using
+ parallel queries the result always lists client-visible process IDs
+ (that is, <function>pg_backend_pid</function> results) even if the
+ actual lock is held or awaited by a child worker process. As a result
+ of that, there may be duplicated PIDs in the result. Also note that
+ when a prepared transaction holds a conflicting lock, it will be
+ represented by a zero process ID.
+ </para>
+ <para>
+ Frequent calls to this function could have some impact on database
+ performance, because it needs exclusive access to the lock manager's
+ shared state for a short time.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_conf_load_time</primary>
+ </indexterm>
+ <function>pg_conf_load_time</function> ()
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Returns the time when the server configuration files were last loaded.
+ If the current session was alive at the time, this will be the time
+ when the session itself re-read the configuration files (so the
+ reading will vary a little in different sessions). Otherwise it is
+ the time when the postmaster process re-read the configuration files.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_logfile</primary>
+ </indexterm>
+ <indexterm>
+ <primary>Logging</primary>
+ <secondary>pg_current_logfile function</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>current_logfiles</primary>
+ <secondary>and the pg_current_logfile function</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>Logging</primary>
+ <secondary>current_logfiles file and the pg_current_logfile
+ function</secondary>
+ </indexterm>
+ <function>pg_current_logfile</function> ( <optional> <type>text</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the path name of the log file currently in use by the logging
+ collector. The path includes the <xref linkend="guc-log-directory"/>
+ directory and the individual log file name. The result
+ is <literal>NULL</literal> if the logging collector is disabled.
+ When multiple log files exist, each in a different
+ format, <function>pg_current_logfile</function> without an argument
+ returns the path of the file having the first format found in the
+ ordered list: <literal>stderr</literal>,
+ <literal>csvlog</literal>, <literal>jsonlog</literal>.
+ <literal>NULL</literal> is returned if no log file has any of these
+ formats.
+ To request information about a specific log file format, supply
+ either <literal>csvlog</literal>, <literal>jsonlog</literal> or
+ <literal>stderr</literal> as the
+ value of the optional parameter. The result is <literal>NULL</literal>
+ if the log format requested is not configured in
+ <xref linkend="guc-log-destination"/>.
+ The result reflects the contents of
+ the <filename>current_logfiles</filename> file.
+ </para>
+ <para>
+ This function is restricted to superusers and roles with privileges of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_my_temp_schema</primary>
+ </indexterm>
+ <function>pg_my_temp_schema</function> ()
+ <returnvalue>oid</returnvalue>
+ </para>
+ <para>
+ Returns the OID of the current session's temporary schema, or zero if
+ it has none (because it has not created any temporary tables).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_is_other_temp_schema</primary>
+ </indexterm>
+ <function>pg_is_other_temp_schema</function> ( <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if the given OID is the OID of another session's
+ temporary schema. (This can be useful, for example, to exclude other
+ sessions' temporary tables from a catalog display.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_jit_available</primary>
+ </indexterm>
+ <function>pg_jit_available</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if a <acronym>JIT</acronym> compiler extension is
+ available (see <xref linkend="jit"/>) and the
+ <xref linkend="guc-jit"/> configuration parameter is set to
+ <literal>on</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_listening_channels</primary>
+ </indexterm>
+ <function>pg_listening_channels</function> ()
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Returns the set of names of asynchronous notification channels that
+ the current session is listening to.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_notification_queue_usage</primary>
+ </indexterm>
+ <function>pg_notification_queue_usage</function> ()
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Returns the fraction (0–1) of the asynchronous notification
+ queue's maximum size that is currently occupied by notifications that
+ are waiting to be processed.
+ See <xref linkend="sql-listen"/> and <xref linkend="sql-notify"/>
+ for more information.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_postmaster_start_time</primary>
+ </indexterm>
+ <function>pg_postmaster_start_time</function> ()
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Returns the time when the server started.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_safe_snapshot_blocking_pids</primary>
+ </indexterm>
+ <function>pg_safe_snapshot_blocking_pids</function> ( <type>integer</type> )
+ <returnvalue>integer[]</returnvalue>
+ </para>
+ <para>
+ Returns an array of the process ID(s) of the sessions that are blocking
+ the server process with the specified process ID from acquiring a safe
+ snapshot, or an empty array if there is no such server process or it
+ is not blocked.
+ </para>
+ <para>
+ A session running a <literal>SERIALIZABLE</literal> transaction blocks
+ a <literal>SERIALIZABLE READ ONLY DEFERRABLE</literal> transaction
+ from acquiring a snapshot until the latter determines that it is safe
+ to avoid taking any predicate locks. See
+ <xref linkend="xact-serializable"/> for more information about
+ serializable and deferrable transactions.
+ </para>
+ <para>
+ Frequent calls to this function could have some impact on database
+ performance, because it needs access to the predicate lock manager's
+ shared state for a short time.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_trigger_depth</primary>
+ </indexterm>
+ <function>pg_trigger_depth</function> ()
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the current nesting level
+ of <productname>PostgreSQL</productname> triggers (0 if not called,
+ directly or indirectly, from inside a trigger).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>session_user</primary>
+ </indexterm>
+ <function>session_user</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns the session user's name.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>system_user</primary>
+ </indexterm>
+ <function>system_user</function>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the authentication method and the identity (if any) that the
+ user presented during the authentication cycle before they were
+ assigned a database role. It is represented as
+ <literal>auth_method:identity</literal> or
+ <literal>NULL</literal> if the user has not been authenticated (for
+ example if <link linkend="auth-trust">Trust authentication</link> has
+ been used).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>user</primary>
+ </indexterm>
+ <function>user</function>
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ This is equivalent to <function>current_user</function>.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ <function>current_catalog</function>,
+ <function>current_role</function>,
+ <function>current_schema</function>,
+ <function>current_user</function>,
+ <function>session_user</function>,
+ and <function>user</function> have special syntactic status
+ in <acronym>SQL</acronym>: they must be called without trailing
+ parentheses. In PostgreSQL, parentheses can optionally be used with
+ <function>current_schema</function>, but not with the others.
+ </para>
+ </note>
+
+ <para>
+ The <function>session_user</function> is normally the user who initiated
+ the current database connection; but superusers can change this setting
+ with <xref linkend="sql-set-session-authorization"/>.
+ The <function>current_user</function> is the user identifier
+ that is applicable for permission checking. Normally it is equal
+ to the session user, but it can be changed with
+ <xref linkend="sql-set-role"/>.
+ It also changes during the execution of
+ functions with the attribute <literal>SECURITY DEFINER</literal>.
+ In Unix parlance, the session user is the <quote>real user</quote> and
+ the current user is the <quote>effective user</quote>.
+ <function>current_role</function> and <function>user</function> are
+ synonyms for <function>current_user</function>. (The SQL standard draws
+ a distinction between <function>current_role</function>
+ and <function>current_user</function>, but <productname>PostgreSQL</productname>
+ does not, since it unifies users and roles into a single kind of entity.)
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-info-access">
+ <title>Access Privilege Inquiry Functions</title>
+
+ <indexterm>
+ <primary>privilege</primary>
+ <secondary>querying</secondary>
+ </indexterm>
+
+ <para>
+ <xref linkend="functions-info-access-table"/> lists functions that
+ allow querying object access privileges programmatically.
+ (See <xref linkend="ddl-priv"/> for more information about
+ privileges.)
+ In these functions, the user whose privileges are being inquired about
+ can be specified by name or by OID
+ (<structname>pg_authid</structname>.<structfield>oid</structfield>), or if
+ the name is given as <literal>public</literal> then the privileges of the
+ PUBLIC pseudo-role are checked. Also, the <parameter>user</parameter>
+ argument can be omitted entirely, in which case
+ the <function>current_user</function> is assumed.
+ The object that is being inquired about can be specified either by name or
+ by OID, too. When specifying by name, a schema name can be included if
+ relevant.
+ The access privilege of interest is specified by a text string, which must
+ evaluate to one of the appropriate privilege keywords for the object's type
+ (e.g., <literal>SELECT</literal>). Optionally, <literal>WITH GRANT
+ OPTION</literal> can be added to a privilege type to test whether the
+ privilege is held with grant option. Also, multiple privilege types can be
+ listed separated by commas, in which case the result will be true if any of
+ the listed privileges is held. (Case of the privilege string is not
+ significant, and extra whitespace is allowed between but not within
+ privilege names.)
+ Some examples:
+<programlisting>
+SELECT has_table_privilege('myschema.mytable', 'select');
+SELECT has_table_privilege('joe', 'mytable', 'INSERT, SELECT WITH GRANT OPTION');
+</programlisting>
+ </para>
+
+ <table id="functions-info-access-table">
+ <title>Access Privilege Inquiry Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_any_column_privilege</primary>
+ </indexterm>
+ <function>has_any_column_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>table</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for any column of table?
+ This succeeds either if the privilege is held for the whole table, or
+ if there is a column-level grant of the privilege for at least one
+ column.
+ Allowable privilege types are
+ <literal>SELECT</literal>, <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, and <literal>REFERENCES</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_column_privilege</primary>
+ </indexterm>
+ <function>has_column_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>table</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>column</parameter> <type>text</type> or <type>smallint</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for the specified table column?
+ This succeeds either if the privilege is held for the whole table, or
+ if there is a column-level grant of the privilege for the column.
+ The column can be specified by name or by attribute number
+ (<structname>pg_attribute</structname>.<structfield>attnum</structfield>).
+ Allowable privilege types are
+ <literal>SELECT</literal>, <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, and <literal>REFERENCES</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_database_privilege</primary>
+ </indexterm>
+ <function>has_database_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>database</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for database?
+ Allowable privilege types are
+ <literal>CREATE</literal>,
+ <literal>CONNECT</literal>,
+ <literal>TEMPORARY</literal>, and
+ <literal>TEMP</literal> (which is equivalent to
+ <literal>TEMPORARY</literal>).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_foreign_data_wrapper_privilege</primary>
+ </indexterm>
+ <function>has_foreign_data_wrapper_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>fdw</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for foreign-data wrapper?
+ The only allowable privilege type is <literal>USAGE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_function_privilege</primary>
+ </indexterm>
+ <function>has_function_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>function</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for function?
+ The only allowable privilege type is <literal>EXECUTE</literal>.
+ </para>
+ <para>
+ When specifying a function by name rather than by OID, the allowed
+ input is the same as for the <type>regprocedure</type> data type (see
+ <xref linkend="datatype-oid"/>).
+ An example is:
+<programlisting>
+SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute');
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_language_privilege</primary>
+ </indexterm>
+ <function>has_language_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>language</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for language?
+ The only allowable privilege type is <literal>USAGE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_parameter_privilege</primary>
+ </indexterm>
+ <function>has_parameter_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>parameter</parameter> <type>text</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for configuration parameter?
+ The parameter name is case-insensitive.
+ Allowable privilege types are <literal>SET</literal>
+ and <literal>ALTER SYSTEM</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_schema_privilege</primary>
+ </indexterm>
+ <function>has_schema_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>schema</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for schema?
+ Allowable privilege types are
+ <literal>CREATE</literal> and
+ <literal>USAGE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_sequence_privilege</primary>
+ </indexterm>
+ <function>has_sequence_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>sequence</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for sequence?
+ Allowable privilege types are
+ <literal>USAGE</literal>,
+ <literal>SELECT</literal>, and
+ <literal>UPDATE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_server_privilege</primary>
+ </indexterm>
+ <function>has_server_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>server</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for foreign server?
+ The only allowable privilege type is <literal>USAGE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_table_privilege</primary>
+ </indexterm>
+ <function>has_table_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>table</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for table?
+ Allowable privilege types
+ are <literal>SELECT</literal>, <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, <literal>DELETE</literal>,
+ <literal>TRUNCATE</literal>, <literal>REFERENCES</literal>,
+ <literal>TRIGGER</literal>, and <literal>MAINTAIN</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_tablespace_privilege</primary>
+ </indexterm>
+ <function>has_tablespace_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>tablespace</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for tablespace?
+ The only allowable privilege type is <literal>CREATE</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>has_type_privilege</primary>
+ </indexterm>
+ <function>has_type_privilege</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>type</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for data type?
+ The only allowable privilege type is <literal>USAGE</literal>.
+ When specifying a type by name rather than by OID, the allowed input
+ is the same as for the <type>regtype</type> data type (see
+ <xref linkend="datatype-oid"/>).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_has_role</primary>
+ </indexterm>
+ <function>pg_has_role</function> (
+ <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
+ <parameter>role</parameter> <type>text</type> or <type>oid</type>,
+ <parameter>privilege</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does user have privilege for role?
+ Allowable privilege types are
+ <literal>MEMBER</literal>, <literal>USAGE</literal>,
+ and <literal>SET</literal>.
+ <literal>MEMBER</literal> denotes direct or indirect membership in
+ the role without regard to what specific privileges may be conferred.
+ <literal>USAGE</literal> denotes whether the privileges of the role
+ are immediately available without doing <command>SET ROLE</command>,
+ while <literal>SET</literal> denotes whether it is possible to change
+ to the role using the <literal>SET ROLE</literal> command.
+ This function does not allow the special case of
+ setting <parameter>user</parameter> to <literal>public</literal>,
+ because the PUBLIC pseudo-role can never be a member of real roles.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>row_security_active</primary>
+ </indexterm>
+ <function>row_security_active</function> (
+ <parameter>table</parameter> <type>text</type> or <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is row-level security active for the specified table in the context of
+ the current user and current environment?
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-aclitem-op-table"/> shows the operators
+ available for the <type>aclitem</type> type, which is the catalog
+ representation of access privileges. See <xref linkend="ddl-priv"/>
+ for information about how to read access privilege values.
+ </para>
+
+ <table id="functions-aclitem-op-table">
+ <title><type>aclitem</type> Operators</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>aclitemeq</primary>
+ </indexterm>
+ <type>aclitem</type> <literal>=</literal> <type>aclitem</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Are <type>aclitem</type>s equal? (Notice that
+ type <type>aclitem</type> lacks the usual set of comparison
+ operators; it has only equality. In turn, <type>aclitem</type>
+ arrays can only be compared for equality.)
+ </para>
+ <para>
+ <literal>'calvin=r*w/hobbes'::aclitem = 'calvin=r*w*/hobbes'::aclitem</literal>
+ <returnvalue>f</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>aclcontains</primary>
+ </indexterm>
+ <type>aclitem[]</type> <literal>@></literal> <type>aclitem</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does array contain the specified privileges? (This is true if there
+ is an array entry that matches the <type>aclitem</type>'s grantee and
+ grantor, and has at least the specified set of privileges.)
+ </para>
+ <para>
+ <literal>'{calvin=r*w/hobbes,hobbes=r*w*/postgres}'::aclitem[] @> 'calvin=r*/hobbes'::aclitem</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>aclitem[]</type> <literal>~</literal> <type>aclitem</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ This is a deprecated alias for <literal>@></literal>.
+ </para>
+ <para>
+ <literal>'{calvin=r*w/hobbes,hobbes=r*w*/postgres}'::aclitem[] ~ 'calvin=r*/hobbes'::aclitem</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-aclitem-fn-table"/> shows some additional
+ functions to manage the <type>aclitem</type> type.
+ </para>
+
+ <table id="functions-aclitem-fn-table">
+ <title><type>aclitem</type> Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>acldefault</primary>
+ </indexterm>
+ <function>acldefault</function> (
+ <parameter>type</parameter> <type>"char"</type>,
+ <parameter>ownerId</parameter> <type>oid</type> )
+ <returnvalue>aclitem[]</returnvalue>
+ </para>
+ <para>
+ Constructs an <type>aclitem</type> array holding the default access
+ privileges for an object of type <parameter>type</parameter> belonging
+ to the role with OID <parameter>ownerId</parameter>. This represents
+ the access privileges that will be assumed when an object's ACL entry
+ is null. (The default access privileges are described in
+ <xref linkend="ddl-priv"/>.)
+ The <parameter>type</parameter> parameter must be one of
+ 'c' for <literal>COLUMN</literal>,
+ 'r' for <literal>TABLE</literal> and table-like objects,
+ 's' for <literal>SEQUENCE</literal>,
+ 'd' for <literal>DATABASE</literal>,
+ 'f' for <literal>FUNCTION</literal> or <literal>PROCEDURE</literal>,
+ 'l' for <literal>LANGUAGE</literal>,
+ 'L' for <literal>LARGE OBJECT</literal>,
+ 'n' for <literal>SCHEMA</literal>,
+ 'p' for <literal>PARAMETER</literal>,
+ 't' for <literal>TABLESPACE</literal>,
+ 'F' for <literal>FOREIGN DATA WRAPPER</literal>,
+ 'S' for <literal>FOREIGN SERVER</literal>,
+ or
+ 'T' for <literal>TYPE</literal> or <literal>DOMAIN</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>aclexplode</primary>
+ </indexterm>
+ <function>aclexplode</function> ( <type>aclitem[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>grantor</parameter> <type>oid</type>,
+ <parameter>grantee</parameter> <type>oid</type>,
+ <parameter>privilege_type</parameter> <type>text</type>,
+ <parameter>is_grantable</parameter> <type>boolean</type> )
+ </para>
+ <para>
+ Returns the <type>aclitem</type> array as a set of rows.
+ If the grantee is the pseudo-role PUBLIC, it is represented by zero in
+ the <parameter>grantee</parameter> column. Each granted privilege is
+ represented as <literal>SELECT</literal>, <literal>INSERT</literal>,
+ etc (see <xref linkend="privilege-abbrevs-table"/> for a full list).
+ Note that each privilege is broken out as a separate row, so
+ only one keyword appears in the <parameter>privilege_type</parameter>
+ column.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>makeaclitem</primary>
+ </indexterm>
+ <function>makeaclitem</function> (
+ <parameter>grantee</parameter> <type>oid</type>,
+ <parameter>grantor</parameter> <type>oid</type>,
+ <parameter>privileges</parameter> <type>text</type>,
+ <parameter>is_grantable</parameter> <type>boolean</type> )
+ <returnvalue>aclitem</returnvalue>
+ </para>
+ <para>
+ Constructs an <type>aclitem</type> with the given properties.
+ <parameter>privileges</parameter> is a comma-separated list of
+ privilege names such as <literal>SELECT</literal>,
+ <literal>INSERT</literal>, etc, all of which are set in the
+ result. (Case of the privilege string is not significant, and
+ extra whitespace is allowed between but not within privilege
+ names.)
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-schema">
+ <title>Schema Visibility Inquiry Functions</title>
+
+ <para>
+ <xref linkend="functions-info-schema-table"/> shows functions that
+ determine whether a certain object is <firstterm>visible</firstterm> in the
+ current schema search path.
+ For example, a table is said to be visible if its
+ containing schema is in the search path and no table of the same
+ name appears earlier in the search path. This is equivalent to the
+ statement that the table can be referenced by name without explicit
+ schema qualification. Thus, to list the names of all visible tables:
+<programlisting>
+SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
+</programlisting>
+ For functions and operators, an object in the search path is said to be
+ visible if there is no object of the same name <emphasis>and argument data
+ type(s)</emphasis> earlier in the path. For operator classes and families,
+ both the name and the associated index access method are considered.
+ </para>
+
+ <indexterm>
+ <primary>search path</primary>
+ <secondary>object visibility</secondary>
+ </indexterm>
+
+ <table id="functions-info-schema-table">
+ <title>Schema Visibility Inquiry Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_collation_is_visible</primary>
+ </indexterm>
+ <function>pg_collation_is_visible</function> ( <parameter>collation</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is collation visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_conversion_is_visible</primary>
+ </indexterm>
+ <function>pg_conversion_is_visible</function> ( <parameter>conversion</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is conversion visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_function_is_visible</primary>
+ </indexterm>
+ <function>pg_function_is_visible</function> ( <parameter>function</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is function visible in search path?
+ (This also works for procedures and aggregates.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_opclass_is_visible</primary>
+ </indexterm>
+ <function>pg_opclass_is_visible</function> ( <parameter>opclass</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is operator class visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_operator_is_visible</primary>
+ </indexterm>
+ <function>pg_operator_is_visible</function> ( <parameter>operator</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is operator visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_opfamily_is_visible</primary>
+ </indexterm>
+ <function>pg_opfamily_is_visible</function> ( <parameter>opclass</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is operator family visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_statistics_obj_is_visible</primary>
+ </indexterm>
+ <function>pg_statistics_obj_is_visible</function> ( <parameter>stat</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is statistics object visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_table_is_visible</primary>
+ </indexterm>
+ <function>pg_table_is_visible</function> ( <parameter>table</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is table visible in search path?
+ (This works for all types of relations, including views, materialized
+ views, indexes, sequences and foreign tables.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ts_config_is_visible</primary>
+ </indexterm>
+ <function>pg_ts_config_is_visible</function> ( <parameter>config</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is text search configuration visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ts_dict_is_visible</primary>
+ </indexterm>
+ <function>pg_ts_dict_is_visible</function> ( <parameter>dict</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is text search dictionary visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ts_parser_is_visible</primary>
+ </indexterm>
+ <function>pg_ts_parser_is_visible</function> ( <parameter>parser</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is text search parser visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ts_template_is_visible</primary>
+ </indexterm>
+ <function>pg_ts_template_is_visible</function> ( <parameter>template</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is text search template visible in search path?
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_type_is_visible</primary>
+ </indexterm>
+ <function>pg_type_is_visible</function> ( <parameter>type</parameter> <type>oid</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is type (or domain) visible in search path?
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ All these functions require object OIDs to identify the object to be
+ checked. If you want to test an object by name, it is convenient to use
+ the OID alias types (<type>regclass</type>, <type>regtype</type>,
+ <type>regprocedure</type>, <type>regoperator</type>, <type>regconfig</type>,
+ or <type>regdictionary</type>),
+ for example:
+<programlisting>
+SELECT pg_type_is_visible('myschema.widget'::regtype);
+</programlisting>
+ Note that it would not make much sense to test a non-schema-qualified
+ type name in this way — if the name can be recognized at all, it must be visible.
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-info-catalog">
+ <title>System Catalog Information Functions</title>
+
+ <para>
+ <xref linkend="functions-info-catalog-table"/> lists functions that
+ extract information from the system catalogs.
+ </para>
+
+ <table id="functions-info-catalog-table">
+ <title>System Catalog Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry id="format-type" xreflabel="format_type" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>format_type</primary>
+ </indexterm>
+ <function>format_type</function> ( <parameter>type</parameter> <type>oid</type>, <parameter>typemod</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the SQL name for a data type that is identified by its type
+ OID and possibly a type modifier. Pass NULL for the type modifier if
+ no specific modifier is known.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_basetype</primary>
+ </indexterm>
+ <function>pg_basetype</function> ( <type>regtype</type> )
+ <returnvalue>regtype</returnvalue>
+ </para>
+ <para>
+ Returns the OID of the base type of a domain identified by its
+ type OID. If the argument is the OID of a non-domain type,
+ returns the argument as-is. Returns NULL if the argument is
+ not a valid type OID. If there's a chain of domain dependencies,
+ it will recurse until finding the base type.
+ </para>
+ <para>
+ Assuming <literal>CREATE DOMAIN mytext AS text</literal>:
+ </para>
+ <para>
+ <literal>pg_basetype('mytext'::regtype)</literal>
+ <returnvalue>text</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-char-to-encoding" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_char_to_encoding</primary>
+ </indexterm>
+ <function>pg_char_to_encoding</function> ( <parameter>encoding</parameter> <type>name</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Converts the supplied encoding name into an integer representing the
+ internal identifier used in some system catalog tables.
+ Returns <literal>-1</literal> if an unknown encoding name is provided.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-encoding-to-char" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_encoding_to_char</primary>
+ </indexterm>
+ <function>pg_encoding_to_char</function> ( <parameter>encoding</parameter> <type>integer</type> )
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Converts the integer used as the internal identifier of an encoding in some
+ system catalog tables into a human-readable string.
+ Returns an empty string if an invalid encoding number is provided.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_catalog_foreign_keys</primary>
+ </indexterm>
+ <function>pg_get_catalog_foreign_keys</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>fktable</parameter> <type>regclass</type>,
+ <parameter>fkcols</parameter> <type>text[]</type>,
+ <parameter>pktable</parameter> <type>regclass</type>,
+ <parameter>pkcols</parameter> <type>text[]</type>,
+ <parameter>is_array</parameter> <type>boolean</type>,
+ <parameter>is_opt</parameter> <type>boolean</type> )
+ </para>
+ <para>
+ Returns a set of records describing the foreign key relationships
+ that exist within the <productname>PostgreSQL</productname> system
+ catalogs.
+ The <parameter>fktable</parameter> column contains the name of the
+ referencing catalog, and the <parameter>fkcols</parameter> column
+ contains the name(s) of the referencing column(s). Similarly,
+ the <parameter>pktable</parameter> column contains the name of the
+ referenced catalog, and the <parameter>pkcols</parameter> column
+ contains the name(s) of the referenced column(s).
+ If <parameter>is_array</parameter> is true, the last referencing
+ column is an array, each of whose elements should match some entry
+ in the referenced catalog.
+ If <parameter>is_opt</parameter> is true, the referencing column(s)
+ are allowed to contain zeroes instead of a valid reference.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_constraintdef</primary>
+ </indexterm>
+ <function>pg_get_constraintdef</function> ( <parameter>constraint</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for a constraint.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_expr</primary>
+ </indexterm>
+ <function>pg_get_expr</function> ( <parameter>expr</parameter> <type>pg_node_tree</type>, <parameter>relation</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Decompiles the internal form of an expression stored in the system
+ catalogs, such as the default value for a column. If the expression
+ might contain Vars, specify the OID of the relation they refer to as
+ the second parameter; if no Vars are expected, passing zero is
+ sufficient.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_functiondef</primary>
+ </indexterm>
+ <function>pg_get_functiondef</function> ( <parameter>func</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for a function or procedure.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ The result is a complete <command>CREATE OR REPLACE FUNCTION</command>
+ or <command>CREATE OR REPLACE PROCEDURE</command> statement.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_function_arguments</primary>
+ </indexterm>
+ <function>pg_get_function_arguments</function> ( <parameter>func</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the argument list of a function or procedure, in the form
+ it would need to appear in within <command>CREATE FUNCTION</command>
+ (including default values).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_function_identity_arguments</primary>
+ </indexterm>
+ <function>pg_get_function_identity_arguments</function> ( <parameter>func</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the argument list necessary to identify a function or
+ procedure, in the form it would need to appear in within commands such
+ as <command>ALTER FUNCTION</command>. This form omits default values.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_function_result</primary>
+ </indexterm>
+ <function>pg_get_function_result</function> ( <parameter>func</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the <literal>RETURNS</literal> clause of a function, in
+ the form it would need to appear in within <command>CREATE
+ FUNCTION</command>. Returns <literal>NULL</literal> for a procedure.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_indexdef</primary>
+ </indexterm>
+ <function>pg_get_indexdef</function> ( <parameter>index</parameter> <type>oid</type> <optional>, <parameter>column</parameter> <type>integer</type>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for an index.
+ (This is a decompiled reconstruction, not the original text
+ of the command.) If <parameter>column</parameter> is supplied and is
+ not zero, only the definition of that column is reconstructed.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_keywords</primary>
+ </indexterm>
+ <function>pg_get_keywords</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>word</parameter> <type>text</type>,
+ <parameter>catcode</parameter> <type>"char"</type>,
+ <parameter>barelabel</parameter> <type>boolean</type>,
+ <parameter>catdesc</parameter> <type>text</type>,
+ <parameter>baredesc</parameter> <type>text</type> )
+ </para>
+ <para>
+ Returns a set of records describing the SQL keywords recognized by the
+ server. The <parameter>word</parameter> column contains the
+ keyword. The <parameter>catcode</parameter> column contains a
+ category code: <literal>U</literal> for an unreserved
+ keyword, <literal>C</literal> for a keyword that can be a column
+ name, <literal>T</literal> for a keyword that can be a type or
+ function name, or <literal>R</literal> for a fully reserved keyword.
+ The <parameter>barelabel</parameter> column
+ contains <literal>true</literal> if the keyword can be used as
+ a <quote>bare</quote> column label in <command>SELECT</command> lists,
+ or <literal>false</literal> if it can only be used
+ after <literal>AS</literal>.
+ The <parameter>catdesc</parameter> column contains a
+ possibly-localized string describing the keyword's category.
+ The <parameter>baredesc</parameter> column contains a
+ possibly-localized string describing the keyword's column label status.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_partkeydef</primary>
+ </indexterm>
+ <function>pg_get_partkeydef</function> ( <parameter>table</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the definition of a partitioned table's partition
+ key, in the form it would have in the <literal>PARTITION
+ BY</literal> clause of <command>CREATE TABLE</command>.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_ruledef</primary>
+ </indexterm>
+ <function>pg_get_ruledef</function> ( <parameter>rule</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for a rule.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_serial_sequence</primary>
+ </indexterm>
+ <function>pg_get_serial_sequence</function> ( <parameter>table</parameter> <type>text</type>, <parameter>column</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the name of the sequence associated with a column,
+ or NULL if no sequence is associated with the column.
+ If the column is an identity column, the associated sequence is the
+ sequence internally created for that column.
+ For columns created using one of the serial types
+ (<type>serial</type>, <type>smallserial</type>, <type>bigserial</type>),
+ it is the sequence created for that serial column definition.
+ In the latter case, the association can be modified or removed
+ with <command>ALTER SEQUENCE OWNED BY</command>.
+ (This function probably should have been
+ called <function>pg_get_owned_sequence</function>; its current name
+ reflects the fact that it has historically been used with serial-type
+ columns.) The first parameter is a table name with optional
+ schema, and the second parameter is a column name. Because the first
+ parameter potentially contains both schema and table names, it is
+ parsed per usual SQL rules, meaning it is lower-cased by default.
+ The second parameter, being just a column name, is treated literally
+ and so has its case preserved. The result is suitably formatted
+ for passing to the sequence functions (see
+ <xref linkend="functions-sequence"/>).
+ </para>
+ <para>
+ A typical use is in reading the current value of the sequence for an
+ identity or serial column, for example:
+<programlisting>
+SELECT currval(pg_get_serial_sequence('sometable', 'id'));
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_statisticsobjdef</primary>
+ </indexterm>
+ <function>pg_get_statisticsobjdef</function> ( <parameter>statobj</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for an extended statistics object.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_triggerdef</primary>
+ </indexterm>
+<function>pg_get_triggerdef</function> ( <parameter>trigger</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the creating command for a trigger.
+ (This is a decompiled reconstruction, not the original text
+ of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_userbyid</primary>
+ </indexterm>
+ <function>pg_get_userbyid</function> ( <parameter>role</parameter> <type>oid</type> )
+ <returnvalue>name</returnvalue>
+ </para>
+ <para>
+ Returns a role's name given its OID.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_viewdef</primary>
+ </indexterm>
+ <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the underlying <command>SELECT</command> command for a
+ view or materialized view. (This is a decompiled reconstruction, not
+ the original text of the command.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>oid</type>, <parameter>wrap_column</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the underlying <command>SELECT</command> command for a
+ view or materialized view. (This is a decompiled reconstruction, not
+ the original text of the command.) In this form of the function,
+ pretty-printing is always enabled, and long lines are wrapped to try
+ to keep them shorter than the specified number of columns.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>text</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reconstructs the underlying <command>SELECT</command> command for a
+ view or materialized view, working from a textual name for the view
+ rather than its OID. (This is deprecated; use the OID variant
+ instead.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_index_column_has_property</primary>
+ </indexterm>
+ <function>pg_index_column_has_property</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>column</parameter> <type>integer</type>, <parameter>property</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether an index column has the named property.
+ Common index column properties are listed in
+ <xref linkend="functions-info-index-column-props"/>.
+ (Note that extension access methods can define additional property
+ names for their indexes.)
+ <literal>NULL</literal> is returned if the property name is not known
+ or does not apply to the particular object, or if the OID or column
+ number does not identify a valid object.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_index_has_property</primary>
+ </indexterm>
+ <function>pg_index_has_property</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>property</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether an index has the named property.
+ Common index properties are listed in
+ <xref linkend="functions-info-index-props"/>.
+ (Note that extension access methods can define additional property
+ names for their indexes.)
+ <literal>NULL</literal> is returned if the property name is not known
+ or does not apply to the particular object, or if the OID does not
+ identify a valid object.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_indexam_has_property</primary>
+ </indexterm>
+ <function>pg_indexam_has_property</function> ( <parameter>am</parameter> <type>oid</type>, <parameter>property</parameter> <type>text</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether an index access method has the named property.
+ Access method properties are listed in
+ <xref linkend="functions-info-indexam-props"/>.
+ <literal>NULL</literal> is returned if the property name is not known
+ or does not apply to the particular object, or if the OID does not
+ identify a valid object.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_options_to_table</primary>
+ </indexterm>
+ <function>pg_options_to_table</function> ( <parameter>options_array</parameter> <type>text[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>option_name</parameter> <type>text</type>,
+ <parameter>option_value</parameter> <type>text</type> )
+ </para>
+ <para>
+ Returns the set of storage options represented by a value from
+ <structname>pg_class</structname>.<structfield>reloptions</structfield> or
+ <structname>pg_attribute</structname>.<structfield>attoptions</structfield>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_settings_get_flags</primary>
+ </indexterm>
+ <function>pg_settings_get_flags</function> ( <parameter>guc</parameter> <type>text</type> )
+ <returnvalue>text[]</returnvalue>
+ </para>
+ <para>
+ Returns an array of the flags associated with the given GUC, or
+ <literal>NULL</literal> if it does not exist. The result is
+ an empty array if the GUC exists but there are no flags to show.
+ Only the most useful flags listed in
+ <xref linkend="functions-pg-settings-flags"/> are exposed.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_tablespace_databases</primary>
+ </indexterm>
+ <function>pg_tablespace_databases</function> ( <parameter>tablespace</parameter> <type>oid</type> )
+ <returnvalue>setof oid</returnvalue>
+ </para>
+ <para>
+ Returns the set of OIDs of databases that have objects stored in the
+ specified tablespace. If this function returns any rows, the
+ tablespace is not empty and cannot be dropped. To identify the specific
+ objects populating the tablespace, you will need to connect to the
+ database(s) identified by <function>pg_tablespace_databases</function>
+ and query their <structname>pg_class</structname> catalogs.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_tablespace_location</primary>
+ </indexterm>
+ <function>pg_tablespace_location</function> ( <parameter>tablespace</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the file system path that this tablespace is located in.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_typeof</primary>
+ </indexterm>
+ <function>pg_typeof</function> ( <type>"any"</type> )
+ <returnvalue>regtype</returnvalue>
+ </para>
+ <para>
+ Returns the OID of the data type of the value that is passed to it.
+ This can be helpful for troubleshooting or dynamically constructing
+ SQL queries. The function is declared as
+ returning <type>regtype</type>, which is an OID alias type (see
+ <xref linkend="datatype-oid"/>); this means that it is the same as an
+ OID for comparison purposes but displays as a type name.
+ </para>
+ <para>
+ <literal>pg_typeof(33)</literal>
+ <returnvalue>integer</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>COLLATION FOR</primary>
+ </indexterm>
+ <function>COLLATION FOR</function> ( <type>"any"</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the name of the collation of the value that is passed to it.
+ The value is quoted and schema-qualified if necessary. If no
+ collation was derived for the argument expression,
+ then <literal>NULL</literal> is returned. If the argument is not of a
+ collatable data type, then an error is raised.
+ </para>
+ <para>
+ <literal>collation for ('foo'::text)</literal>
+ <returnvalue>"default"</returnvalue>
+ </para>
+ <para>
+ <literal>collation for ('foo' COLLATE "de_DE")</literal>
+ <returnvalue>"de_DE"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regclass</primary>
+ </indexterm>
+ <function>to_regclass</function> ( <type>text</type> )
+ <returnvalue>regclass</returnvalue>
+ </para>
+ <para>
+ Translates a textual relation name to its OID. A similar result is
+ obtained by casting the string to type <type>regclass</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regcollation</primary>
+ </indexterm>
+ <function>to_regcollation</function> ( <type>text</type> )
+ <returnvalue>regcollation</returnvalue>
+ </para>
+ <para>
+ Translates a textual collation name to its OID. A similar result is
+ obtained by casting the string to type <type>regcollation</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regnamespace</primary>
+ </indexterm>
+ <function>to_regnamespace</function> ( <type>text</type> )
+ <returnvalue>regnamespace</returnvalue>
+ </para>
+ <para>
+ Translates a textual schema name to its OID. A similar result is
+ obtained by casting the string to type <type>regnamespace</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regoper</primary>
+ </indexterm>
+ <function>to_regoper</function> ( <type>text</type> )
+ <returnvalue>regoper</returnvalue>
+ </para>
+ <para>
+ Translates a textual operator name to its OID. A similar result is
+ obtained by casting the string to type <type>regoper</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found or is ambiguous.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regoperator</primary>
+ </indexterm>
+ <function>to_regoperator</function> ( <type>text</type> )
+ <returnvalue>regoperator</returnvalue>
+ </para>
+ <para>
+ Translates a textual operator name (with parameter types) to its OID. A similar result is
+ obtained by casting the string to type <type>regoperator</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regproc</primary>
+ </indexterm>
+ <function>to_regproc</function> ( <type>text</type> )
+ <returnvalue>regproc</returnvalue>
+ </para>
+ <para>
+ Translates a textual function or procedure name to its OID. A similar result is
+ obtained by casting the string to type <type>regproc</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found or is ambiguous.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regprocedure</primary>
+ </indexterm>
+ <function>to_regprocedure</function> ( <type>text</type> )
+ <returnvalue>regprocedure</returnvalue>
+ </para>
+ <para>
+ Translates a textual function or procedure name (with argument types) to its OID. A similar result is
+ obtained by casting the string to type <type>regprocedure</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regrole</primary>
+ </indexterm>
+ <function>to_regrole</function> ( <type>text</type> )
+ <returnvalue>regrole</returnvalue>
+ </para>
+ <para>
+ Translates a textual role name to its OID. A similar result is
+ obtained by casting the string to type <type>regrole</type> (see
+ <xref linkend="datatype-oid"/>); however, this function will return
+ <literal>NULL</literal> rather than throwing an error if the name is
+ not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="to-regtype" xreflabel="to_regtype" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regtype</primary>
+ </indexterm>
+ <function>to_regtype</function> ( <type>text</type> )
+ <returnvalue>regtype</returnvalue>
+ </para>
+ <para>
+ Parses a string of text, extracts a potential type name from it,
+ and translates that name into a type OID. A syntax error in the
+ string will result in an error; but if the string is a
+ syntactically valid type name that happens not to be found in the
+ catalogs, the result is <literal>NULL</literal>. A similar result
+ is obtained by casting the string to type <type>regtype</type>
+ (see <xref linkend="datatype-oid"/>), except that that will throw
+ error for name not found.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_regtypemod</primary>
+ </indexterm>
+ <function>to_regtypemod</function> ( <type>text</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Parses a string of text, extracts a potential type name from it,
+ and translates its type modifier, if any. A syntax error in the
+ string will result in an error; but if the string is a
+ syntactically valid type name that happens not to be found in the
+ catalogs, the result is <literal>NULL</literal>. The result is
+ <literal>-1</literal> if no type modifier is present.
+ </para>
+ <para>
+ <function>to_regtypemod</function> can be combined with
+ <xref linkend="to-regtype"/> to produce appropriate inputs for
+ <xref linkend="format-type"/>, allowing a string representing a
+ type name to be canonicalized.
+ </para>
+ <para>
+ <literal>format_type(to_regtype('varchar(32)'), to_regtypemod('varchar(32)'))</literal>
+ <returnvalue>character varying(32)</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Most of the functions that reconstruct (decompile) database objects
+ have an optional <parameter>pretty</parameter> flag, which
+ if <literal>true</literal> causes the result to
+ be <quote>pretty-printed</quote>. Pretty-printing suppresses unnecessary
+ parentheses and adds whitespace for legibility.
+ The pretty-printed format is more readable, but the default format
+ is more likely to be interpreted the same way by future versions of
+ <productname>PostgreSQL</productname>; so avoid using pretty-printed output
+ for dump purposes. Passing <literal>false</literal> for
+ the <parameter>pretty</parameter> parameter yields the same result as
+ omitting the parameter.
+ </para>
+
+ <table id="functions-info-index-column-props">
+ <title>Index Column Properties</title>
+ <tgroup cols="2">
+ <thead>
+ <row><entry>Name</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>asc</literal></entry>
+ <entry>Does the column sort in ascending order on a forward scan?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>desc</literal></entry>
+ <entry>Does the column sort in descending order on a forward scan?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>nulls_first</literal></entry>
+ <entry>Does the column sort with nulls first on a forward scan?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>nulls_last</literal></entry>
+ <entry>Does the column sort with nulls last on a forward scan?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>orderable</literal></entry>
+ <entry>Does the column possess any defined sort ordering?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>distance_orderable</literal></entry>
+ <entry>Can the column be scanned in order by a <quote>distance</quote>
+ operator, for example <literal>ORDER BY col <-> constant</literal> ?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>returnable</literal></entry>
+ <entry>Can the column value be returned by an index-only scan?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>search_array</literal></entry>
+ <entry>Does the column natively support <literal>col = ANY(array)</literal>
+ searches?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>search_nulls</literal></entry>
+ <entry>Does the column support <literal>IS NULL</literal> and
+ <literal>IS NOT NULL</literal> searches?
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-info-index-props">
+ <title>Index Properties</title>
+ <tgroup cols="2">
+ <thead>
+ <row><entry>Name</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>clusterable</literal></entry>
+ <entry>Can the index be used in a <literal>CLUSTER</literal> command?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>index_scan</literal></entry>
+ <entry>Does the index support plain (non-bitmap) scans?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>bitmap_scan</literal></entry>
+ <entry>Does the index support bitmap scans?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>backward_scan</literal></entry>
+ <entry>Can the scan direction be changed in mid-scan (to
+ support <literal>FETCH BACKWARD</literal> on a cursor without
+ needing materialization)?
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-info-indexam-props">
+ <title>Index Access Method Properties</title>
+ <tgroup cols="2">
+ <thead>
+ <row><entry>Name</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>can_order</literal></entry>
+ <entry>Does the access method support <literal>ASC</literal>,
+ <literal>DESC</literal> and related keywords in
+ <literal>CREATE INDEX</literal>?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>can_unique</literal></entry>
+ <entry>Does the access method support unique indexes?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>can_multi_col</literal></entry>
+ <entry>Does the access method support indexes with multiple columns?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>can_exclude</literal></entry>
+ <entry>Does the access method support exclusion constraints?
+ </entry>
+ </row>
+ <row>
+ <entry><literal>can_include</literal></entry>
+ <entry>Does the access method support the <literal>INCLUDE</literal>
+ clause of <literal>CREATE INDEX</literal>?
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-pg-settings-flags">
+ <title>GUC Flags</title>
+ <tgroup cols="2">
+ <thead>
+ <row><entry>Flag</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>EXPLAIN</literal></entry>
+ <entry>Parameters with this flag are included in
+ <command>EXPLAIN (SETTINGS)</command> commands.
+ </entry>
+ </row>
+ <row>
+ <entry><literal>NO_SHOW_ALL</literal></entry>
+ <entry>Parameters with this flag are excluded from
+ <command>SHOW ALL</command> commands.
+ </entry>
+ </row>
+ <row>
+ <entry><literal>NO_RESET</literal></entry>
+ <entry>Parameters with this flag do not support
+ <command>RESET</command> commands.
+ </entry>
+ </row>
+ <row>
+ <entry><literal>NO_RESET_ALL</literal></entry>
+ <entry>Parameters with this flag are excluded from
+ <command>RESET ALL</command> commands.
+ </entry>
+ </row>
+ <row>
+ <entry><literal>NOT_IN_SAMPLE</literal></entry>
+ <entry>Parameters with this flag are not included in
+ <filename>postgresql.conf</filename> by default.
+ </entry>
+ </row>
+ <row>
+ <entry><literal>RUNTIME_COMPUTED</literal></entry>
+ <entry>Parameters with this flag are runtime-computed ones.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-object">
+ <title>Object Information and Addressing Functions</title>
+
+ <para>
+ <xref linkend="functions-info-object-table"/> lists functions related to
+ database object identification and addressing.
+ </para>
+
+ <table id="functions-info-object-table">
+ <title>Object Information and Addressing Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_describe_object</primary>
+ </indexterm>
+ <function>pg_describe_object</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns a textual description of a database object identified by
+ catalog OID, object OID, and sub-object ID (such as a column number
+ within a table; the sub-object ID is zero when referring to a whole
+ object). This description is intended to be human-readable, and might
+ be translated, depending on server configuration. This is especially
+ useful to determine the identity of an object referenced in the
+ <structname>pg_depend</structname> catalog. This function returns
+ <literal>NULL</literal> values for undefined objects.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_identify_object</primary>
+ </indexterm>
+ <function>pg_identify_object</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>type</parameter> <type>text</type>,
+ <parameter>schema</parameter> <type>text</type>,
+ <parameter>name</parameter> <type>text</type>,
+ <parameter>identity</parameter> <type>text</type> )
+ </para>
+ <para>
+ Returns a row containing enough information to uniquely identify the
+ database object specified by catalog OID, object OID and sub-object
+ ID.
+ This information is intended to be machine-readable, and is never
+ translated.
+ <parameter>type</parameter> identifies the type of database object;
+ <parameter>schema</parameter> is the schema name that the object
+ belongs in, or <literal>NULL</literal> for object types that do not
+ belong to schemas;
+ <parameter>name</parameter> is the name of the object, quoted if
+ necessary, if the name (along with schema name, if pertinent) is
+ sufficient to uniquely identify the object,
+ otherwise <literal>NULL</literal>;
+ <parameter>identity</parameter> is the complete object identity, with
+ the precise format depending on object type, and each name within the
+ format being schema-qualified and quoted as necessary. Undefined
+ objects are identified with <literal>NULL</literal> values.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_identify_object_as_address</primary>
+ </indexterm>
+ <function>pg_identify_object_as_address</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>type</parameter> <type>text</type>,
+ <parameter>object_names</parameter> <type>text[]</type>,
+ <parameter>object_args</parameter> <type>text[]</type> )
+ </para>
+ <para>
+ Returns a row containing enough information to uniquely identify the
+ database object specified by catalog OID, object OID and sub-object
+ ID.
+ The returned information is independent of the current server, that
+ is, it could be used to identify an identically named object in
+ another server.
+ <parameter>type</parameter> identifies the type of database object;
+ <parameter>object_names</parameter> and
+ <parameter>object_args</parameter>
+ are text arrays that together form a reference to the object.
+ These three values can be passed
+ to <function>pg_get_object_address</function> to obtain the internal
+ address of the object.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_object_address</primary>
+ </indexterm>
+ <function>pg_get_object_address</function> ( <parameter>type</parameter> <type>text</type>, <parameter>object_names</parameter> <type>text[]</type>, <parameter>object_args</parameter> <type>text[]</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>classid</parameter> <type>oid</type>,
+ <parameter>objid</parameter> <type>oid</type>,
+ <parameter>objsubid</parameter> <type>integer</type> )
+ </para>
+ <para>
+ Returns a row containing enough information to uniquely identify the
+ database object specified by a type code and object name and argument
+ arrays.
+ The returned values are the ones that would be used in system catalogs
+ such as <structname>pg_depend</structname>; they can be passed to
+ other system functions such as <function>pg_describe_object</function>
+ or <function>pg_identify_object</function>.
+ <parameter>classid</parameter> is the OID of the system catalog
+ containing the object;
+ <parameter>objid</parameter> is the OID of the object itself, and
+ <parameter>objsubid</parameter> is the sub-object ID, or zero if none.
+ This function is the inverse
+ of <function>pg_identify_object_as_address</function>.
+ Undefined objects are identified with <literal>NULL</literal> values.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-comment">
+ <title>Comment Information Functions</title>
+
+ <indexterm>
+ <primary>comment</primary>
+ <secondary sortas="database objects">about database objects</secondary>
+ </indexterm>
+
+ <para>
+ The functions shown in <xref linkend="functions-info-comment-table"/>
+ extract comments previously stored with the <xref linkend="sql-comment"/>
+ command. A null value is returned if no
+ comment could be found for the specified parameters.
+ </para>
+
+ <table id="functions-info-comment-table">
+ <title>Comment Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>col_description</primary>
+ </indexterm>
+ <function>col_description</function> ( <parameter>table</parameter> <type>oid</type>, <parameter>column</parameter> <type>integer</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the comment for a table column, which is specified by the OID
+ of its table and its column number.
+ (<function>obj_description</function> cannot be used for table
+ columns, since columns do not have OIDs of their own.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>obj_description</primary>
+ </indexterm>
+ <function>obj_description</function> ( <parameter>object</parameter> <type>oid</type>, <parameter>catalog</parameter> <type>name</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the comment for a database object specified by its OID and the
+ name of the containing system catalog. For
+ example, <literal>obj_description(123456, 'pg_class')</literal> would
+ retrieve the comment for the table with OID 123456.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>obj_description</function> ( <parameter>object</parameter> <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the comment for a database object specified by its OID alone.
+ This is <emphasis>deprecated</emphasis> since there is no guarantee
+ that OIDs are unique across different system catalogs; therefore, the
+ wrong comment might be returned.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>shobj_description</primary>
+ </indexterm>
+ <function>shobj_description</function> ( <parameter>object</parameter> <type>oid</type>, <parameter>catalog</parameter> <type>name</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the comment for a shared database object specified by its OID
+ and the name of the containing system catalog. This is just
+ like <function>obj_description</function> except that it is used for
+ retrieving comments on shared objects (that is, databases, roles, and
+ tablespaces). Some system catalogs are global to all databases within
+ each cluster, and the descriptions for objects in them are stored
+ globally as well.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-validity">
+ <title>Data Validity Checking Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-info-validity-table"/>
+ can be helpful for checking validity of proposed input data.
+ </para>
+
+ <table id="functions-info-validity-table">
+ <title>Data Validity Checking Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_input_is_valid</primary>
+ </indexterm>
+ <function>pg_input_is_valid</function> (
+ <parameter>string</parameter> <type>text</type>,
+ <parameter>type</parameter> <type>text</type>
+ )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether the given <parameter>string</parameter> is valid
+ input for the specified data type, returning true or false.
+ </para>
+ <para>
+ This function will only work as desired if the data type's input
+ function has been updated to report invalid input as
+ a <quote>soft</quote> error. Otherwise, invalid input will abort
+ the transaction, just as if the string had been cast to the type
+ directly.
+ </para>
+ <para>
+ <literal>pg_input_is_valid('42', 'integer')</literal>
+ <returnvalue>t</returnvalue>
+ </para>
+ <para>
+ <literal>pg_input_is_valid('42000000000', 'integer')</literal>
+ <returnvalue>f</returnvalue>
+ </para>
+ <para>
+ <literal>pg_input_is_valid('1234.567', 'numeric(7,4)')</literal>
+ <returnvalue>f</returnvalue>
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_input_error_info</primary>
+ </indexterm>
+ <function>pg_input_error_info</function> (
+ <parameter>string</parameter> <type>text</type>,
+ <parameter>type</parameter> <type>text</type>
+ )
+ <returnvalue>record</returnvalue>
+ ( <parameter>message</parameter> <type>text</type>,
+ <parameter>detail</parameter> <type>text</type>,
+ <parameter>hint</parameter> <type>text</type>,
+ <parameter>sql_error_code</parameter> <type>text</type> )
+ </para>
+ <para>
+ Tests whether the given <parameter>string</parameter> is valid
+ input for the specified data type; if not, return the details of
+ the error that would have been thrown. If the input is valid, the
+ results are NULL. The inputs are the same as
+ for <function>pg_input_is_valid</function>.
+ </para>
+ <para>
+ This function will only work as desired if the data type's input
+ function has been updated to report invalid input as
+ a <quote>soft</quote> error. Otherwise, invalid input will abort
+ the transaction, just as if the string had been cast to the type
+ directly.
+ </para>
+ <para>
+ <literal>select * from pg_input_error_info('42000000000', 'integer')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ message | detail | hint | sql_error_code
+------------------------------------------------------+--------+------+----------------
+ value "42000000000" is out of range for type integer | | | 22003
+</programlisting>
+ </para>
+ <para>
+ <literal>select message, detail from pg_input_error_info('1234.567', 'numeric(7,4)')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ message | detail
+------------------------+----------------------------------&zwsp;-------------------------------------------------
+ numeric field overflow | A field with precision 7, scale 4 must round to an absolute value less than 10^3.
+</programlisting>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-snapshot">
+ <title>Transaction ID and Snapshot Information Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-pg-snapshot"/>
+ provide server transaction information in an exportable form. The main
+ use of these functions is to determine which transactions were committed
+ between two snapshots.
+ </para>
+
+ <table id="functions-pg-snapshot">
+ <title>Transaction ID and Snapshot Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_xact_id</primary>
+ </indexterm>
+ <function>pg_current_xact_id</function> ()
+ <returnvalue>xid8</returnvalue>
+ </para>
+ <para>
+ Returns the current transaction's ID. It will assign a new one if the
+ current transaction does not have one already (because it has not
+ performed any database updates); see <xref
+ linkend="transaction-id"/> for details. If executed in a
+ subtransaction, this will return the top-level transaction ID;
+ see <xref linkend="subxacts"/> for details.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_xact_id_if_assigned</primary>
+ </indexterm>
+ <function>pg_current_xact_id_if_assigned</function> ()
+ <returnvalue>xid8</returnvalue>
+ </para>
+ <para>
+ Returns the current transaction's ID, or <literal>NULL</literal> if no
+ ID is assigned yet. (It's best to use this variant if the transaction
+ might otherwise be read-only, to avoid unnecessary consumption of an
+ XID.)
+ If executed in a subtransaction, this will return the top-level
+ transaction ID.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_xact_status</primary>
+ </indexterm>
+ <function>pg_xact_status</function> ( <type>xid8</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Reports the commit status of a recent transaction.
+ The result is one of <literal>in progress</literal>,
+ <literal>committed</literal>, or <literal>aborted</literal>,
+ provided that the transaction is recent enough that the system retains
+ the commit status of that transaction.
+ If it is old enough that no references to the transaction survive in
+ the system and the commit status information has been discarded, the
+ result is <literal>NULL</literal>.
+ Applications might use this function, for example, to determine
+ whether their transaction committed or aborted after the application
+ and database server become disconnected while
+ a <literal>COMMIT</literal> is in progress.
+ Note that prepared transactions are reported as <literal>in
+ progress</literal>; applications must check <link
+ linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link>
+ if they need to determine whether a transaction ID belongs to a
+ prepared transaction.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_snapshot</primary>
+ </indexterm>
+ <function>pg_current_snapshot</function> ()
+ <returnvalue>pg_snapshot</returnvalue>
+ </para>
+ <para>
+ Returns a current <firstterm>snapshot</firstterm>, a data structure
+ showing which transaction IDs are now in-progress.
+ Only top-level transaction IDs are included in the snapshot;
+ subtransaction IDs are not shown; see <xref linkend="subxacts"/>
+ for details.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_snapshot_xip</primary>
+ </indexterm>
+ <function>pg_snapshot_xip</function> ( <type>pg_snapshot</type> )
+ <returnvalue>setof xid8</returnvalue>
+ </para>
+ <para>
+ Returns the set of in-progress transaction IDs contained in a snapshot.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_snapshot_xmax</primary>
+ </indexterm>
+ <function>pg_snapshot_xmax</function> ( <type>pg_snapshot</type> )
+ <returnvalue>xid8</returnvalue>
+ </para>
+ <para>
+ Returns the <structfield>xmax</structfield> of a snapshot.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_snapshot_xmin</primary>
+ </indexterm>
+ <function>pg_snapshot_xmin</function> ( <type>pg_snapshot</type> )
+ <returnvalue>xid8</returnvalue>
+ </para>
+ <para>
+ Returns the <structfield>xmin</structfield> of a snapshot.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_visible_in_snapshot</primary>
+ </indexterm>
+ <function>pg_visible_in_snapshot</function> ( <type>xid8</type>, <type>pg_snapshot</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is the given transaction ID <firstterm>visible</firstterm> according
+ to this snapshot (that is, was it completed before the snapshot was
+ taken)? Note that this function will not give the correct answer for
+ a subtransaction ID (subxid); see <xref linkend="subxacts"/> for
+ details.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The internal transaction ID type <type>xid</type> is 32 bits wide and
+ wraps around every 4 billion transactions. However,
+ the functions shown in <xref linkend="functions-pg-snapshot"/> use a
+ 64-bit type <type>xid8</type> that does not wrap around during the life
+ of an installation and can be converted to <type>xid</type> by casting if
+ required; see <xref linkend="transaction-id"/> for details.
+ The data type <type>pg_snapshot</type> stores information about
+ transaction ID visibility at a particular moment in time. Its components
+ are described in <xref linkend="functions-pg-snapshot-parts"/>.
+ <type>pg_snapshot</type>'s textual representation is
+ <literal><replaceable>xmin</replaceable>:<replaceable>xmax</replaceable>:<replaceable>xip_list</replaceable></literal>.
+ For example <literal>10:20:10,14,15</literal> means
+ <literal>xmin=10, xmax=20, xip_list=10, 14, 15</literal>.
+ </para>
+
+ <table id="functions-pg-snapshot-parts">
+ <title>Snapshot Components</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><structfield>xmin</structfield></entry>
+ <entry>
+ Lowest transaction ID that was still active. All transaction IDs
+ less than <structfield>xmin</structfield> are either committed and visible,
+ or rolled back and dead.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>xmax</structfield></entry>
+ <entry>
+ One past the highest completed transaction ID. All transaction IDs
+ greater than or equal to <structfield>xmax</structfield> had not yet
+ completed as of the time of the snapshot, and thus are invisible.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>xip_list</structfield></entry>
+ <entry>
+ Transactions in progress at the time of the snapshot. A transaction
+ ID that is <literal>xmin <= <replaceable>X</replaceable> <
+ xmax</literal> and not in this list was already completed at the time
+ of the snapshot, and thus is either visible or dead according to its
+ commit status. This list does not include the transaction IDs of
+ subtransactions (subxids).
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ In releases of <productname>PostgreSQL</productname> before 13 there was
+ no <type>xid8</type> type, so variants of these functions were provided
+ that used <type>bigint</type> to represent a 64-bit XID, with a
+ correspondingly distinct snapshot data type <type>txid_snapshot</type>.
+ These older functions have <literal>txid</literal> in their names. They
+ are still supported for backward compatibility, but may be removed from a
+ future release. See <xref linkend="functions-txid-snapshot"/>.
+ </para>
+
+ <table id="functions-txid-snapshot">
+ <title>Deprecated Transaction ID and Snapshot Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>age</primary>
+ </indexterm>
+ <function>age</function> ( <type>xid</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of transactions between the supplied
+ transaction id and the current transaction counter.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>mxid_age</primary>
+ </indexterm>
+ <function>mxid_age</function> ( <type>xid</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of multixacts IDs between the supplied
+ multixact ID and the current multixacts counter.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_current</primary>
+ </indexterm>
+ <function>txid_current</function> ()
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ See <function>pg_current_xact_id()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_current_if_assigned</primary>
+ </indexterm>
+ <function>txid_current_if_assigned</function> ()
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ See <function>pg_current_xact_id_if_assigned()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_current_snapshot</primary>
+ </indexterm>
+ <function>txid_current_snapshot</function> ()
+ <returnvalue>txid_snapshot</returnvalue>
+ </para>
+ <para>
+ See <function>pg_current_snapshot()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_snapshot_xip</primary>
+ </indexterm>
+ <function>txid_snapshot_xip</function> ( <type>txid_snapshot</type> )
+ <returnvalue>setof bigint</returnvalue>
+ </para>
+ <para>
+ See <function>pg_snapshot_xip()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_snapshot_xmax</primary>
+ </indexterm>
+ <function>txid_snapshot_xmax</function> ( <type>txid_snapshot</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ See <function>pg_snapshot_xmax()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_snapshot_xmin</primary>
+ </indexterm>
+ <function>txid_snapshot_xmin</function> ( <type>txid_snapshot</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ See <function>pg_snapshot_xmin()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_visible_in_snapshot</primary>
+ </indexterm>
+ <function>txid_visible_in_snapshot</function> ( <type>bigint</type>, <type>txid_snapshot</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ See <function>pg_visible_in_snapshot()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>txid_status</primary>
+ </indexterm>
+ <function>txid_status</function> ( <type>bigint</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ See <function>pg_xact_status()</function>.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-commit-timestamp">
+ <title>Committed Transaction Information Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-commit-timestamp"/>
+ provide information about when past transactions were committed.
+ They only provide useful data when the
+ <xref linkend="guc-track-commit-timestamp"/> configuration option is
+ enabled, and only for transactions that were committed after it was
+ enabled. Commit timestamp information is routinely removed during
+ vacuum.
+ </para>
+
+ <table id="functions-commit-timestamp">
+ <title>Committed Transaction Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_xact_commit_timestamp</primary>
+ </indexterm>
+ <function>pg_xact_commit_timestamp</function> ( <type>xid</type> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Returns the commit timestamp of a transaction.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_xact_commit_timestamp_origin</primary>
+ </indexterm>
+ <function>pg_xact_commit_timestamp_origin</function> ( <type>xid</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>timestamp</parameter> <type>timestamp with time zone</type>,
+ <parameter>roident</parameter> <type>oid</type>)
+ </para>
+ <para>
+ Returns the commit timestamp and replication origin of a transaction.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_last_committed_xact</primary>
+ </indexterm>
+ <function>pg_last_committed_xact</function> ()
+ <returnvalue>record</returnvalue>
+ ( <parameter>xid</parameter> <type>xid</type>,
+ <parameter>timestamp</parameter> <type>timestamp with time zone</type>,
+ <parameter>roident</parameter> <type>oid</type> )
+ </para>
+ <para>
+ Returns the transaction ID, commit timestamp and replication origin
+ of the latest committed transaction.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-controldata">
+ <title>Control Data Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-controldata"/>
+ print information initialized during <command>initdb</command>, such
+ as the catalog version. They also show information about write-ahead
+ logging and checkpoint processing. This information is cluster-wide,
+ not specific to any one database. These functions provide most of the same
+ information, from the same source, as the
+ <xref linkend="app-pgcontroldata"/> application.
+ </para>
+
+ <table id="functions-controldata">
+ <title>Control Data Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_control_checkpoint</primary>
+ </indexterm>
+ <function>pg_control_checkpoint</function> ()
+ <returnvalue>record</returnvalue>
+ </para>
+ <para>
+ Returns information about current checkpoint state, as shown in
+ <xref linkend="functions-pg-control-checkpoint"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_control_system</primary>
+ </indexterm>
+ <function>pg_control_system</function> ()
+ <returnvalue>record</returnvalue>
+ </para>
+ <para>
+ Returns information about current control file state, as shown in
+ <xref linkend="functions-pg-control-system"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_control_init</primary>
+ </indexterm>
+ <function>pg_control_init</function> ()
+ <returnvalue>record</returnvalue>
+ </para>
+ <para>
+ Returns information about cluster initialization state, as shown in
+ <xref linkend="functions-pg-control-init"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_control_recovery</primary>
+ </indexterm>
+ <function>pg_control_recovery</function> ()
+ <returnvalue>record</returnvalue>
+ </para>
+ <para>
+ Returns information about recovery state, as shown in
+ <xref linkend="functions-pg-control-recovery"/>.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-pg-control-checkpoint">
+ <title><function>pg_control_checkpoint</function> Output Columns</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Column Name</entry>
+ <entry>Data Type</entry>
+ </row>
+ </thead>
+
+ <tbody>
+
+ <row>
+ <entry><structfield>checkpoint_lsn</structfield></entry>
+ <entry><type>pg_lsn</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>redo_lsn</structfield></entry>
+ <entry><type>pg_lsn</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>redo_wal_file</structfield></entry>
+ <entry><type>text</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>timeline_id</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>prev_timeline_id</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>full_page_writes</structfield></entry>
+ <entry><type>boolean</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>next_xid</structfield></entry>
+ <entry><type>text</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>next_oid</structfield></entry>
+ <entry><type>oid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>next_multixact_id</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>next_multi_offset</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_xid</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_xid_dbid</structfield></entry>
+ <entry><type>oid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_active_xid</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_multi_xid</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_multi_dbid</structfield></entry>
+ <entry><type>oid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>oldest_commit_ts_xid</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>newest_commit_ts_xid</structfield></entry>
+ <entry><type>xid</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>checkpoint_time</structfield></entry>
+ <entry><type>timestamp with time zone</type></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-pg-control-system">
+ <title><function>pg_control_system</function> Output Columns</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Column Name</entry>
+ <entry>Data Type</entry>
+ </row>
+ </thead>
+
+ <tbody>
+
+ <row>
+ <entry><structfield>pg_control_version</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>catalog_version_no</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>system_identifier</structfield></entry>
+ <entry><type>bigint</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>pg_control_last_modified</structfield></entry>
+ <entry><type>timestamp with time zone</type></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-pg-control-init">
+ <title><function>pg_control_init</function> Output Columns</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Column Name</entry>
+ <entry>Data Type</entry>
+ </row>
+ </thead>
+
+ <tbody>
+
+ <row>
+ <entry><structfield>max_data_alignment</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>database_block_size</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>blocks_per_segment</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>wal_block_size</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>bytes_per_wal_segment</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>max_identifier_length</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>max_index_columns</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>max_toast_chunk_size</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>large_object_chunk_size</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>float8_pass_by_value</structfield></entry>
+ <entry><type>boolean</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>data_page_checksum_version</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-pg-control-recovery">
+ <title><function>pg_control_recovery</function> Output Columns</title>
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Column Name</entry>
+ <entry>Data Type</entry>
+ </row>
+ </thead>
+
+ <tbody>
+
+ <row>
+ <entry><structfield>min_recovery_end_lsn</structfield></entry>
+ <entry><type>pg_lsn</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>min_recovery_end_timeline</structfield></entry>
+ <entry><type>integer</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>backup_start_lsn</structfield></entry>
+ <entry><type>pg_lsn</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>backup_end_lsn</structfield></entry>
+ <entry><type>pg_lsn</type></entry>
+ </row>
+
+ <row>
+ <entry><structfield>end_of_backup_record_required</structfield></entry>
+ <entry><type>boolean</type></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-version">
+ <title>Version Information Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-version"/>
+ print version information.
+ </para>
+
+ <table id="functions-version">
+ <title>Version Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>version</primary>
+ </indexterm>
+ <function>version</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns a string describing the <productname>PostgreSQL</productname>
+ server's version. You can also get this information from
+ <xref linkend="guc-server-version"/>, or for a machine-readable
+ version use <xref linkend="guc-server-version-num"/>. Software
+ developers should use <varname>server_version_num</varname> (available
+ since 8.2) or <xref linkend="libpq-PQserverVersion"/> instead of
+ parsing the text version.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>unicode_version</primary>
+ </indexterm>
+ <function>unicode_version</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns a string representing the version of Unicode used by
+ <productname>PostgreSQL</productname>.
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>icu_unicode_version</primary>
+ </indexterm>
+ <function>icu_unicode_version</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns a string representing the version of Unicode used by ICU, if
+ the server was built with ICU support; otherwise returns
+ <literal>NULL</literal> </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-info-wal-summary">
+ <title>WAL Summarization Information Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-wal-summary"/>
+ print information about the status of WAL summarization.
+ See <xref linkend="guc-summarize-wal" />.
+ </para>
+
+ <table id="functions-wal-summary">
+ <title>WAL Summarization Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_available_wal_summaries</primary>
+ </indexterm>
+ <function>pg_available_wal_summaries</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>tli</parameter> <type>bigint</type>,
+ <parameter>start_lsn</parameter> <type>pg_lsn</type>,
+ <parameter>end_lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Returns information about the WAL summary files present in the
+ data directory, under <literal>pg_wal/summaries</literal>.
+ One row will be returned per WAL summary file. Each file summarizes
+ WAL on the indicated TLI within the indicated LSN range. This function
+ might be useful to determine whether enough WAL summaries are present
+ on the server to take an incremental backup based on some prior
+ backup whose start LSN is known.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_wal_summary_contents</primary>
+ </indexterm>
+ <function>pg_wal_summary_contents</function> ( <parameter>tli</parameter> <type>bigint</type>, <parameter>start_lsn</parameter> <type>pg_lsn</type>, <parameter>end_lsn</parameter> <type>pg_lsn</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>relfilenode</parameter> <type>oid</type>,
+ <parameter>reltablespace</parameter> <type>oid</type>,
+ <parameter>reldatabase</parameter> <type>oid</type>,
+ <parameter>relforknumber</parameter> <type>smallint</type>,
+ <parameter>relblocknumber</parameter> <type>bigint</type>,
+ <parameter>is_limit_block</parameter> <type>boolean</type> )
+ </para>
+ <para>
+ Returns one information about the contents of a single WAL summary file
+ identified by TLI and starting and ending LSNs. Each row with
+ <literal>is_limit_block</literal> false indicates that the block
+ identified by the remaining output columns was modified by at least
+ one WAL record within the range of records summarized by this file.
+ Each row with <literal>is_limit_block</literal> true indicates either
+ that (a) the relation fork was truncated to the length given by
+ <literal>relblocknumber</literal> within the relevant range of WAL
+ records or (b) that the relation fork was created or dropped within
+ the relevant range of WAL records; in such cases,
+ <literal>relblocknumber</literal> will be zero.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_wal_summarizer_state</primary>
+ </indexterm>
+ <function>pg_get_wal_summarizer_state</function> ()
+ <returnvalue>record</returnvalue>
+ ( <parameter>summarized_tli</parameter> <type>bigint</type>,
+ <parameter>summarized_lsn</parameter> <type>pg_lsn</type>,
+ <parameter>pending_lsn</parameter> <type>pg_lsn</type>,
+ <parameter>summarizer_pid</parameter> <type>int</type> )
+ </para>
+ <para>
+ Returns information about the progress of the WAL summarizer. If the
+ WAL summarizer has never run since the instance was started, then
+ <literal>summarized_tli</literal> and <literal>summarized_lsn</literal>
+ will be <literal>0</literal> and <literal>0/0</literal> respectively;
+ otherwise, they will be the TLI and ending LSN of the last WAL summary
+ file written to disk. If the WAL summarizer is currently running,
+ <literal>pending_lsn</literal> will be the ending LSN of the last
+ record that it has consumed, which must always be greater than or
+ equal to <literal>summarized_lsn</literal>; if the WAL summarizer is
+ not running, it will be equal to <literal>summarized_lsn</literal>.
+ <literal>summarizer_pid</literal> is the PID of the WAL summarizer
+ process, if it is running, and otherwise NULL.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ </sect1>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 8fd550ad..35a2d25b 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -12602,3646 +12602,7 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
</sect1>
- <sect1 id="functions-info">
- <title>System Information Functions and Operators</title>
-
- <para>
- The functions described in this section are used to obtain various
- information about a <productname>PostgreSQL</productname> installation.
- </para>
-
- <sect2 id="functions-info-session">
- <title>Session Information Functions</title>
-
- <para>
- <xref linkend="functions-info-session-table"/> shows several
- functions that extract session and system information.
- </para>
-
- <para>
- In addition to the functions listed in this section, there are a number of
- functions related to the statistics system that also provide system
- information. See <xref linkend="monitoring-stats-functions"/> for more
- information.
- </para>
-
- <table id="functions-info-session-table">
- <title>Session Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_catalog</primary>
- </indexterm>
- <function>current_catalog</function>
- <returnvalue>name</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>current_database</primary>
- </indexterm>
- <function>current_database</function> ()
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns the name of the current database. (Databases are
- called <quote>catalogs</quote> in the SQL standard,
- so <function>current_catalog</function> is the standard's
- spelling.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_query</primary>
- </indexterm>
- <function>current_query</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the text of the currently executing query, as submitted
- by the client (which might contain more than one statement).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_role</primary>
- </indexterm>
- <function>current_role</function>
- <returnvalue>name</returnvalue>
- </para>
- <para>
- This is equivalent to <function>current_user</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_schema</primary>
- </indexterm>
- <indexterm>
- <primary>schema</primary>
- <secondary>current</secondary>
- </indexterm>
- <function>current_schema</function>
- <returnvalue>name</returnvalue>
- </para>
- <para role="func_signature">
- <function>current_schema</function> ()
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns the name of the schema that is first in the search path (or a
- null value if the search path is empty). This is the schema that will
- be used for any tables or other named objects that are created without
- specifying a target schema.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_schemas</primary>
- </indexterm>
- <indexterm>
- <primary>search path</primary>
- <secondary>current</secondary>
- </indexterm>
- <function>current_schemas</function> ( <parameter>include_implicit</parameter> <type>boolean</type> )
- <returnvalue>name[]</returnvalue>
- </para>
- <para>
- Returns an array of the names of all schemas presently in the
- effective search path, in their priority order. (Items in the current
- <xref linkend="guc-search-path"/> setting that do not correspond to
- existing, searchable schemas are omitted.) If the Boolean argument
- is <literal>true</literal>, then implicitly-searched system schemas
- such as <literal>pg_catalog</literal> are included in the result.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_user</primary>
- </indexterm>
- <indexterm>
- <primary>user</primary>
- <secondary>current</secondary>
- </indexterm>
- <function>current_user</function>
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns the user name of the current execution context.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>inet_client_addr</primary>
- </indexterm>
- <function>inet_client_addr</function> ()
- <returnvalue>inet</returnvalue>
- </para>
- <para>
- Returns the IP address of the current client,
- or <literal>NULL</literal> if the current connection is via a
- Unix-domain socket.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>inet_client_port</primary>
- </indexterm>
- <function>inet_client_port</function> ()
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the IP port number of the current client,
- or <literal>NULL</literal> if the current connection is via a
- Unix-domain socket.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>inet_server_addr</primary>
- </indexterm>
- <function>inet_server_addr</function> ()
- <returnvalue>inet</returnvalue>
- </para>
- <para>
- Returns the IP address on which the server accepted the current
- connection,
- or <literal>NULL</literal> if the current connection is via a
- Unix-domain socket.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>inet_server_port</primary>
- </indexterm>
- <function>inet_server_port</function> ()
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the IP port number on which the server accepted the current
- connection,
- or <literal>NULL</literal> if the current connection is via a
- Unix-domain socket.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_backend_pid</primary>
- </indexterm>
- <function>pg_backend_pid</function> ()
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the process ID of the server process attached to the current
- session.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_blocking_pids</primary>
- </indexterm>
- <function>pg_blocking_pids</function> ( <type>integer</type> )
- <returnvalue>integer[]</returnvalue>
- </para>
- <para>
- Returns an array of the process ID(s) of the sessions that are
- blocking the server process with the specified process ID from
- acquiring a lock, or an empty array if there is no such server process
- or it is not blocked.
- </para>
- <para>
- One server process blocks another if it either holds a lock that
- conflicts with the blocked process's lock request (hard block), or is
- waiting for a lock that would conflict with the blocked process's lock
- request and is ahead of it in the wait queue (soft block). When using
- parallel queries the result always lists client-visible process IDs
- (that is, <function>pg_backend_pid</function> results) even if the
- actual lock is held or awaited by a child worker process. As a result
- of that, there may be duplicated PIDs in the result. Also note that
- when a prepared transaction holds a conflicting lock, it will be
- represented by a zero process ID.
- </para>
- <para>
- Frequent calls to this function could have some impact on database
- performance, because it needs exclusive access to the lock manager's
- shared state for a short time.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_conf_load_time</primary>
- </indexterm>
- <function>pg_conf_load_time</function> ()
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Returns the time when the server configuration files were last loaded.
- If the current session was alive at the time, this will be the time
- when the session itself re-read the configuration files (so the
- reading will vary a little in different sessions). Otherwise it is
- the time when the postmaster process re-read the configuration files.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_logfile</primary>
- </indexterm>
- <indexterm>
- <primary>Logging</primary>
- <secondary>pg_current_logfile function</secondary>
- </indexterm>
- <indexterm>
- <primary>current_logfiles</primary>
- <secondary>and the pg_current_logfile function</secondary>
- </indexterm>
- <indexterm>
- <primary>Logging</primary>
- <secondary>current_logfiles file and the pg_current_logfile
- function</secondary>
- </indexterm>
- <function>pg_current_logfile</function> ( <optional> <type>text</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the path name of the log file currently in use by the logging
- collector. The path includes the <xref linkend="guc-log-directory"/>
- directory and the individual log file name. The result
- is <literal>NULL</literal> if the logging collector is disabled.
- When multiple log files exist, each in a different
- format, <function>pg_current_logfile</function> without an argument
- returns the path of the file having the first format found in the
- ordered list: <literal>stderr</literal>,
- <literal>csvlog</literal>, <literal>jsonlog</literal>.
- <literal>NULL</literal> is returned if no log file has any of these
- formats.
- To request information about a specific log file format, supply
- either <literal>csvlog</literal>, <literal>jsonlog</literal> or
- <literal>stderr</literal> as the
- value of the optional parameter. The result is <literal>NULL</literal>
- if the log format requested is not configured in
- <xref linkend="guc-log-destination"/>.
- The result reflects the contents of
- the <filename>current_logfiles</filename> file.
- </para>
- <para>
- This function is restricted to superusers and roles with privileges of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_my_temp_schema</primary>
- </indexterm>
- <function>pg_my_temp_schema</function> ()
- <returnvalue>oid</returnvalue>
- </para>
- <para>
- Returns the OID of the current session's temporary schema, or zero if
- it has none (because it has not created any temporary tables).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_is_other_temp_schema</primary>
- </indexterm>
- <function>pg_is_other_temp_schema</function> ( <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if the given OID is the OID of another session's
- temporary schema. (This can be useful, for example, to exclude other
- sessions' temporary tables from a catalog display.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_jit_available</primary>
- </indexterm>
- <function>pg_jit_available</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if a <acronym>JIT</acronym> compiler extension is
- available (see <xref linkend="jit"/>) and the
- <xref linkend="guc-jit"/> configuration parameter is set to
- <literal>on</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_listening_channels</primary>
- </indexterm>
- <function>pg_listening_channels</function> ()
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Returns the set of names of asynchronous notification channels that
- the current session is listening to.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_notification_queue_usage</primary>
- </indexterm>
- <function>pg_notification_queue_usage</function> ()
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Returns the fraction (0–1) of the asynchronous notification
- queue's maximum size that is currently occupied by notifications that
- are waiting to be processed.
- See <xref linkend="sql-listen"/> and <xref linkend="sql-notify"/>
- for more information.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_postmaster_start_time</primary>
- </indexterm>
- <function>pg_postmaster_start_time</function> ()
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Returns the time when the server started.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_safe_snapshot_blocking_pids</primary>
- </indexterm>
- <function>pg_safe_snapshot_blocking_pids</function> ( <type>integer</type> )
- <returnvalue>integer[]</returnvalue>
- </para>
- <para>
- Returns an array of the process ID(s) of the sessions that are blocking
- the server process with the specified process ID from acquiring a safe
- snapshot, or an empty array if there is no such server process or it
- is not blocked.
- </para>
- <para>
- A session running a <literal>SERIALIZABLE</literal> transaction blocks
- a <literal>SERIALIZABLE READ ONLY DEFERRABLE</literal> transaction
- from acquiring a snapshot until the latter determines that it is safe
- to avoid taking any predicate locks. See
- <xref linkend="xact-serializable"/> for more information about
- serializable and deferrable transactions.
- </para>
- <para>
- Frequent calls to this function could have some impact on database
- performance, because it needs access to the predicate lock manager's
- shared state for a short time.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_trigger_depth</primary>
- </indexterm>
- <function>pg_trigger_depth</function> ()
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the current nesting level
- of <productname>PostgreSQL</productname> triggers (0 if not called,
- directly or indirectly, from inside a trigger).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>session_user</primary>
- </indexterm>
- <function>session_user</function>
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns the session user's name.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>system_user</primary>
- </indexterm>
- <function>system_user</function>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the authentication method and the identity (if any) that the
- user presented during the authentication cycle before they were
- assigned a database role. It is represented as
- <literal>auth_method:identity</literal> or
- <literal>NULL</literal> if the user has not been authenticated (for
- example if <link linkend="auth-trust">Trust authentication</link> has
- been used).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>user</primary>
- </indexterm>
- <function>user</function>
- <returnvalue>name</returnvalue>
- </para>
- <para>
- This is equivalent to <function>current_user</function>.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <note>
- <para>
- <function>current_catalog</function>,
- <function>current_role</function>,
- <function>current_schema</function>,
- <function>current_user</function>,
- <function>session_user</function>,
- and <function>user</function> have special syntactic status
- in <acronym>SQL</acronym>: they must be called without trailing
- parentheses. In PostgreSQL, parentheses can optionally be used with
- <function>current_schema</function>, but not with the others.
- </para>
- </note>
-
- <para>
- The <function>session_user</function> is normally the user who initiated
- the current database connection; but superusers can change this setting
- with <xref linkend="sql-set-session-authorization"/>.
- The <function>current_user</function> is the user identifier
- that is applicable for permission checking. Normally it is equal
- to the session user, but it can be changed with
- <xref linkend="sql-set-role"/>.
- It also changes during the execution of
- functions with the attribute <literal>SECURITY DEFINER</literal>.
- In Unix parlance, the session user is the <quote>real user</quote> and
- the current user is the <quote>effective user</quote>.
- <function>current_role</function> and <function>user</function> are
- synonyms for <function>current_user</function>. (The SQL standard draws
- a distinction between <function>current_role</function>
- and <function>current_user</function>, but <productname>PostgreSQL</productname>
- does not, since it unifies users and roles into a single kind of entity.)
- </para>
-
- </sect2>
-
- <sect2 id="functions-info-access">
- <title>Access Privilege Inquiry Functions</title>
-
- <indexterm>
- <primary>privilege</primary>
- <secondary>querying</secondary>
- </indexterm>
-
- <para>
- <xref linkend="functions-info-access-table"/> lists functions that
- allow querying object access privileges programmatically.
- (See <xref linkend="ddl-priv"/> for more information about
- privileges.)
- In these functions, the user whose privileges are being inquired about
- can be specified by name or by OID
- (<structname>pg_authid</structname>.<structfield>oid</structfield>), or if
- the name is given as <literal>public</literal> then the privileges of the
- PUBLIC pseudo-role are checked. Also, the <parameter>user</parameter>
- argument can be omitted entirely, in which case
- the <function>current_user</function> is assumed.
- The object that is being inquired about can be specified either by name or
- by OID, too. When specifying by name, a schema name can be included if
- relevant.
- The access privilege of interest is specified by a text string, which must
- evaluate to one of the appropriate privilege keywords for the object's type
- (e.g., <literal>SELECT</literal>). Optionally, <literal>WITH GRANT
- OPTION</literal> can be added to a privilege type to test whether the
- privilege is held with grant option. Also, multiple privilege types can be
- listed separated by commas, in which case the result will be true if any of
- the listed privileges is held. (Case of the privilege string is not
- significant, and extra whitespace is allowed between but not within
- privilege names.)
- Some examples:
-<programlisting>
-SELECT has_table_privilege('myschema.mytable', 'select');
-SELECT has_table_privilege('joe', 'mytable', 'INSERT, SELECT WITH GRANT OPTION');
-</programlisting>
- </para>
-
- <table id="functions-info-access-table">
- <title>Access Privilege Inquiry Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_any_column_privilege</primary>
- </indexterm>
- <function>has_any_column_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>table</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for any column of table?
- This succeeds either if the privilege is held for the whole table, or
- if there is a column-level grant of the privilege for at least one
- column.
- Allowable privilege types are
- <literal>SELECT</literal>, <literal>INSERT</literal>,
- <literal>UPDATE</literal>, and <literal>REFERENCES</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_column_privilege</primary>
- </indexterm>
- <function>has_column_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>table</parameter> <type>text</type> or <type>oid</type>,
- <parameter>column</parameter> <type>text</type> or <type>smallint</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for the specified table column?
- This succeeds either if the privilege is held for the whole table, or
- if there is a column-level grant of the privilege for the column.
- The column can be specified by name or by attribute number
- (<structname>pg_attribute</structname>.<structfield>attnum</structfield>).
- Allowable privilege types are
- <literal>SELECT</literal>, <literal>INSERT</literal>,
- <literal>UPDATE</literal>, and <literal>REFERENCES</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_database_privilege</primary>
- </indexterm>
- <function>has_database_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>database</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for database?
- Allowable privilege types are
- <literal>CREATE</literal>,
- <literal>CONNECT</literal>,
- <literal>TEMPORARY</literal>, and
- <literal>TEMP</literal> (which is equivalent to
- <literal>TEMPORARY</literal>).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_foreign_data_wrapper_privilege</primary>
- </indexterm>
- <function>has_foreign_data_wrapper_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>fdw</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for foreign-data wrapper?
- The only allowable privilege type is <literal>USAGE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_function_privilege</primary>
- </indexterm>
- <function>has_function_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>function</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for function?
- The only allowable privilege type is <literal>EXECUTE</literal>.
- </para>
- <para>
- When specifying a function by name rather than by OID, the allowed
- input is the same as for the <type>regprocedure</type> data type (see
- <xref linkend="datatype-oid"/>).
- An example is:
-<programlisting>
-SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute');
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_language_privilege</primary>
- </indexterm>
- <function>has_language_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>language</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for language?
- The only allowable privilege type is <literal>USAGE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_parameter_privilege</primary>
- </indexterm>
- <function>has_parameter_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>parameter</parameter> <type>text</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for configuration parameter?
- The parameter name is case-insensitive.
- Allowable privilege types are <literal>SET</literal>
- and <literal>ALTER SYSTEM</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_schema_privilege</primary>
- </indexterm>
- <function>has_schema_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>schema</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for schema?
- Allowable privilege types are
- <literal>CREATE</literal> and
- <literal>USAGE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_sequence_privilege</primary>
- </indexterm>
- <function>has_sequence_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>sequence</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for sequence?
- Allowable privilege types are
- <literal>USAGE</literal>,
- <literal>SELECT</literal>, and
- <literal>UPDATE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_server_privilege</primary>
- </indexterm>
- <function>has_server_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>server</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for foreign server?
- The only allowable privilege type is <literal>USAGE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_table_privilege</primary>
- </indexterm>
- <function>has_table_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>table</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for table?
- Allowable privilege types
- are <literal>SELECT</literal>, <literal>INSERT</literal>,
- <literal>UPDATE</literal>, <literal>DELETE</literal>,
- <literal>TRUNCATE</literal>, <literal>REFERENCES</literal>,
- <literal>TRIGGER</literal>, and <literal>MAINTAIN</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_tablespace_privilege</primary>
- </indexterm>
- <function>has_tablespace_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>tablespace</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for tablespace?
- The only allowable privilege type is <literal>CREATE</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>has_type_privilege</primary>
- </indexterm>
- <function>has_type_privilege</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>type</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for data type?
- The only allowable privilege type is <literal>USAGE</literal>.
- When specifying a type by name rather than by OID, the allowed input
- is the same as for the <type>regtype</type> data type (see
- <xref linkend="datatype-oid"/>).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_has_role</primary>
- </indexterm>
- <function>pg_has_role</function> (
- <optional> <parameter>user</parameter> <type>name</type> or <type>oid</type>, </optional>
- <parameter>role</parameter> <type>text</type> or <type>oid</type>,
- <parameter>privilege</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does user have privilege for role?
- Allowable privilege types are
- <literal>MEMBER</literal>, <literal>USAGE</literal>,
- and <literal>SET</literal>.
- <literal>MEMBER</literal> denotes direct or indirect membership in
- the role without regard to what specific privileges may be conferred.
- <literal>USAGE</literal> denotes whether the privileges of the role
- are immediately available without doing <command>SET ROLE</command>,
- while <literal>SET</literal> denotes whether it is possible to change
- to the role using the <literal>SET ROLE</literal> command.
- This function does not allow the special case of
- setting <parameter>user</parameter> to <literal>public</literal>,
- because the PUBLIC pseudo-role can never be a member of real roles.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>row_security_active</primary>
- </indexterm>
- <function>row_security_active</function> (
- <parameter>table</parameter> <type>text</type> or <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is row-level security active for the specified table in the context of
- the current user and current environment?
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-aclitem-op-table"/> shows the operators
- available for the <type>aclitem</type> type, which is the catalog
- representation of access privileges. See <xref linkend="ddl-priv"/>
- for information about how to read access privilege values.
- </para>
-
- <table id="functions-aclitem-op-table">
- <title><type>aclitem</type> Operators</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>aclitemeq</primary>
- </indexterm>
- <type>aclitem</type> <literal>=</literal> <type>aclitem</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Are <type>aclitem</type>s equal? (Notice that
- type <type>aclitem</type> lacks the usual set of comparison
- operators; it has only equality. In turn, <type>aclitem</type>
- arrays can only be compared for equality.)
- </para>
- <para>
- <literal>'calvin=r*w/hobbes'::aclitem = 'calvin=r*w*/hobbes'::aclitem</literal>
- <returnvalue>f</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>aclcontains</primary>
- </indexterm>
- <type>aclitem[]</type> <literal>@></literal> <type>aclitem</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does array contain the specified privileges? (This is true if there
- is an array entry that matches the <type>aclitem</type>'s grantee and
- grantor, and has at least the specified set of privileges.)
- </para>
- <para>
- <literal>'{calvin=r*w/hobbes,hobbes=r*w*/postgres}'::aclitem[] @> 'calvin=r*/hobbes'::aclitem</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>aclitem[]</type> <literal>~</literal> <type>aclitem</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- This is a deprecated alias for <literal>@></literal>.
- </para>
- <para>
- <literal>'{calvin=r*w/hobbes,hobbes=r*w*/postgres}'::aclitem[] ~ 'calvin=r*/hobbes'::aclitem</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-aclitem-fn-table"/> shows some additional
- functions to manage the <type>aclitem</type> type.
- </para>
-
- <table id="functions-aclitem-fn-table">
- <title><type>aclitem</type> Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>acldefault</primary>
- </indexterm>
- <function>acldefault</function> (
- <parameter>type</parameter> <type>"char"</type>,
- <parameter>ownerId</parameter> <type>oid</type> )
- <returnvalue>aclitem[]</returnvalue>
- </para>
- <para>
- Constructs an <type>aclitem</type> array holding the default access
- privileges for an object of type <parameter>type</parameter> belonging
- to the role with OID <parameter>ownerId</parameter>. This represents
- the access privileges that will be assumed when an object's ACL entry
- is null. (The default access privileges are described in
- <xref linkend="ddl-priv"/>.)
- The <parameter>type</parameter> parameter must be one of
- 'c' for <literal>COLUMN</literal>,
- 'r' for <literal>TABLE</literal> and table-like objects,
- 's' for <literal>SEQUENCE</literal>,
- 'd' for <literal>DATABASE</literal>,
- 'f' for <literal>FUNCTION</literal> or <literal>PROCEDURE</literal>,
- 'l' for <literal>LANGUAGE</literal>,
- 'L' for <literal>LARGE OBJECT</literal>,
- 'n' for <literal>SCHEMA</literal>,
- 'p' for <literal>PARAMETER</literal>,
- 't' for <literal>TABLESPACE</literal>,
- 'F' for <literal>FOREIGN DATA WRAPPER</literal>,
- 'S' for <literal>FOREIGN SERVER</literal>,
- or
- 'T' for <literal>TYPE</literal> or <literal>DOMAIN</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>aclexplode</primary>
- </indexterm>
- <function>aclexplode</function> ( <type>aclitem[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>grantor</parameter> <type>oid</type>,
- <parameter>grantee</parameter> <type>oid</type>,
- <parameter>privilege_type</parameter> <type>text</type>,
- <parameter>is_grantable</parameter> <type>boolean</type> )
- </para>
- <para>
- Returns the <type>aclitem</type> array as a set of rows.
- If the grantee is the pseudo-role PUBLIC, it is represented by zero in
- the <parameter>grantee</parameter> column. Each granted privilege is
- represented as <literal>SELECT</literal>, <literal>INSERT</literal>,
- etc (see <xref linkend="privilege-abbrevs-table"/> for a full list).
- Note that each privilege is broken out as a separate row, so
- only one keyword appears in the <parameter>privilege_type</parameter>
- column.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>makeaclitem</primary>
- </indexterm>
- <function>makeaclitem</function> (
- <parameter>grantee</parameter> <type>oid</type>,
- <parameter>grantor</parameter> <type>oid</type>,
- <parameter>privileges</parameter> <type>text</type>,
- <parameter>is_grantable</parameter> <type>boolean</type> )
- <returnvalue>aclitem</returnvalue>
- </para>
- <para>
- Constructs an <type>aclitem</type> with the given properties.
- <parameter>privileges</parameter> is a comma-separated list of
- privilege names such as <literal>SELECT</literal>,
- <literal>INSERT</literal>, etc, all of which are set in the
- result. (Case of the privilege string is not significant, and
- extra whitespace is allowed between but not within privilege
- names.)
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-schema">
- <title>Schema Visibility Inquiry Functions</title>
-
- <para>
- <xref linkend="functions-info-schema-table"/> shows functions that
- determine whether a certain object is <firstterm>visible</firstterm> in the
- current schema search path.
- For example, a table is said to be visible if its
- containing schema is in the search path and no table of the same
- name appears earlier in the search path. This is equivalent to the
- statement that the table can be referenced by name without explicit
- schema qualification. Thus, to list the names of all visible tables:
-<programlisting>
-SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
-</programlisting>
- For functions and operators, an object in the search path is said to be
- visible if there is no object of the same name <emphasis>and argument data
- type(s)</emphasis> earlier in the path. For operator classes and families,
- both the name and the associated index access method are considered.
- </para>
-
- <indexterm>
- <primary>search path</primary>
- <secondary>object visibility</secondary>
- </indexterm>
-
- <table id="functions-info-schema-table">
- <title>Schema Visibility Inquiry Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_collation_is_visible</primary>
- </indexterm>
- <function>pg_collation_is_visible</function> ( <parameter>collation</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is collation visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_conversion_is_visible</primary>
- </indexterm>
- <function>pg_conversion_is_visible</function> ( <parameter>conversion</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is conversion visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_function_is_visible</primary>
- </indexterm>
- <function>pg_function_is_visible</function> ( <parameter>function</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is function visible in search path?
- (This also works for procedures and aggregates.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_opclass_is_visible</primary>
- </indexterm>
- <function>pg_opclass_is_visible</function> ( <parameter>opclass</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is operator class visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_operator_is_visible</primary>
- </indexterm>
- <function>pg_operator_is_visible</function> ( <parameter>operator</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is operator visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_opfamily_is_visible</primary>
- </indexterm>
- <function>pg_opfamily_is_visible</function> ( <parameter>opclass</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is operator family visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_statistics_obj_is_visible</primary>
- </indexterm>
- <function>pg_statistics_obj_is_visible</function> ( <parameter>stat</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is statistics object visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_table_is_visible</primary>
- </indexterm>
- <function>pg_table_is_visible</function> ( <parameter>table</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is table visible in search path?
- (This works for all types of relations, including views, materialized
- views, indexes, sequences and foreign tables.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ts_config_is_visible</primary>
- </indexterm>
- <function>pg_ts_config_is_visible</function> ( <parameter>config</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is text search configuration visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ts_dict_is_visible</primary>
- </indexterm>
- <function>pg_ts_dict_is_visible</function> ( <parameter>dict</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is text search dictionary visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ts_parser_is_visible</primary>
- </indexterm>
- <function>pg_ts_parser_is_visible</function> ( <parameter>parser</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is text search parser visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ts_template_is_visible</primary>
- </indexterm>
- <function>pg_ts_template_is_visible</function> ( <parameter>template</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is text search template visible in search path?
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_type_is_visible</primary>
- </indexterm>
- <function>pg_type_is_visible</function> ( <parameter>type</parameter> <type>oid</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is type (or domain) visible in search path?
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- All these functions require object OIDs to identify the object to be
- checked. If you want to test an object by name, it is convenient to use
- the OID alias types (<type>regclass</type>, <type>regtype</type>,
- <type>regprocedure</type>, <type>regoperator</type>, <type>regconfig</type>,
- or <type>regdictionary</type>),
- for example:
-<programlisting>
-SELECT pg_type_is_visible('myschema.widget'::regtype);
-</programlisting>
- Note that it would not make much sense to test a non-schema-qualified
- type name in this way — if the name can be recognized at all, it must be visible.
- </para>
-
- </sect2>
-
- <sect2 id="functions-info-catalog">
- <title>System Catalog Information Functions</title>
-
- <para>
- <xref linkend="functions-info-catalog-table"/> lists functions that
- extract information from the system catalogs.
- </para>
-
- <table id="functions-info-catalog-table">
- <title>System Catalog Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry id="format-type" xreflabel="format_type" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>format_type</primary>
- </indexterm>
- <function>format_type</function> ( <parameter>type</parameter> <type>oid</type>, <parameter>typemod</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the SQL name for a data type that is identified by its type
- OID and possibly a type modifier. Pass NULL for the type modifier if
- no specific modifier is known.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_basetype</primary>
- </indexterm>
- <function>pg_basetype</function> ( <type>regtype</type> )
- <returnvalue>regtype</returnvalue>
- </para>
- <para>
- Returns the OID of the base type of a domain identified by its
- type OID. If the argument is the OID of a non-domain type,
- returns the argument as-is. Returns NULL if the argument is
- not a valid type OID. If there's a chain of domain dependencies,
- it will recurse until finding the base type.
- </para>
- <para>
- Assuming <literal>CREATE DOMAIN mytext AS text</literal>:
- </para>
- <para>
- <literal>pg_basetype('mytext'::regtype)</literal>
- <returnvalue>text</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-char-to-encoding" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_char_to_encoding</primary>
- </indexterm>
- <function>pg_char_to_encoding</function> ( <parameter>encoding</parameter> <type>name</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Converts the supplied encoding name into an integer representing the
- internal identifier used in some system catalog tables.
- Returns <literal>-1</literal> if an unknown encoding name is provided.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-encoding-to-char" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_encoding_to_char</primary>
- </indexterm>
- <function>pg_encoding_to_char</function> ( <parameter>encoding</parameter> <type>integer</type> )
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Converts the integer used as the internal identifier of an encoding in some
- system catalog tables into a human-readable string.
- Returns an empty string if an invalid encoding number is provided.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_catalog_foreign_keys</primary>
- </indexterm>
- <function>pg_get_catalog_foreign_keys</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>fktable</parameter> <type>regclass</type>,
- <parameter>fkcols</parameter> <type>text[]</type>,
- <parameter>pktable</parameter> <type>regclass</type>,
- <parameter>pkcols</parameter> <type>text[]</type>,
- <parameter>is_array</parameter> <type>boolean</type>,
- <parameter>is_opt</parameter> <type>boolean</type> )
- </para>
- <para>
- Returns a set of records describing the foreign key relationships
- that exist within the <productname>PostgreSQL</productname> system
- catalogs.
- The <parameter>fktable</parameter> column contains the name of the
- referencing catalog, and the <parameter>fkcols</parameter> column
- contains the name(s) of the referencing column(s). Similarly,
- the <parameter>pktable</parameter> column contains the name of the
- referenced catalog, and the <parameter>pkcols</parameter> column
- contains the name(s) of the referenced column(s).
- If <parameter>is_array</parameter> is true, the last referencing
- column is an array, each of whose elements should match some entry
- in the referenced catalog.
- If <parameter>is_opt</parameter> is true, the referencing column(s)
- are allowed to contain zeroes instead of a valid reference.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_constraintdef</primary>
- </indexterm>
- <function>pg_get_constraintdef</function> ( <parameter>constraint</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for a constraint.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_expr</primary>
- </indexterm>
- <function>pg_get_expr</function> ( <parameter>expr</parameter> <type>pg_node_tree</type>, <parameter>relation</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Decompiles the internal form of an expression stored in the system
- catalogs, such as the default value for a column. If the expression
- might contain Vars, specify the OID of the relation they refer to as
- the second parameter; if no Vars are expected, passing zero is
- sufficient.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_functiondef</primary>
- </indexterm>
- <function>pg_get_functiondef</function> ( <parameter>func</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for a function or procedure.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- The result is a complete <command>CREATE OR REPLACE FUNCTION</command>
- or <command>CREATE OR REPLACE PROCEDURE</command> statement.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_function_arguments</primary>
- </indexterm>
- <function>pg_get_function_arguments</function> ( <parameter>func</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the argument list of a function or procedure, in the form
- it would need to appear in within <command>CREATE FUNCTION</command>
- (including default values).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_function_identity_arguments</primary>
- </indexterm>
- <function>pg_get_function_identity_arguments</function> ( <parameter>func</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the argument list necessary to identify a function or
- procedure, in the form it would need to appear in within commands such
- as <command>ALTER FUNCTION</command>. This form omits default values.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_function_result</primary>
- </indexterm>
- <function>pg_get_function_result</function> ( <parameter>func</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the <literal>RETURNS</literal> clause of a function, in
- the form it would need to appear in within <command>CREATE
- FUNCTION</command>. Returns <literal>NULL</literal> for a procedure.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_indexdef</primary>
- </indexterm>
- <function>pg_get_indexdef</function> ( <parameter>index</parameter> <type>oid</type> <optional>, <parameter>column</parameter> <type>integer</type>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for an index.
- (This is a decompiled reconstruction, not the original text
- of the command.) If <parameter>column</parameter> is supplied and is
- not zero, only the definition of that column is reconstructed.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_keywords</primary>
- </indexterm>
- <function>pg_get_keywords</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>word</parameter> <type>text</type>,
- <parameter>catcode</parameter> <type>"char"</type>,
- <parameter>barelabel</parameter> <type>boolean</type>,
- <parameter>catdesc</parameter> <type>text</type>,
- <parameter>baredesc</parameter> <type>text</type> )
- </para>
- <para>
- Returns a set of records describing the SQL keywords recognized by the
- server. The <parameter>word</parameter> column contains the
- keyword. The <parameter>catcode</parameter> column contains a
- category code: <literal>U</literal> for an unreserved
- keyword, <literal>C</literal> for a keyword that can be a column
- name, <literal>T</literal> for a keyword that can be a type or
- function name, or <literal>R</literal> for a fully reserved keyword.
- The <parameter>barelabel</parameter> column
- contains <literal>true</literal> if the keyword can be used as
- a <quote>bare</quote> column label in <command>SELECT</command> lists,
- or <literal>false</literal> if it can only be used
- after <literal>AS</literal>.
- The <parameter>catdesc</parameter> column contains a
- possibly-localized string describing the keyword's category.
- The <parameter>baredesc</parameter> column contains a
- possibly-localized string describing the keyword's column label status.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_partkeydef</primary>
- </indexterm>
- <function>pg_get_partkeydef</function> ( <parameter>table</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the definition of a partitioned table's partition
- key, in the form it would have in the <literal>PARTITION
- BY</literal> clause of <command>CREATE TABLE</command>.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_ruledef</primary>
- </indexterm>
- <function>pg_get_ruledef</function> ( <parameter>rule</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for a rule.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_serial_sequence</primary>
- </indexterm>
- <function>pg_get_serial_sequence</function> ( <parameter>table</parameter> <type>text</type>, <parameter>column</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the name of the sequence associated with a column,
- or NULL if no sequence is associated with the column.
- If the column is an identity column, the associated sequence is the
- sequence internally created for that column.
- For columns created using one of the serial types
- (<type>serial</type>, <type>smallserial</type>, <type>bigserial</type>),
- it is the sequence created for that serial column definition.
- In the latter case, the association can be modified or removed
- with <command>ALTER SEQUENCE OWNED BY</command>.
- (This function probably should have been
- called <function>pg_get_owned_sequence</function>; its current name
- reflects the fact that it has historically been used with serial-type
- columns.) The first parameter is a table name with optional
- schema, and the second parameter is a column name. Because the first
- parameter potentially contains both schema and table names, it is
- parsed per usual SQL rules, meaning it is lower-cased by default.
- The second parameter, being just a column name, is treated literally
- and so has its case preserved. The result is suitably formatted
- for passing to the sequence functions (see
- <xref linkend="functions-sequence"/>).
- </para>
- <para>
- A typical use is in reading the current value of the sequence for an
- identity or serial column, for example:
-<programlisting>
-SELECT currval(pg_get_serial_sequence('sometable', 'id'));
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_statisticsobjdef</primary>
- </indexterm>
- <function>pg_get_statisticsobjdef</function> ( <parameter>statobj</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for an extended statistics object.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_triggerdef</primary>
- </indexterm>
-<function>pg_get_triggerdef</function> ( <parameter>trigger</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the creating command for a trigger.
- (This is a decompiled reconstruction, not the original text
- of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_userbyid</primary>
- </indexterm>
- <function>pg_get_userbyid</function> ( <parameter>role</parameter> <type>oid</type> )
- <returnvalue>name</returnvalue>
- </para>
- <para>
- Returns a role's name given its OID.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_viewdef</primary>
- </indexterm>
- <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>oid</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the underlying <command>SELECT</command> command for a
- view or materialized view. (This is a decompiled reconstruction, not
- the original text of the command.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>oid</type>, <parameter>wrap_column</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the underlying <command>SELECT</command> command for a
- view or materialized view. (This is a decompiled reconstruction, not
- the original text of the command.) In this form of the function,
- pretty-printing is always enabled, and long lines are wrapped to try
- to keep them shorter than the specified number of columns.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>pg_get_viewdef</function> ( <parameter>view</parameter> <type>text</type> <optional>, <parameter>pretty</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reconstructs the underlying <command>SELECT</command> command for a
- view or materialized view, working from a textual name for the view
- rather than its OID. (This is deprecated; use the OID variant
- instead.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_index_column_has_property</primary>
- </indexterm>
- <function>pg_index_column_has_property</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>column</parameter> <type>integer</type>, <parameter>property</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether an index column has the named property.
- Common index column properties are listed in
- <xref linkend="functions-info-index-column-props"/>.
- (Note that extension access methods can define additional property
- names for their indexes.)
- <literal>NULL</literal> is returned if the property name is not known
- or does not apply to the particular object, or if the OID or column
- number does not identify a valid object.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_index_has_property</primary>
- </indexterm>
- <function>pg_index_has_property</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>property</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether an index has the named property.
- Common index properties are listed in
- <xref linkend="functions-info-index-props"/>.
- (Note that extension access methods can define additional property
- names for their indexes.)
- <literal>NULL</literal> is returned if the property name is not known
- or does not apply to the particular object, or if the OID does not
- identify a valid object.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_indexam_has_property</primary>
- </indexterm>
- <function>pg_indexam_has_property</function> ( <parameter>am</parameter> <type>oid</type>, <parameter>property</parameter> <type>text</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether an index access method has the named property.
- Access method properties are listed in
- <xref linkend="functions-info-indexam-props"/>.
- <literal>NULL</literal> is returned if the property name is not known
- or does not apply to the particular object, or if the OID does not
- identify a valid object.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_options_to_table</primary>
- </indexterm>
- <function>pg_options_to_table</function> ( <parameter>options_array</parameter> <type>text[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>option_name</parameter> <type>text</type>,
- <parameter>option_value</parameter> <type>text</type> )
- </para>
- <para>
- Returns the set of storage options represented by a value from
- <structname>pg_class</structname>.<structfield>reloptions</structfield> or
- <structname>pg_attribute</structname>.<structfield>attoptions</structfield>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_settings_get_flags</primary>
- </indexterm>
- <function>pg_settings_get_flags</function> ( <parameter>guc</parameter> <type>text</type> )
- <returnvalue>text[]</returnvalue>
- </para>
- <para>
- Returns an array of the flags associated with the given GUC, or
- <literal>NULL</literal> if it does not exist. The result is
- an empty array if the GUC exists but there are no flags to show.
- Only the most useful flags listed in
- <xref linkend="functions-pg-settings-flags"/> are exposed.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_tablespace_databases</primary>
- </indexterm>
- <function>pg_tablespace_databases</function> ( <parameter>tablespace</parameter> <type>oid</type> )
- <returnvalue>setof oid</returnvalue>
- </para>
- <para>
- Returns the set of OIDs of databases that have objects stored in the
- specified tablespace. If this function returns any rows, the
- tablespace is not empty and cannot be dropped. To identify the specific
- objects populating the tablespace, you will need to connect to the
- database(s) identified by <function>pg_tablespace_databases</function>
- and query their <structname>pg_class</structname> catalogs.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_tablespace_location</primary>
- </indexterm>
- <function>pg_tablespace_location</function> ( <parameter>tablespace</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the file system path that this tablespace is located in.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_typeof</primary>
- </indexterm>
- <function>pg_typeof</function> ( <type>"any"</type> )
- <returnvalue>regtype</returnvalue>
- </para>
- <para>
- Returns the OID of the data type of the value that is passed to it.
- This can be helpful for troubleshooting or dynamically constructing
- SQL queries. The function is declared as
- returning <type>regtype</type>, which is an OID alias type (see
- <xref linkend="datatype-oid"/>); this means that it is the same as an
- OID for comparison purposes but displays as a type name.
- </para>
- <para>
- <literal>pg_typeof(33)</literal>
- <returnvalue>integer</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>COLLATION FOR</primary>
- </indexterm>
- <function>COLLATION FOR</function> ( <type>"any"</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the name of the collation of the value that is passed to it.
- The value is quoted and schema-qualified if necessary. If no
- collation was derived for the argument expression,
- then <literal>NULL</literal> is returned. If the argument is not of a
- collatable data type, then an error is raised.
- </para>
- <para>
- <literal>collation for ('foo'::text)</literal>
- <returnvalue>"default"</returnvalue>
- </para>
- <para>
- <literal>collation for ('foo' COLLATE "de_DE")</literal>
- <returnvalue>"de_DE"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regclass</primary>
- </indexterm>
- <function>to_regclass</function> ( <type>text</type> )
- <returnvalue>regclass</returnvalue>
- </para>
- <para>
- Translates a textual relation name to its OID. A similar result is
- obtained by casting the string to type <type>regclass</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regcollation</primary>
- </indexterm>
- <function>to_regcollation</function> ( <type>text</type> )
- <returnvalue>regcollation</returnvalue>
- </para>
- <para>
- Translates a textual collation name to its OID. A similar result is
- obtained by casting the string to type <type>regcollation</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regnamespace</primary>
- </indexterm>
- <function>to_regnamespace</function> ( <type>text</type> )
- <returnvalue>regnamespace</returnvalue>
- </para>
- <para>
- Translates a textual schema name to its OID. A similar result is
- obtained by casting the string to type <type>regnamespace</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regoper</primary>
- </indexterm>
- <function>to_regoper</function> ( <type>text</type> )
- <returnvalue>regoper</returnvalue>
- </para>
- <para>
- Translates a textual operator name to its OID. A similar result is
- obtained by casting the string to type <type>regoper</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found or is ambiguous.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regoperator</primary>
- </indexterm>
- <function>to_regoperator</function> ( <type>text</type> )
- <returnvalue>regoperator</returnvalue>
- </para>
- <para>
- Translates a textual operator name (with parameter types) to its OID. A similar result is
- obtained by casting the string to type <type>regoperator</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regproc</primary>
- </indexterm>
- <function>to_regproc</function> ( <type>text</type> )
- <returnvalue>regproc</returnvalue>
- </para>
- <para>
- Translates a textual function or procedure name to its OID. A similar result is
- obtained by casting the string to type <type>regproc</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found or is ambiguous.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regprocedure</primary>
- </indexterm>
- <function>to_regprocedure</function> ( <type>text</type> )
- <returnvalue>regprocedure</returnvalue>
- </para>
- <para>
- Translates a textual function or procedure name (with argument types) to its OID. A similar result is
- obtained by casting the string to type <type>regprocedure</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regrole</primary>
- </indexterm>
- <function>to_regrole</function> ( <type>text</type> )
- <returnvalue>regrole</returnvalue>
- </para>
- <para>
- Translates a textual role name to its OID. A similar result is
- obtained by casting the string to type <type>regrole</type> (see
- <xref linkend="datatype-oid"/>); however, this function will return
- <literal>NULL</literal> rather than throwing an error if the name is
- not found.
- </para></entry>
- </row>
-
- <row>
- <entry id="to-regtype" xreflabel="to_regtype" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regtype</primary>
- </indexterm>
- <function>to_regtype</function> ( <type>text</type> )
- <returnvalue>regtype</returnvalue>
- </para>
- <para>
- Parses a string of text, extracts a potential type name from it,
- and translates that name into a type OID. A syntax error in the
- string will result in an error; but if the string is a
- syntactically valid type name that happens not to be found in the
- catalogs, the result is <literal>NULL</literal>. A similar result
- is obtained by casting the string to type <type>regtype</type>
- (see <xref linkend="datatype-oid"/>), except that that will throw
- error for name not found.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_regtypemod</primary>
- </indexterm>
- <function>to_regtypemod</function> ( <type>text</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Parses a string of text, extracts a potential type name from it,
- and translates its type modifier, if any. A syntax error in the
- string will result in an error; but if the string is a
- syntactically valid type name that happens not to be found in the
- catalogs, the result is <literal>NULL</literal>. The result is
- <literal>-1</literal> if no type modifier is present.
- </para>
- <para>
- <function>to_regtypemod</function> can be combined with
- <xref linkend="to-regtype"/> to produce appropriate inputs for
- <xref linkend="format-type"/>, allowing a string representing a
- type name to be canonicalized.
- </para>
- <para>
- <literal>format_type(to_regtype('varchar(32)'), to_regtypemod('varchar(32)'))</literal>
- <returnvalue>character varying(32)</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Most of the functions that reconstruct (decompile) database objects
- have an optional <parameter>pretty</parameter> flag, which
- if <literal>true</literal> causes the result to
- be <quote>pretty-printed</quote>. Pretty-printing suppresses unnecessary
- parentheses and adds whitespace for legibility.
- The pretty-printed format is more readable, but the default format
- is more likely to be interpreted the same way by future versions of
- <productname>PostgreSQL</productname>; so avoid using pretty-printed output
- for dump purposes. Passing <literal>false</literal> for
- the <parameter>pretty</parameter> parameter yields the same result as
- omitting the parameter.
- </para>
-
- <table id="functions-info-index-column-props">
- <title>Index Column Properties</title>
- <tgroup cols="2">
- <thead>
- <row><entry>Name</entry><entry>Description</entry></row>
- </thead>
- <tbody>
- <row>
- <entry><literal>asc</literal></entry>
- <entry>Does the column sort in ascending order on a forward scan?
- </entry>
- </row>
- <row>
- <entry><literal>desc</literal></entry>
- <entry>Does the column sort in descending order on a forward scan?
- </entry>
- </row>
- <row>
- <entry><literal>nulls_first</literal></entry>
- <entry>Does the column sort with nulls first on a forward scan?
- </entry>
- </row>
- <row>
- <entry><literal>nulls_last</literal></entry>
- <entry>Does the column sort with nulls last on a forward scan?
- </entry>
- </row>
- <row>
- <entry><literal>orderable</literal></entry>
- <entry>Does the column possess any defined sort ordering?
- </entry>
- </row>
- <row>
- <entry><literal>distance_orderable</literal></entry>
- <entry>Can the column be scanned in order by a <quote>distance</quote>
- operator, for example <literal>ORDER BY col <-> constant</literal> ?
- </entry>
- </row>
- <row>
- <entry><literal>returnable</literal></entry>
- <entry>Can the column value be returned by an index-only scan?
- </entry>
- </row>
- <row>
- <entry><literal>search_array</literal></entry>
- <entry>Does the column natively support <literal>col = ANY(array)</literal>
- searches?
- </entry>
- </row>
- <row>
- <entry><literal>search_nulls</literal></entry>
- <entry>Does the column support <literal>IS NULL</literal> and
- <literal>IS NOT NULL</literal> searches?
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-info-index-props">
- <title>Index Properties</title>
- <tgroup cols="2">
- <thead>
- <row><entry>Name</entry><entry>Description</entry></row>
- </thead>
- <tbody>
- <row>
- <entry><literal>clusterable</literal></entry>
- <entry>Can the index be used in a <literal>CLUSTER</literal> command?
- </entry>
- </row>
- <row>
- <entry><literal>index_scan</literal></entry>
- <entry>Does the index support plain (non-bitmap) scans?
- </entry>
- </row>
- <row>
- <entry><literal>bitmap_scan</literal></entry>
- <entry>Does the index support bitmap scans?
- </entry>
- </row>
- <row>
- <entry><literal>backward_scan</literal></entry>
- <entry>Can the scan direction be changed in mid-scan (to
- support <literal>FETCH BACKWARD</literal> on a cursor without
- needing materialization)?
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-info-indexam-props">
- <title>Index Access Method Properties</title>
- <tgroup cols="2">
- <thead>
- <row><entry>Name</entry><entry>Description</entry></row>
- </thead>
- <tbody>
- <row>
- <entry><literal>can_order</literal></entry>
- <entry>Does the access method support <literal>ASC</literal>,
- <literal>DESC</literal> and related keywords in
- <literal>CREATE INDEX</literal>?
- </entry>
- </row>
- <row>
- <entry><literal>can_unique</literal></entry>
- <entry>Does the access method support unique indexes?
- </entry>
- </row>
- <row>
- <entry><literal>can_multi_col</literal></entry>
- <entry>Does the access method support indexes with multiple columns?
- </entry>
- </row>
- <row>
- <entry><literal>can_exclude</literal></entry>
- <entry>Does the access method support exclusion constraints?
- </entry>
- </row>
- <row>
- <entry><literal>can_include</literal></entry>
- <entry>Does the access method support the <literal>INCLUDE</literal>
- clause of <literal>CREATE INDEX</literal>?
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-pg-settings-flags">
- <title>GUC Flags</title>
- <tgroup cols="2">
- <thead>
- <row><entry>Flag</entry><entry>Description</entry></row>
- </thead>
- <tbody>
- <row>
- <entry><literal>EXPLAIN</literal></entry>
- <entry>Parameters with this flag are included in
- <command>EXPLAIN (SETTINGS)</command> commands.
- </entry>
- </row>
- <row>
- <entry><literal>NO_SHOW_ALL</literal></entry>
- <entry>Parameters with this flag are excluded from
- <command>SHOW ALL</command> commands.
- </entry>
- </row>
- <row>
- <entry><literal>NO_RESET</literal></entry>
- <entry>Parameters with this flag do not support
- <command>RESET</command> commands.
- </entry>
- </row>
- <row>
- <entry><literal>NO_RESET_ALL</literal></entry>
- <entry>Parameters with this flag are excluded from
- <command>RESET ALL</command> commands.
- </entry>
- </row>
- <row>
- <entry><literal>NOT_IN_SAMPLE</literal></entry>
- <entry>Parameters with this flag are not included in
- <filename>postgresql.conf</filename> by default.
- </entry>
- </row>
- <row>
- <entry><literal>RUNTIME_COMPUTED</literal></entry>
- <entry>Parameters with this flag are runtime-computed ones.
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-object">
- <title>Object Information and Addressing Functions</title>
-
- <para>
- <xref linkend="functions-info-object-table"/> lists functions related to
- database object identification and addressing.
- </para>
-
- <table id="functions-info-object-table">
- <title>Object Information and Addressing Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_describe_object</primary>
- </indexterm>
- <function>pg_describe_object</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns a textual description of a database object identified by
- catalog OID, object OID, and sub-object ID (such as a column number
- within a table; the sub-object ID is zero when referring to a whole
- object). This description is intended to be human-readable, and might
- be translated, depending on server configuration. This is especially
- useful to determine the identity of an object referenced in the
- <structname>pg_depend</structname> catalog. This function returns
- <literal>NULL</literal> values for undefined objects.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_identify_object</primary>
- </indexterm>
- <function>pg_identify_object</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>type</parameter> <type>text</type>,
- <parameter>schema</parameter> <type>text</type>,
- <parameter>name</parameter> <type>text</type>,
- <parameter>identity</parameter> <type>text</type> )
- </para>
- <para>
- Returns a row containing enough information to uniquely identify the
- database object specified by catalog OID, object OID and sub-object
- ID.
- This information is intended to be machine-readable, and is never
- translated.
- <parameter>type</parameter> identifies the type of database object;
- <parameter>schema</parameter> is the schema name that the object
- belongs in, or <literal>NULL</literal> for object types that do not
- belong to schemas;
- <parameter>name</parameter> is the name of the object, quoted if
- necessary, if the name (along with schema name, if pertinent) is
- sufficient to uniquely identify the object,
- otherwise <literal>NULL</literal>;
- <parameter>identity</parameter> is the complete object identity, with
- the precise format depending on object type, and each name within the
- format being schema-qualified and quoted as necessary. Undefined
- objects are identified with <literal>NULL</literal> values.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_identify_object_as_address</primary>
- </indexterm>
- <function>pg_identify_object_as_address</function> ( <parameter>classid</parameter> <type>oid</type>, <parameter>objid</parameter> <type>oid</type>, <parameter>objsubid</parameter> <type>integer</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>type</parameter> <type>text</type>,
- <parameter>object_names</parameter> <type>text[]</type>,
- <parameter>object_args</parameter> <type>text[]</type> )
- </para>
- <para>
- Returns a row containing enough information to uniquely identify the
- database object specified by catalog OID, object OID and sub-object
- ID.
- The returned information is independent of the current server, that
- is, it could be used to identify an identically named object in
- another server.
- <parameter>type</parameter> identifies the type of database object;
- <parameter>object_names</parameter> and
- <parameter>object_args</parameter>
- are text arrays that together form a reference to the object.
- These three values can be passed
- to <function>pg_get_object_address</function> to obtain the internal
- address of the object.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_object_address</primary>
- </indexterm>
- <function>pg_get_object_address</function> ( <parameter>type</parameter> <type>text</type>, <parameter>object_names</parameter> <type>text[]</type>, <parameter>object_args</parameter> <type>text[]</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>classid</parameter> <type>oid</type>,
- <parameter>objid</parameter> <type>oid</type>,
- <parameter>objsubid</parameter> <type>integer</type> )
- </para>
- <para>
- Returns a row containing enough information to uniquely identify the
- database object specified by a type code and object name and argument
- arrays.
- The returned values are the ones that would be used in system catalogs
- such as <structname>pg_depend</structname>; they can be passed to
- other system functions such as <function>pg_describe_object</function>
- or <function>pg_identify_object</function>.
- <parameter>classid</parameter> is the OID of the system catalog
- containing the object;
- <parameter>objid</parameter> is the OID of the object itself, and
- <parameter>objsubid</parameter> is the sub-object ID, or zero if none.
- This function is the inverse
- of <function>pg_identify_object_as_address</function>.
- Undefined objects are identified with <literal>NULL</literal> values.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-comment">
- <title>Comment Information Functions</title>
-
- <indexterm>
- <primary>comment</primary>
- <secondary sortas="database objects">about database objects</secondary>
- </indexterm>
-
- <para>
- The functions shown in <xref linkend="functions-info-comment-table"/>
- extract comments previously stored with the <xref linkend="sql-comment"/>
- command. A null value is returned if no
- comment could be found for the specified parameters.
- </para>
-
- <table id="functions-info-comment-table">
- <title>Comment Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>col_description</primary>
- </indexterm>
- <function>col_description</function> ( <parameter>table</parameter> <type>oid</type>, <parameter>column</parameter> <type>integer</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the comment for a table column, which is specified by the OID
- of its table and its column number.
- (<function>obj_description</function> cannot be used for table
- columns, since columns do not have OIDs of their own.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>obj_description</primary>
- </indexterm>
- <function>obj_description</function> ( <parameter>object</parameter> <type>oid</type>, <parameter>catalog</parameter> <type>name</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the comment for a database object specified by its OID and the
- name of the containing system catalog. For
- example, <literal>obj_description(123456, 'pg_class')</literal> would
- retrieve the comment for the table with OID 123456.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>obj_description</function> ( <parameter>object</parameter> <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the comment for a database object specified by its OID alone.
- This is <emphasis>deprecated</emphasis> since there is no guarantee
- that OIDs are unique across different system catalogs; therefore, the
- wrong comment might be returned.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>shobj_description</primary>
- </indexterm>
- <function>shobj_description</function> ( <parameter>object</parameter> <type>oid</type>, <parameter>catalog</parameter> <type>name</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the comment for a shared database object specified by its OID
- and the name of the containing system catalog. This is just
- like <function>obj_description</function> except that it is used for
- retrieving comments on shared objects (that is, databases, roles, and
- tablespaces). Some system catalogs are global to all databases within
- each cluster, and the descriptions for objects in them are stored
- globally as well.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-validity">
- <title>Data Validity Checking Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-info-validity-table"/>
- can be helpful for checking validity of proposed input data.
- </para>
-
- <table id="functions-info-validity-table">
- <title>Data Validity Checking Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_input_is_valid</primary>
- </indexterm>
- <function>pg_input_is_valid</function> (
- <parameter>string</parameter> <type>text</type>,
- <parameter>type</parameter> <type>text</type>
- )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether the given <parameter>string</parameter> is valid
- input for the specified data type, returning true or false.
- </para>
- <para>
- This function will only work as desired if the data type's input
- function has been updated to report invalid input as
- a <quote>soft</quote> error. Otherwise, invalid input will abort
- the transaction, just as if the string had been cast to the type
- directly.
- </para>
- <para>
- <literal>pg_input_is_valid('42', 'integer')</literal>
- <returnvalue>t</returnvalue>
- </para>
- <para>
- <literal>pg_input_is_valid('42000000000', 'integer')</literal>
- <returnvalue>f</returnvalue>
- </para>
- <para>
- <literal>pg_input_is_valid('1234.567', 'numeric(7,4)')</literal>
- <returnvalue>f</returnvalue>
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_input_error_info</primary>
- </indexterm>
- <function>pg_input_error_info</function> (
- <parameter>string</parameter> <type>text</type>,
- <parameter>type</parameter> <type>text</type>
- )
- <returnvalue>record</returnvalue>
- ( <parameter>message</parameter> <type>text</type>,
- <parameter>detail</parameter> <type>text</type>,
- <parameter>hint</parameter> <type>text</type>,
- <parameter>sql_error_code</parameter> <type>text</type> )
- </para>
- <para>
- Tests whether the given <parameter>string</parameter> is valid
- input for the specified data type; if not, return the details of
- the error that would have been thrown. If the input is valid, the
- results are NULL. The inputs are the same as
- for <function>pg_input_is_valid</function>.
- </para>
- <para>
- This function will only work as desired if the data type's input
- function has been updated to report invalid input as
- a <quote>soft</quote> error. Otherwise, invalid input will abort
- the transaction, just as if the string had been cast to the type
- directly.
- </para>
- <para>
- <literal>select * from pg_input_error_info('42000000000', 'integer')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- message | detail | hint | sql_error_code
-------------------------------------------------------+--------+------+----------------
- value "42000000000" is out of range for type integer | | | 22003
-</programlisting>
- </para>
- <para>
- <literal>select message, detail from pg_input_error_info('1234.567', 'numeric(7,4)')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- message | detail
-------------------------+----------------------------------&zwsp;-------------------------------------------------
- numeric field overflow | A field with precision 7, scale 4 must round to an absolute value less than 10^3.
-</programlisting>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-snapshot">
- <title>Transaction ID and Snapshot Information Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-pg-snapshot"/>
- provide server transaction information in an exportable form. The main
- use of these functions is to determine which transactions were committed
- between two snapshots.
- </para>
-
- <table id="functions-pg-snapshot">
- <title>Transaction ID and Snapshot Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_xact_id</primary>
- </indexterm>
- <function>pg_current_xact_id</function> ()
- <returnvalue>xid8</returnvalue>
- </para>
- <para>
- Returns the current transaction's ID. It will assign a new one if the
- current transaction does not have one already (because it has not
- performed any database updates); see <xref
- linkend="transaction-id"/> for details. If executed in a
- subtransaction, this will return the top-level transaction ID;
- see <xref linkend="subxacts"/> for details.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_xact_id_if_assigned</primary>
- </indexterm>
- <function>pg_current_xact_id_if_assigned</function> ()
- <returnvalue>xid8</returnvalue>
- </para>
- <para>
- Returns the current transaction's ID, or <literal>NULL</literal> if no
- ID is assigned yet. (It's best to use this variant if the transaction
- might otherwise be read-only, to avoid unnecessary consumption of an
- XID.)
- If executed in a subtransaction, this will return the top-level
- transaction ID.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_xact_status</primary>
- </indexterm>
- <function>pg_xact_status</function> ( <type>xid8</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Reports the commit status of a recent transaction.
- The result is one of <literal>in progress</literal>,
- <literal>committed</literal>, or <literal>aborted</literal>,
- provided that the transaction is recent enough that the system retains
- the commit status of that transaction.
- If it is old enough that no references to the transaction survive in
- the system and the commit status information has been discarded, the
- result is <literal>NULL</literal>.
- Applications might use this function, for example, to determine
- whether their transaction committed or aborted after the application
- and database server become disconnected while
- a <literal>COMMIT</literal> is in progress.
- Note that prepared transactions are reported as <literal>in
- progress</literal>; applications must check <link
- linkend="view-pg-prepared-xacts"><structname>pg_prepared_xacts</structname></link>
- if they need to determine whether a transaction ID belongs to a
- prepared transaction.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_snapshot</primary>
- </indexterm>
- <function>pg_current_snapshot</function> ()
- <returnvalue>pg_snapshot</returnvalue>
- </para>
- <para>
- Returns a current <firstterm>snapshot</firstterm>, a data structure
- showing which transaction IDs are now in-progress.
- Only top-level transaction IDs are included in the snapshot;
- subtransaction IDs are not shown; see <xref linkend="subxacts"/>
- for details.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_snapshot_xip</primary>
- </indexterm>
- <function>pg_snapshot_xip</function> ( <type>pg_snapshot</type> )
- <returnvalue>setof xid8</returnvalue>
- </para>
- <para>
- Returns the set of in-progress transaction IDs contained in a snapshot.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_snapshot_xmax</primary>
- </indexterm>
- <function>pg_snapshot_xmax</function> ( <type>pg_snapshot</type> )
- <returnvalue>xid8</returnvalue>
- </para>
- <para>
- Returns the <structfield>xmax</structfield> of a snapshot.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_snapshot_xmin</primary>
- </indexterm>
- <function>pg_snapshot_xmin</function> ( <type>pg_snapshot</type> )
- <returnvalue>xid8</returnvalue>
- </para>
- <para>
- Returns the <structfield>xmin</structfield> of a snapshot.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_visible_in_snapshot</primary>
- </indexterm>
- <function>pg_visible_in_snapshot</function> ( <type>xid8</type>, <type>pg_snapshot</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is the given transaction ID <firstterm>visible</firstterm> according
- to this snapshot (that is, was it completed before the snapshot was
- taken)? Note that this function will not give the correct answer for
- a subtransaction ID (subxid); see <xref linkend="subxacts"/> for
- details.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The internal transaction ID type <type>xid</type> is 32 bits wide and
- wraps around every 4 billion transactions. However,
- the functions shown in <xref linkend="functions-pg-snapshot"/> use a
- 64-bit type <type>xid8</type> that does not wrap around during the life
- of an installation and can be converted to <type>xid</type> by casting if
- required; see <xref linkend="transaction-id"/> for details.
- The data type <type>pg_snapshot</type> stores information about
- transaction ID visibility at a particular moment in time. Its components
- are described in <xref linkend="functions-pg-snapshot-parts"/>.
- <type>pg_snapshot</type>'s textual representation is
- <literal><replaceable>xmin</replaceable>:<replaceable>xmax</replaceable>:<replaceable>xip_list</replaceable></literal>.
- For example <literal>10:20:10,14,15</literal> means
- <literal>xmin=10, xmax=20, xip_list=10, 14, 15</literal>.
- </para>
-
- <table id="functions-pg-snapshot-parts">
- <title>Snapshot Components</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Name</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><structfield>xmin</structfield></entry>
- <entry>
- Lowest transaction ID that was still active. All transaction IDs
- less than <structfield>xmin</structfield> are either committed and visible,
- or rolled back and dead.
- </entry>
- </row>
-
- <row>
- <entry><structfield>xmax</structfield></entry>
- <entry>
- One past the highest completed transaction ID. All transaction IDs
- greater than or equal to <structfield>xmax</structfield> had not yet
- completed as of the time of the snapshot, and thus are invisible.
- </entry>
- </row>
-
- <row>
- <entry><structfield>xip_list</structfield></entry>
- <entry>
- Transactions in progress at the time of the snapshot. A transaction
- ID that is <literal>xmin <= <replaceable>X</replaceable> <
- xmax</literal> and not in this list was already completed at the time
- of the snapshot, and thus is either visible or dead according to its
- commit status. This list does not include the transaction IDs of
- subtransactions (subxids).
- </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- In releases of <productname>PostgreSQL</productname> before 13 there was
- no <type>xid8</type> type, so variants of these functions were provided
- that used <type>bigint</type> to represent a 64-bit XID, with a
- correspondingly distinct snapshot data type <type>txid_snapshot</type>.
- These older functions have <literal>txid</literal> in their names. They
- are still supported for backward compatibility, but may be removed from a
- future release. See <xref linkend="functions-txid-snapshot"/>.
- </para>
-
- <table id="functions-txid-snapshot">
- <title>Deprecated Transaction ID and Snapshot Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>age</primary>
- </indexterm>
- <function>age</function> ( <type>xid</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the number of transactions between the supplied
- transaction id and the current transaction counter.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>mxid_age</primary>
- </indexterm>
- <function>mxid_age</function> ( <type>xid</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the number of multixacts IDs between the supplied
- multixact ID and the current multixacts counter.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_current</primary>
- </indexterm>
- <function>txid_current</function> ()
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- See <function>pg_current_xact_id()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_current_if_assigned</primary>
- </indexterm>
- <function>txid_current_if_assigned</function> ()
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- See <function>pg_current_xact_id_if_assigned()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_current_snapshot</primary>
- </indexterm>
- <function>txid_current_snapshot</function> ()
- <returnvalue>txid_snapshot</returnvalue>
- </para>
- <para>
- See <function>pg_current_snapshot()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_snapshot_xip</primary>
- </indexterm>
- <function>txid_snapshot_xip</function> ( <type>txid_snapshot</type> )
- <returnvalue>setof bigint</returnvalue>
- </para>
- <para>
- See <function>pg_snapshot_xip()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_snapshot_xmax</primary>
- </indexterm>
- <function>txid_snapshot_xmax</function> ( <type>txid_snapshot</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- See <function>pg_snapshot_xmax()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_snapshot_xmin</primary>
- </indexterm>
- <function>txid_snapshot_xmin</function> ( <type>txid_snapshot</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- See <function>pg_snapshot_xmin()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_visible_in_snapshot</primary>
- </indexterm>
- <function>txid_visible_in_snapshot</function> ( <type>bigint</type>, <type>txid_snapshot</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- See <function>pg_visible_in_snapshot()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>txid_status</primary>
- </indexterm>
- <function>txid_status</function> ( <type>bigint</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- See <function>pg_xact_status()</function>.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-commit-timestamp">
- <title>Committed Transaction Information Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-commit-timestamp"/>
- provide information about when past transactions were committed.
- They only provide useful data when the
- <xref linkend="guc-track-commit-timestamp"/> configuration option is
- enabled, and only for transactions that were committed after it was
- enabled. Commit timestamp information is routinely removed during
- vacuum.
- </para>
-
- <table id="functions-commit-timestamp">
- <title>Committed Transaction Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_xact_commit_timestamp</primary>
- </indexterm>
- <function>pg_xact_commit_timestamp</function> ( <type>xid</type> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Returns the commit timestamp of a transaction.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_xact_commit_timestamp_origin</primary>
- </indexterm>
- <function>pg_xact_commit_timestamp_origin</function> ( <type>xid</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>timestamp</parameter> <type>timestamp with time zone</type>,
- <parameter>roident</parameter> <type>oid</type>)
- </para>
- <para>
- Returns the commit timestamp and replication origin of a transaction.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_last_committed_xact</primary>
- </indexterm>
- <function>pg_last_committed_xact</function> ()
- <returnvalue>record</returnvalue>
- ( <parameter>xid</parameter> <type>xid</type>,
- <parameter>timestamp</parameter> <type>timestamp with time zone</type>,
- <parameter>roident</parameter> <type>oid</type> )
- </para>
- <para>
- Returns the transaction ID, commit timestamp and replication origin
- of the latest committed transaction.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-controldata">
- <title>Control Data Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-controldata"/>
- print information initialized during <command>initdb</command>, such
- as the catalog version. They also show information about write-ahead
- logging and checkpoint processing. This information is cluster-wide,
- not specific to any one database. These functions provide most of the same
- information, from the same source, as the
- <xref linkend="app-pgcontroldata"/> application.
- </para>
-
- <table id="functions-controldata">
- <title>Control Data Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_control_checkpoint</primary>
- </indexterm>
- <function>pg_control_checkpoint</function> ()
- <returnvalue>record</returnvalue>
- </para>
- <para>
- Returns information about current checkpoint state, as shown in
- <xref linkend="functions-pg-control-checkpoint"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_control_system</primary>
- </indexterm>
- <function>pg_control_system</function> ()
- <returnvalue>record</returnvalue>
- </para>
- <para>
- Returns information about current control file state, as shown in
- <xref linkend="functions-pg-control-system"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_control_init</primary>
- </indexterm>
- <function>pg_control_init</function> ()
- <returnvalue>record</returnvalue>
- </para>
- <para>
- Returns information about cluster initialization state, as shown in
- <xref linkend="functions-pg-control-init"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_control_recovery</primary>
- </indexterm>
- <function>pg_control_recovery</function> ()
- <returnvalue>record</returnvalue>
- </para>
- <para>
- Returns information about recovery state, as shown in
- <xref linkend="functions-pg-control-recovery"/>.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-pg-control-checkpoint">
- <title><function>pg_control_checkpoint</function> Output Columns</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Column Name</entry>
- <entry>Data Type</entry>
- </row>
- </thead>
-
- <tbody>
-
- <row>
- <entry><structfield>checkpoint_lsn</structfield></entry>
- <entry><type>pg_lsn</type></entry>
- </row>
-
- <row>
- <entry><structfield>redo_lsn</structfield></entry>
- <entry><type>pg_lsn</type></entry>
- </row>
-
- <row>
- <entry><structfield>redo_wal_file</structfield></entry>
- <entry><type>text</type></entry>
- </row>
-
- <row>
- <entry><structfield>timeline_id</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>prev_timeline_id</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>full_page_writes</structfield></entry>
- <entry><type>boolean</type></entry>
- </row>
-
- <row>
- <entry><structfield>next_xid</structfield></entry>
- <entry><type>text</type></entry>
- </row>
-
- <row>
- <entry><structfield>next_oid</structfield></entry>
- <entry><type>oid</type></entry>
- </row>
-
- <row>
- <entry><structfield>next_multixact_id</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>next_multi_offset</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_xid</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_xid_dbid</structfield></entry>
- <entry><type>oid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_active_xid</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_multi_xid</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_multi_dbid</structfield></entry>
- <entry><type>oid</type></entry>
- </row>
-
- <row>
- <entry><structfield>oldest_commit_ts_xid</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>newest_commit_ts_xid</structfield></entry>
- <entry><type>xid</type></entry>
- </row>
-
- <row>
- <entry><structfield>checkpoint_time</structfield></entry>
- <entry><type>timestamp with time zone</type></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-pg-control-system">
- <title><function>pg_control_system</function> Output Columns</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Column Name</entry>
- <entry>Data Type</entry>
- </row>
- </thead>
-
- <tbody>
-
- <row>
- <entry><structfield>pg_control_version</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>catalog_version_no</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>system_identifier</structfield></entry>
- <entry><type>bigint</type></entry>
- </row>
-
- <row>
- <entry><structfield>pg_control_last_modified</structfield></entry>
- <entry><type>timestamp with time zone</type></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-pg-control-init">
- <title><function>pg_control_init</function> Output Columns</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Column Name</entry>
- <entry>Data Type</entry>
- </row>
- </thead>
-
- <tbody>
-
- <row>
- <entry><structfield>max_data_alignment</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>database_block_size</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>blocks_per_segment</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>wal_block_size</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>bytes_per_wal_segment</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>max_identifier_length</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>max_index_columns</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>max_toast_chunk_size</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>large_object_chunk_size</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>float8_pass_by_value</structfield></entry>
- <entry><type>boolean</type></entry>
- </row>
-
- <row>
- <entry><structfield>data_page_checksum_version</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-pg-control-recovery">
- <title><function>pg_control_recovery</function> Output Columns</title>
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Column Name</entry>
- <entry>Data Type</entry>
- </row>
- </thead>
-
- <tbody>
-
- <row>
- <entry><structfield>min_recovery_end_lsn</structfield></entry>
- <entry><type>pg_lsn</type></entry>
- </row>
-
- <row>
- <entry><structfield>min_recovery_end_timeline</structfield></entry>
- <entry><type>integer</type></entry>
- </row>
-
- <row>
- <entry><structfield>backup_start_lsn</structfield></entry>
- <entry><type>pg_lsn</type></entry>
- </row>
-
- <row>
- <entry><structfield>backup_end_lsn</structfield></entry>
- <entry><type>pg_lsn</type></entry>
- </row>
-
- <row>
- <entry><structfield>end_of_backup_record_required</structfield></entry>
- <entry><type>boolean</type></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-version">
- <title>Version Information Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-version"/>
- print version information.
- </para>
-
- <table id="functions-version">
- <title>Version Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>version</primary>
- </indexterm>
- <function>version</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns a string describing the <productname>PostgreSQL</productname>
- server's version. You can also get this information from
- <xref linkend="guc-server-version"/>, or for a machine-readable
- version use <xref linkend="guc-server-version-num"/>. Software
- developers should use <varname>server_version_num</varname> (available
- since 8.2) or <xref linkend="libpq-PQserverVersion"/> instead of
- parsing the text version.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>unicode_version</primary>
- </indexterm>
- <function>unicode_version</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns a string representing the version of Unicode used by
- <productname>PostgreSQL</productname>.
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>icu_unicode_version</primary>
- </indexterm>
- <function>icu_unicode_version</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns a string representing the version of Unicode used by ICU, if
- the server was built with ICU support; otherwise returns
- <literal>NULL</literal> </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-info-wal-summary">
- <title>WAL Summarization Information Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-wal-summary"/>
- print information about the status of WAL summarization.
- See <xref linkend="guc-summarize-wal" />.
- </para>
-
- <table id="functions-wal-summary">
- <title>WAL Summarization Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_available_wal_summaries</primary>
- </indexterm>
- <function>pg_available_wal_summaries</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>tli</parameter> <type>bigint</type>,
- <parameter>start_lsn</parameter> <type>pg_lsn</type>,
- <parameter>end_lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Returns information about the WAL summary files present in the
- data directory, under <literal>pg_wal/summaries</literal>.
- One row will be returned per WAL summary file. Each file summarizes
- WAL on the indicated TLI within the indicated LSN range. This function
- might be useful to determine whether enough WAL summaries are present
- on the server to take an incremental backup based on some prior
- backup whose start LSN is known.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_wal_summary_contents</primary>
- </indexterm>
- <function>pg_wal_summary_contents</function> ( <parameter>tli</parameter> <type>bigint</type>, <parameter>start_lsn</parameter> <type>pg_lsn</type>, <parameter>end_lsn</parameter> <type>pg_lsn</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>relfilenode</parameter> <type>oid</type>,
- <parameter>reltablespace</parameter> <type>oid</type>,
- <parameter>reldatabase</parameter> <type>oid</type>,
- <parameter>relforknumber</parameter> <type>smallint</type>,
- <parameter>relblocknumber</parameter> <type>bigint</type>,
- <parameter>is_limit_block</parameter> <type>boolean</type> )
- </para>
- <para>
- Returns one information about the contents of a single WAL summary file
- identified by TLI and starting and ending LSNs. Each row with
- <literal>is_limit_block</literal> false indicates that the block
- identified by the remaining output columns was modified by at least
- one WAL record within the range of records summarized by this file.
- Each row with <literal>is_limit_block</literal> true indicates either
- that (a) the relation fork was truncated to the length given by
- <literal>relblocknumber</literal> within the relevant range of WAL
- records or (b) that the relation fork was created or dropped within
- the relevant range of WAL records; in such cases,
- <literal>relblocknumber</literal> will be zero.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_wal_summarizer_state</primary>
- </indexterm>
- <function>pg_get_wal_summarizer_state</function> ()
- <returnvalue>record</returnvalue>
- ( <parameter>summarized_tli</parameter> <type>bigint</type>,
- <parameter>summarized_lsn</parameter> <type>pg_lsn</type>,
- <parameter>pending_lsn</parameter> <type>pg_lsn</type>,
- <parameter>summarizer_pid</parameter> <type>int</type> )
- </para>
- <para>
- Returns information about the progress of the WAL summarizer. If the
- WAL summarizer has never run since the instance was started, then
- <literal>summarized_tli</literal> and <literal>summarized_lsn</literal>
- will be <literal>0</literal> and <literal>0/0</literal> respectively;
- otherwise, they will be the TLI and ending LSN of the last WAL summary
- file written to disk. If the WAL summarizer is currently running,
- <literal>pending_lsn</literal> will be the ending LSN of the last
- record that it has consumed, which must always be greater than or
- equal to <literal>summarized_lsn</literal>; if the WAL summarizer is
- not running, it will be equal to <literal>summarized_lsn</literal>.
- <literal>summarizer_pid</literal> is the PID of the WAL summarizer
- process, if it is running, and otherwise NULL.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- </sect1>
+&func-info;
<sect1 id="functions-admin">
<title>System Administration Functions</title>
--
2.34.1
v1-0005-split-sect1-functions-aggregate-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0005-split-sect1-functions-aggregate-from-func.sgml.patchDownload
From 259bf2f06b6fc51903d8f563a615bb05625d84ee Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 15:02:48 +0800
Subject: [PATCH v1 5/7] split sect1: "functions-aggregate" from func.sgml
"functions-aggregate" lives in a new file: doc/src/sgml/func-aggregate.sgml,
it will hold doc/src/sgml/html/functions-aggregate.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-aggregate.sgml | 1418 +++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 1419 +-----------------------------
3 files changed, 1420 insertions(+), 1418 deletions(-)
create mode 100644 doc/src/sgml/func-aggregate.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 45330f8e..13694aca 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -22,6 +22,7 @@
<!ENTITY func-matching SYSTEM "func-matching.sgml">
<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-aggregate.sgml b/doc/src/sgml/func-aggregate.sgml
new file mode 100644
index 00000000..725d2892
--- /dev/null
+++ b/doc/src/sgml/func-aggregate.sgml
@@ -0,0 +1,1418 @@
+ <sect1 id="functions-aggregate">
+ <title>Aggregate Functions</title>
+
+ <indexterm zone="functions-aggregate">
+ <primary>aggregate function</primary>
+ <secondary>built-in</secondary>
+ </indexterm>
+
+ <para>
+ <firstterm>Aggregate functions</firstterm> compute a single result
+ from a set of input values. The built-in general-purpose aggregate
+ functions are listed in <xref linkend="functions-aggregate-table"/>
+ while statistical aggregates are in <xref
+ linkend="functions-aggregate-statistics-table"/>.
+ The built-in within-group ordered-set aggregate functions
+ are listed in <xref linkend="functions-orderedset-table"/>
+ while the built-in within-group hypothetical-set ones are in <xref
+ linkend="functions-hypothetical-table"/>. Grouping operations,
+ which are closely related to aggregate functions, are listed in
+ <xref linkend="functions-grouping-table"/>.
+ The special syntax considerations for aggregate
+ functions are explained in <xref linkend="syntax-aggregates"/>.
+ Consult <xref linkend="tutorial-agg"/> for additional introductory
+ information.
+ </para>
+
+ <para>
+ Aggregate functions that support <firstterm>Partial Mode</firstterm>
+ are eligible to participate in various optimizations, such as parallel
+ 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">
+ <colspec colname="col1" colwidth="10*"/>
+ <colspec colname="col2" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ <entry>Partial Mode</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>any_value</primary>
+ </indexterm>
+ <function>any_value</function> ( <type>anyelement</type> )
+ <returnvalue><replaceable>same as input type</replaceable></returnvalue>
+ </para>
+ <para>
+ Returns an arbitrary value from the non-null input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>array_agg</primary>
+ </indexterm>
+ <function>array_agg</function> ( <type>anynonarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>anyarray</returnvalue>
+ </para>
+ <para>
+ Collects all the input values, including nulls, into an array.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>array_agg</function> ( <type>anyarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>anyarray</returnvalue>
+ </para>
+ <para>
+ Concatenates all the input arrays into an array of one higher
+ dimension. (The inputs must all have the same dimensionality, and
+ cannot be empty or null.)
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>average</primary>
+ </indexterm>
+ <indexterm>
+ <primary>avg</primary>
+ </indexterm>
+ <function>avg</function> ( <type>smallint</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>integer</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>bigint</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>numeric</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>real</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>avg</function> ( <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Computes the average (arithmetic mean) of all the non-null input
+ values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bit_and</primary>
+ </indexterm>
+ <function>bit_and</function> ( <type>smallint</type> )
+ <returnvalue>smallint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_and</function> ( <type>integer</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_and</function> ( <type>bigint</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_and</function> ( <type>bit</type> )
+ <returnvalue>bit</returnvalue>
+ </para>
+ <para>
+ Computes the bitwise AND of all non-null input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bit_or</primary>
+ </indexterm>
+ <function>bit_or</function> ( <type>smallint</type> )
+ <returnvalue>smallint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_or</function> ( <type>integer</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_or</function> ( <type>bigint</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_or</function> ( <type>bit</type> )
+ <returnvalue>bit</returnvalue>
+ </para>
+ <para>
+ Computes the bitwise OR of all non-null input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bit_xor</primary>
+ </indexterm>
+ <function>bit_xor</function> ( <type>smallint</type> )
+ <returnvalue>smallint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_xor</function> ( <type>integer</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_xor</function> ( <type>bigint</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>bit_xor</function> ( <type>bit</type> )
+ <returnvalue>bit</returnvalue>
+ </para>
+ <para>
+ Computes the bitwise exclusive OR of all non-null input values.
+ Can be useful as a checksum for an unordered set of values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bool_and</primary>
+ </indexterm>
+ <function>bool_and</function> ( <type>boolean</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if all non-null input values are true, otherwise false.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>bool_or</primary>
+ </indexterm>
+ <function>bool_or</function> ( <type>boolean</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if any non-null input value is true, otherwise false.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>count</primary>
+ </indexterm>
+ <function>count</function> ( <literal>*</literal> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the number of input rows.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>count</function> ( <type>"any"</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the number of input rows in which the input value is not
+ null.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>every</primary>
+ </indexterm>
+ <function>every</function> ( <type>boolean</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ This is the SQL standard's equivalent to <function>bool_and</function>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_agg</primary>
+ </indexterm>
+ <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> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the input values, including nulls, into a JSON array.
+ Values are converted to JSON as per <function>to_json</function>
+ or <function>to_jsonb</function>.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_objectagg</primary></indexterm>
+ <function>json_objectagg</function> (
+ <optional> { <replaceable>key_expression</replaceable> { <literal>VALUE</literal> | ':' } <replaceable>value_expression</replaceable> } </optional>
+ <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
+ <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
+ </para>
+ <para>
+ Behaves like <function>json_object</function><!-- xref -->, but as an
+ aggregate function, so it only takes one
+ <replaceable>key_expression</replaceable> and one
+ <replaceable>value_expression</replaceable> parameter.
+ </para>
+ <para>
+ <literal>SELECT json_objectagg(k:v) FROM (VALUES ('a'::text,current_date),('b',current_date + 1)) AS t(k,v)</literal>
+ <returnvalue>{ "a" : "2022-05-10", "b" : "2022-05-11" }</returnvalue>
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object_agg</primary>
+ </indexterm>
+ <function>json_object_agg</function> ( <parameter>key</parameter>
+ <type>"any"</type>, <parameter>value</parameter>
+ <type>"any"</type>
+ <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object_agg</primary>
+ </indexterm>
+ <function>jsonb_object_agg</function> ( <parameter>key</parameter>
+ <type>"any"</type>, <parameter>value</parameter>
+ <type>"any"</type>
+ <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the key/value pairs into a JSON object. Key arguments
+ are coerced to text; value arguments are converted as per
+ <function>to_json</function> or <function>to_jsonb</function>.
+ Values can be null, but keys cannot.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object_agg_strict</primary>
+ </indexterm>
+ <function>json_object_agg_strict</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object_agg_strict</primary>
+ </indexterm>
+ <function>jsonb_object_agg_strict</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the key/value pairs into a JSON object. Key arguments
+ are coerced to text; value arguments are converted as per
+ <function>to_json</function> or <function>to_jsonb</function>.
+ The <parameter>key</parameter> can not be null. If the
+ <parameter>value</parameter> is null then the entry is skipped,
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object_agg_unique</primary>
+ </indexterm>
+ <function>json_object_agg_unique</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object_agg_unique</primary>
+ </indexterm>
+ <function>jsonb_object_agg_unique</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the key/value pairs into a JSON object. Key arguments
+ are coerced to text; value arguments are converted as per
+ <function>to_json</function> or <function>to_jsonb</function>.
+ Values can be null, but keys cannot.
+ If there is a duplicate key an error is thrown.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_arrayagg</primary></indexterm>
+ <function>json_arrayagg</function> (
+ <optional> <replaceable>value_expression</replaceable> </optional>
+ <optional> <literal>ORDER BY</literal> <replaceable>sort_expression</replaceable> </optional>
+ <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
+ </para>
+ <para>
+ Behaves in the same way as <function>json_array</function>
+ but as an aggregate function so it only takes one
+ <replaceable>value_expression</replaceable> parameter.
+ If <literal>ABSENT ON NULL</literal> is specified, any NULL
+ values are omitted.
+ If <literal>ORDER BY</literal> is specified, the elements will
+ appear in the array in that order rather than in the input order.
+ </para>
+ <para>
+ <literal>SELECT json_arrayagg(v) FROM (VALUES(2),(1)) t(v)</literal>
+ <returnvalue>[2, 1]</returnvalue>
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object_agg_unique_strict</primary>
+ </indexterm>
+ <function>json_object_agg_unique_strict</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object_agg_unique_strict</primary>
+ </indexterm>
+ <function>jsonb_object_agg_unique_strict</function> (
+ <parameter>key</parameter> <type>"any"</type>,
+ <parameter>value</parameter> <type>"any"</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the key/value pairs into a JSON object. Key arguments
+ are coerced to text; value arguments are converted as per
+ <function>to_json</function> or <function>to_jsonb</function>.
+ The <parameter>key</parameter> can not be null. If the
+ <parameter>value</parameter> is null then the entry is skipped.
+ If there is a duplicate key an error is thrown.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>max</primary>
+ </indexterm>
+ <function>max</function> ( <replaceable>see text</replaceable> )
+ <returnvalue><replaceable>same as input type</replaceable></returnvalue>
+ </para>
+ <para>
+ Computes the maximum of the non-null input
+ values. Available for any numeric, string, date/time, or enum type,
+ as well as <type>inet</type>, <type>interval</type>,
+ <type>money</type>, <type>oid</type>, <type>pg_lsn</type>,
+ <type>tid</type>, <type>xid8</type>,
+ and arrays of any of these types.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>min</primary>
+ </indexterm>
+ <function>min</function> ( <replaceable>see text</replaceable> )
+ <returnvalue><replaceable>same as input type</replaceable></returnvalue>
+ </para>
+ <para>
+ Computes the minimum of the non-null input
+ values. Available for any numeric, string, date/time, or enum type,
+ as well as <type>inet</type>, <type>interval</type>,
+ <type>money</type>, <type>oid</type>, <type>pg_lsn</type>,
+ <type>tid</type>, <type>xid8</type>,
+ and arrays of any of these types.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>range_agg</primary>
+ </indexterm>
+ <function>range_agg</function> ( <parameter>value</parameter>
+ <type>anyrange</type> )
+ <returnvalue>anymultirange</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>range_agg</function> ( <parameter>value</parameter>
+ <type>anymultirange</type> )
+ <returnvalue>anymultirange</returnvalue>
+ </para>
+ <para>
+ Computes the union of the non-null input values.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>range_intersect_agg</primary>
+ </indexterm>
+ <function>range_intersect_agg</function> ( <parameter>value</parameter>
+ <type>anyrange</type> )
+ <returnvalue>anyrange</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>range_intersect_agg</function> ( <parameter>value</parameter>
+ <type>anymultirange</type> )
+ <returnvalue>anymultirange</returnvalue>
+ </para>
+ <para>
+ Computes the intersection of the non-null input values.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_agg_strict</primary>
+ </indexterm>
+ <function>json_agg_strict</function> ( <type>anyelement</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_agg_strict</primary>
+ </indexterm>
+ <function>jsonb_agg_strict</function> ( <type>anyelement</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Collects all the input values, skipping nulls, into a JSON array.
+ Values are converted to JSON as per <function>to_json</function>
+ or <function>to_jsonb</function>.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>string_agg</primary>
+ </indexterm>
+ <function>string_agg</function> ( <parameter>value</parameter>
+ <type>text</type>, <parameter>delimiter</parameter> <type>text</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>string_agg</function> ( <parameter>value</parameter>
+ <type>bytea</type>, <parameter>delimiter</parameter> <type>bytea</type>
+ <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>bytea</returnvalue>
+ </para>
+ <para>
+ Concatenates the non-null input values into a string. Each value
+ after the first is preceded by the
+ corresponding <parameter>delimiter</parameter> (if it's not null).
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>sum</primary>
+ </indexterm>
+ <function>sum</function> ( <type>smallint</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>integer</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>bigint</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>numeric</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>real</type> )
+ <returnvalue>real</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>sum</function> ( <type>money</type> )
+ <returnvalue>money</returnvalue>
+ </para>
+ <para>
+ Computes the sum of the non-null input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>xmlagg</primary>
+ </indexterm>
+ <function>xmlagg</function> ( <type>xml</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
+ <returnvalue>xml</returnvalue>
+ </para>
+ <para>
+ Concatenates the non-null XML input values (see
+ <xref linkend="functions-xml-xmlagg"/>).
+ </para></entry>
+ <entry>No</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ It should be noted that except for <function>count</function>,
+ these functions return a null value when no rows are selected. In
+ particular, <function>sum</function> of no rows returns null, not
+ zero as one might expect, and <function>array_agg</function>
+ returns null rather than an empty array when there are no input
+ rows. The <function>coalesce</function> function can be used to
+ substitute zero or an empty array for null when necessary.
+ </para>
+
+ <para>
+ The aggregate functions <function>array_agg</function>,
+ <function>json_agg</function>, <function>jsonb_agg</function>,
+ <function>json_agg_strict</function>, <function>jsonb_agg_strict</function>,
+ <function>json_object_agg</function>, <function>jsonb_object_agg</function>,
+ <function>json_object_agg_strict</function>, <function>jsonb_object_agg_strict</function>,
+ <function>json_object_agg_unique</function>, <function>jsonb_object_agg_unique</function>,
+ <function>json_object_agg_unique_strict</function>,
+ <function>jsonb_object_agg_unique_strict</function>,
+ <function>string_agg</function>,
+ and <function>xmlagg</function>, as well as similar user-defined
+ aggregate functions, produce meaningfully different result values
+ depending on the order of the input values. This ordering is
+ unspecified by default, but can be controlled by writing an
+ <literal>ORDER BY</literal> clause within the aggregate call, as shown in
+ <xref linkend="syntax-aggregates"/>.
+ Alternatively, supplying the input values from a sorted subquery
+ will usually work. For example:
+
+<screen><![CDATA[
+SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
+]]></screen>
+
+ Beware that this approach can fail if the outer query level contains
+ additional processing, such as a join, because that might cause the
+ subquery's output to be reordered before the aggregate is computed.
+ </para>
+
+ <note>
+ <indexterm>
+ <primary>ANY</primary>
+ </indexterm>
+ <indexterm>
+ <primary>SOME</primary>
+ </indexterm>
+ <para>
+ The boolean aggregates <function>bool_and</function> and
+ <function>bool_or</function> correspond to the standard SQL aggregates
+ <function>every</function> and <function>any</function> or
+ <function>some</function>.
+ <productname>PostgreSQL</productname>
+ supports <function>every</function>, but not <function>any</function>
+ or <function>some</function>, because there is an ambiguity built into
+ the standard syntax:
+<programlisting>
+SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;
+</programlisting>
+ Here <function>ANY</function> can be considered either as introducing
+ a subquery, or as being an aggregate function, if the subquery
+ returns one row with a Boolean value.
+ Thus the standard name cannot be given to these aggregates.
+ </para>
+ </note>
+
+ <note>
+ <para>
+ Users accustomed to working with other SQL database management
+ systems might be disappointed by the performance of the
+ <function>count</function> aggregate when it is applied to the
+ entire table. A query like:
+<programlisting>
+SELECT count(*) FROM sometable;
+</programlisting>
+ will require effort proportional to the size of the table:
+ <productname>PostgreSQL</productname> will need to scan either the
+ entire table or the entirety of an index that includes all rows in
+ the table.
+ </para>
+ </note>
+
+ <para>
+ <xref linkend="functions-aggregate-statistics-table"/> shows
+ aggregate functions typically used in statistical analysis.
+ (These are separated out merely to avoid cluttering the listing
+ of more-commonly-used aggregates.) Functions shown as
+ accepting <replaceable>numeric_type</replaceable> are available for all
+ the types <type>smallint</type>, <type>integer</type>,
+ <type>bigint</type>, <type>numeric</type>, <type>real</type>,
+ and <type>double precision</type>.
+ Where the description mentions
+ <parameter>N</parameter>, it means the
+ number of input rows for which all the input expressions are non-null.
+ In all cases, null is returned if the computation is meaningless,
+ for example when <parameter>N</parameter> is zero.
+ </para>
+
+ <indexterm>
+ <primary>statistics</primary>
+ </indexterm>
+ <indexterm>
+ <primary>linear regression</primary>
+ </indexterm>
+
+ <table id="functions-aggregate-statistics-table">
+ <title>Aggregate Functions for Statistics</title>
+ <tgroup cols="2">
+ <colspec colname="col1" colwidth="10*"/>
+ <colspec colname="col2" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ <entry>Partial Mode</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>correlation</primary>
+ </indexterm>
+ <indexterm>
+ <primary>corr</primary>
+ </indexterm>
+ <function>corr</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the correlation coefficient.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>covariance</primary>
+ <secondary>population</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>covar_pop</primary>
+ </indexterm>
+ <function>covar_pop</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the population covariance.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>covariance</primary>
+ <secondary>sample</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>covar_samp</primary>
+ </indexterm>
+ <function>covar_samp</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the sample covariance.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_avgx</primary>
+ </indexterm>
+ <function>regr_avgx</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the average of the independent variable,
+ <literal>sum(<parameter>X</parameter>)/<parameter>N</parameter></literal>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_avgy</primary>
+ </indexterm>
+ <function>regr_avgy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the average of the dependent variable,
+ <literal>sum(<parameter>Y</parameter>)/<parameter>N</parameter></literal>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_count</primary>
+ </indexterm>
+ <function>regr_count</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the number of rows in which both inputs are non-null.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regression intercept</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regr_intercept</primary>
+ </indexterm>
+ <function>regr_intercept</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the y-intercept of the least-squares-fit linear equation
+ determined by the
+ (<parameter>X</parameter>, <parameter>Y</parameter>) pairs.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_r2</primary>
+ </indexterm>
+ <function>regr_r2</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the square of the correlation coefficient.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regression slope</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regr_slope</primary>
+ </indexterm>
+ <function>regr_slope</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the slope of the least-squares-fit linear equation determined
+ by the (<parameter>X</parameter>, <parameter>Y</parameter>)
+ pairs.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_sxx</primary>
+ </indexterm>
+ <function>regr_sxx</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the <quote>sum of squares</quote> of the independent
+ variable,
+ <literal>sum(<parameter>X</parameter>^2) - sum(<parameter>X</parameter>)^2/<parameter>N</parameter></literal>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_sxy</primary>
+ </indexterm>
+ <function>regr_sxy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the <quote>sum of products</quote> of independent times
+ dependent variables,
+ <literal>sum(<parameter>X</parameter>*<parameter>Y</parameter>) - sum(<parameter>X</parameter>) * sum(<parameter>Y</parameter>)/<parameter>N</parameter></literal>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>regr_syy</primary>
+ </indexterm>
+ <function>regr_syy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the <quote>sum of squares</quote> of the dependent
+ variable,
+ <literal>sum(<parameter>Y</parameter>^2) - sum(<parameter>Y</parameter>)^2/<parameter>N</parameter></literal>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>standard deviation</primary>
+ </indexterm>
+ <indexterm>
+ <primary>stddev</primary>
+ </indexterm>
+ <function>stddev</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ This is a historical alias for <function>stddev_samp</function>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>standard deviation</primary>
+ <secondary>population</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>stddev_pop</primary>
+ </indexterm>
+ <function>stddev_pop</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ Computes the population standard deviation of the input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>standard deviation</primary>
+ <secondary>sample</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>stddev_samp</primary>
+ </indexterm>
+ <function>stddev_samp</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ Computes the sample standard deviation of the input values.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>variance</primary>
+ </indexterm>
+ <function>variance</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ This is a historical alias for <function>var_samp</function>.
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>variance</primary>
+ <secondary>population</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>var_pop</primary>
+ </indexterm>
+ <function>var_pop</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ Computes the population variance of the input values (square of the
+ population standard deviation).
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>variance</primary>
+ <secondary>sample</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>var_samp</primary>
+ </indexterm>
+ <function>var_samp</function> ( <replaceable>numeric_type</replaceable> )
+ <returnvalue></returnvalue> <type>double precision</type>
+ for <type>real</type> or <type>double precision</type>,
+ otherwise <type>numeric</type>
+ </para>
+ <para>
+ Computes the sample variance of the input values (square of the sample
+ standard deviation).
+ </para></entry>
+ <entry>Yes</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-orderedset-table"/> shows some
+ aggregate functions that use the <firstterm>ordered-set aggregate</firstterm>
+ syntax. These functions are sometimes referred to as <quote>inverse
+ distribution</quote> functions. Their aggregated input is introduced by
+ <literal>ORDER BY</literal>, and they may also take a <firstterm>direct
+ argument</firstterm> that is not aggregated, but is computed only once.
+ All these functions ignore null values in their aggregated input.
+ For those that take a <parameter>fraction</parameter> parameter, the
+ fraction value must be between 0 and 1; an error is thrown if not.
+ However, a null <parameter>fraction</parameter> value simply produces a
+ null result.
+ </para>
+
+ <indexterm>
+ <primary>ordered-set aggregate</primary>
+ <secondary>built-in</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>inverse distribution</primary>
+ </indexterm>
+
+ <table id="functions-orderedset-table">
+ <title>Ordered-Set Aggregate Functions</title>
+ <tgroup cols="2">
+ <colspec colname="col1" colwidth="10*"/>
+ <colspec colname="col2" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ <entry>Partial Mode</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>mode</primary>
+ <secondary>statistical</secondary>
+ </indexterm>
+ <function>mode</function> () <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
+ <returnvalue>anyelement</returnvalue>
+ </para>
+ <para>
+ Computes the <firstterm>mode</firstterm>, the most frequent
+ value of the aggregated argument (arbitrarily choosing the first one
+ if there are multiple equally-frequent values). The aggregated
+ argument must be of a sortable type.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>percentile</primary>
+ <secondary>continuous</secondary>
+ </indexterm>
+ <function>percentile_cont</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>double precision</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>percentile_cont</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Computes the <firstterm>continuous percentile</firstterm>, a value
+ corresponding to the specified <parameter>fraction</parameter>
+ within the ordered set of aggregated argument values. This will
+ interpolate between adjacent input items if needed.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>percentile_cont</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>double precision</type> )
+ <returnvalue>double precision[]</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>percentile_cont</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>interval</type> )
+ <returnvalue>interval[]</returnvalue>
+ </para>
+ <para>
+ Computes multiple continuous percentiles. The result is an array of
+ the same dimensions as the <parameter>fractions</parameter>
+ parameter, with each non-null element replaced by the (possibly
+ interpolated) value corresponding to that percentile.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>percentile</primary>
+ <secondary>discrete</secondary>
+ </indexterm>
+ <function>percentile_disc</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
+ <returnvalue>anyelement</returnvalue>
+ </para>
+ <para>
+ Computes the <firstterm>discrete percentile</firstterm>, the first
+ value within the ordered set of aggregated argument values whose
+ position in the ordering equals or exceeds the
+ specified <parameter>fraction</parameter>. The aggregated
+ argument must be of a sortable type.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>percentile_disc</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
+ <returnvalue>anyarray</returnvalue>
+ </para>
+ <para>
+ Computes multiple discrete percentiles. The result is an array of the
+ same dimensions as the <parameter>fractions</parameter> parameter,
+ with each non-null element replaced by the input value corresponding
+ to that percentile.
+ The aggregated argument must be of a sortable type.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <indexterm>
+ <primary>hypothetical-set aggregate</primary>
+ <secondary>built-in</secondary>
+ </indexterm>
+
+ <para>
+ Each of the <quote>hypothetical-set</quote> aggregates listed in
+ <xref linkend="functions-hypothetical-table"/> is associated with a
+ window function of the same name defined in
+ <xref linkend="functions-window"/>. In each case, the aggregate's result
+ is the value that the associated window function would have
+ returned for the <quote>hypothetical</quote> row constructed from
+ <replaceable>args</replaceable>, if such a row had been added to the sorted
+ group of rows represented by the <replaceable>sorted_args</replaceable>.
+ For each of these functions, the list of direct arguments
+ given in <replaceable>args</replaceable> must match the number and types of
+ the aggregated arguments given in <replaceable>sorted_args</replaceable>.
+ Unlike most built-in aggregates, these aggregates are not strict, that is
+ they do not drop input rows containing nulls. Null values sort according
+ to the rule specified in the <literal>ORDER BY</literal> clause.
+ </para>
+
+ <table id="functions-hypothetical-table">
+ <title>Hypothetical-Set Aggregate Functions</title>
+ <tgroup cols="2">
+ <colspec colname="col1" colwidth="10*"/>
+ <colspec colname="col2" colwidth="1*"/>
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ <entry>Partial Mode</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>rank</primary>
+ <secondary>hypothetical</secondary>
+ </indexterm>
+ <function>rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the rank of the hypothetical row, with gaps; that is, the row
+ number of the first row in its peer group.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>dense_rank</primary>
+ <secondary>hypothetical</secondary>
+ </indexterm>
+ <function>dense_rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the rank of the hypothetical row, without gaps; this function
+ effectively counts peer groups.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>percent_rank</primary>
+ <secondary>hypothetical</secondary>
+ </indexterm>
+ <function>percent_rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the relative rank of the hypothetical row, that is
+ (<function>rank</function> - 1) / (total rows - 1).
+ The value thus ranges from 0 to 1 inclusive.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>cume_dist</primary>
+ <secondary>hypothetical</secondary>
+ </indexterm>
+ <function>cume_dist</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Computes the cumulative distribution, that is (number of rows
+ preceding or peers with hypothetical row) / (total rows). The value
+ thus ranges from 1/<parameter>N</parameter> to 1.
+ </para></entry>
+ <entry>No</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-grouping-table">
+ <title>Grouping Operations</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>GROUPING</primary>
+ </indexterm>
+ <function>GROUPING</function> ( <replaceable>group_by_expression(s)</replaceable> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns a bit mask indicating which <literal>GROUP BY</literal>
+ expressions are not included in the current grouping set.
+ Bits are assigned with the rightmost argument corresponding to the
+ least-significant bit; each bit is 0 if the corresponding expression
+ is included in the grouping criteria of the grouping set generating
+ the current result row, and 1 if it is not included.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The grouping operations shown in
+ <xref linkend="functions-grouping-table"/> are used in conjunction with
+ grouping sets (see <xref linkend="queries-grouping-sets"/>) to distinguish
+ result rows. The arguments to the <literal>GROUPING</literal> function
+ are not actually evaluated, but they must exactly match expressions given
+ in the <literal>GROUP BY</literal> clause of the associated query level.
+ For example:
+<screen>
+<prompt>=></prompt> <userinput>SELECT * FROM items_sold;</userinput>
+ make | model | sales
+-------+-------+-------
+ Foo | GT | 10
+ Foo | Tour | 20
+ Bar | City | 15
+ Bar | Sport | 5
+(4 rows)
+
+<prompt>=></prompt> <userinput>SELECT make, model, GROUPING(make,model), sum(sales) FROM items_sold GROUP BY ROLLUP(make,model);</userinput>
+ make | model | grouping | sum
+-------+-------+----------+-----
+ Foo | GT | 0 | 10
+ Foo | Tour | 0 | 20
+ Bar | City | 0 | 15
+ Bar | Sport | 0 | 5
+ Foo | | 1 | 30
+ Bar | | 1 | 20
+ | | 3 | 50
+(7 rows)
+</screen>
+ Here, the <literal>grouping</literal> value <literal>0</literal> in the
+ first four rows shows that those have been grouped normally, over both the
+ grouping columns. The value <literal>1</literal> indicates
+ that <literal>model</literal> was not grouped by in the next-to-last two
+ rows, and the value <literal>3</literal> indicates that
+ neither <literal>make</literal> nor <literal>model</literal> was grouped
+ by in the last row (which therefore is an aggregate over all the input
+ rows).
+ </para>
+
+ </sect1>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7ee6b51f..8fd550ad 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11241,1424 +11241,7 @@ SELECT NULLIF(value, '(none)') ...
</para>
</sect1>
- <sect1 id="functions-aggregate">
- <title>Aggregate Functions</title>
-
- <indexterm zone="functions-aggregate">
- <primary>aggregate function</primary>
- <secondary>built-in</secondary>
- </indexterm>
-
- <para>
- <firstterm>Aggregate functions</firstterm> compute a single result
- from a set of input values. The built-in general-purpose aggregate
- functions are listed in <xref linkend="functions-aggregate-table"/>
- while statistical aggregates are in <xref
- linkend="functions-aggregate-statistics-table"/>.
- The built-in within-group ordered-set aggregate functions
- are listed in <xref linkend="functions-orderedset-table"/>
- while the built-in within-group hypothetical-set ones are in <xref
- linkend="functions-hypothetical-table"/>. Grouping operations,
- which are closely related to aggregate functions, are listed in
- <xref linkend="functions-grouping-table"/>.
- The special syntax considerations for aggregate
- functions are explained in <xref linkend="syntax-aggregates"/>.
- Consult <xref linkend="tutorial-agg"/> for additional introductory
- information.
- </para>
-
- <para>
- Aggregate functions that support <firstterm>Partial Mode</firstterm>
- are eligible to participate in various optimizations, such as parallel
- 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">
- <colspec colname="col1" colwidth="10*"/>
- <colspec colname="col2" colwidth="1*"/>
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- <entry>Partial Mode</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>any_value</primary>
- </indexterm>
- <function>any_value</function> ( <type>anyelement</type> )
- <returnvalue><replaceable>same as input type</replaceable></returnvalue>
- </para>
- <para>
- Returns an arbitrary value from the non-null input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>array_agg</primary>
- </indexterm>
- <function>array_agg</function> ( <type>anynonarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>anyarray</returnvalue>
- </para>
- <para>
- Collects all the input values, including nulls, into an array.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>array_agg</function> ( <type>anyarray</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>anyarray</returnvalue>
- </para>
- <para>
- Concatenates all the input arrays into an array of one higher
- dimension. (The inputs must all have the same dimensionality, and
- cannot be empty or null.)
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>average</primary>
- </indexterm>
- <indexterm>
- <primary>avg</primary>
- </indexterm>
- <function>avg</function> ( <type>smallint</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>integer</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>bigint</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>numeric</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>real</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para role="func_signature">
- <function>avg</function> ( <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Computes the average (arithmetic mean) of all the non-null input
- values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bit_and</primary>
- </indexterm>
- <function>bit_and</function> ( <type>smallint</type> )
- <returnvalue>smallint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_and</function> ( <type>integer</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_and</function> ( <type>bigint</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_and</function> ( <type>bit</type> )
- <returnvalue>bit</returnvalue>
- </para>
- <para>
- Computes the bitwise AND of all non-null input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bit_or</primary>
- </indexterm>
- <function>bit_or</function> ( <type>smallint</type> )
- <returnvalue>smallint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_or</function> ( <type>integer</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_or</function> ( <type>bigint</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_or</function> ( <type>bit</type> )
- <returnvalue>bit</returnvalue>
- </para>
- <para>
- Computes the bitwise OR of all non-null input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bit_xor</primary>
- </indexterm>
- <function>bit_xor</function> ( <type>smallint</type> )
- <returnvalue>smallint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_xor</function> ( <type>integer</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_xor</function> ( <type>bigint</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>bit_xor</function> ( <type>bit</type> )
- <returnvalue>bit</returnvalue>
- </para>
- <para>
- Computes the bitwise exclusive OR of all non-null input values.
- Can be useful as a checksum for an unordered set of values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bool_and</primary>
- </indexterm>
- <function>bool_and</function> ( <type>boolean</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if all non-null input values are true, otherwise false.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>bool_or</primary>
- </indexterm>
- <function>bool_or</function> ( <type>boolean</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if any non-null input value is true, otherwise false.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>count</primary>
- </indexterm>
- <function>count</function> ( <literal>*</literal> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the number of input rows.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>count</function> ( <type>"any"</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the number of input rows in which the input value is not
- null.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>every</primary>
- </indexterm>
- <function>every</function> ( <type>boolean</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- This is the SQL standard's equivalent to <function>bool_and</function>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_agg</primary>
- </indexterm>
- <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> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the input values, including nulls, into a JSON array.
- Values are converted to JSON as per <function>to_json</function>
- or <function>to_jsonb</function>.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_objectagg</primary></indexterm>
- <function>json_objectagg</function> (
- <optional> { <replaceable>key_expression</replaceable> { <literal>VALUE</literal> | ':' } <replaceable>value_expression</replaceable> } </optional>
- <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
- <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
- </para>
- <para>
- Behaves like <function>json_object</function><!-- xref -->, but as an
- aggregate function, so it only takes one
- <replaceable>key_expression</replaceable> and one
- <replaceable>value_expression</replaceable> parameter.
- </para>
- <para>
- <literal>SELECT json_objectagg(k:v) FROM (VALUES ('a'::text,current_date),('b',current_date + 1)) AS t(k,v)</literal>
- <returnvalue>{ "a" : "2022-05-10", "b" : "2022-05-11" }</returnvalue>
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object_agg</primary>
- </indexterm>
- <function>json_object_agg</function> ( <parameter>key</parameter>
- <type>"any"</type>, <parameter>value</parameter>
- <type>"any"</type>
- <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object_agg</primary>
- </indexterm>
- <function>jsonb_object_agg</function> ( <parameter>key</parameter>
- <type>"any"</type>, <parameter>value</parameter>
- <type>"any"</type>
- <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the key/value pairs into a JSON object. Key arguments
- are coerced to text; value arguments are converted as per
- <function>to_json</function> or <function>to_jsonb</function>.
- Values can be null, but keys cannot.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object_agg_strict</primary>
- </indexterm>
- <function>json_object_agg_strict</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object_agg_strict</primary>
- </indexterm>
- <function>jsonb_object_agg_strict</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the key/value pairs into a JSON object. Key arguments
- are coerced to text; value arguments are converted as per
- <function>to_json</function> or <function>to_jsonb</function>.
- The <parameter>key</parameter> can not be null. If the
- <parameter>value</parameter> is null then the entry is skipped,
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object_agg_unique</primary>
- </indexterm>
- <function>json_object_agg_unique</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object_agg_unique</primary>
- </indexterm>
- <function>jsonb_object_agg_unique</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the key/value pairs into a JSON object. Key arguments
- are coerced to text; value arguments are converted as per
- <function>to_json</function> or <function>to_jsonb</function>.
- Values can be null, but keys cannot.
- If there is a duplicate key an error is thrown.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_arrayagg</primary></indexterm>
- <function>json_arrayagg</function> (
- <optional> <replaceable>value_expression</replaceable> </optional>
- <optional> <literal>ORDER BY</literal> <replaceable>sort_expression</replaceable> </optional>
- <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
- </para>
- <para>
- Behaves in the same way as <function>json_array</function>
- but as an aggregate function so it only takes one
- <replaceable>value_expression</replaceable> parameter.
- If <literal>ABSENT ON NULL</literal> is specified, any NULL
- values are omitted.
- If <literal>ORDER BY</literal> is specified, the elements will
- appear in the array in that order rather than in the input order.
- </para>
- <para>
- <literal>SELECT json_arrayagg(v) FROM (VALUES(2),(1)) t(v)</literal>
- <returnvalue>[2, 1]</returnvalue>
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object_agg_unique_strict</primary>
- </indexterm>
- <function>json_object_agg_unique_strict</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object_agg_unique_strict</primary>
- </indexterm>
- <function>jsonb_object_agg_unique_strict</function> (
- <parameter>key</parameter> <type>"any"</type>,
- <parameter>value</parameter> <type>"any"</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the key/value pairs into a JSON object. Key arguments
- are coerced to text; value arguments are converted as per
- <function>to_json</function> or <function>to_jsonb</function>.
- The <parameter>key</parameter> can not be null. If the
- <parameter>value</parameter> is null then the entry is skipped.
- If there is a duplicate key an error is thrown.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>max</primary>
- </indexterm>
- <function>max</function> ( <replaceable>see text</replaceable> )
- <returnvalue><replaceable>same as input type</replaceable></returnvalue>
- </para>
- <para>
- Computes the maximum of the non-null input
- values. Available for any numeric, string, date/time, or enum type,
- as well as <type>inet</type>, <type>interval</type>,
- <type>money</type>, <type>oid</type>, <type>pg_lsn</type>,
- <type>tid</type>, <type>xid8</type>,
- and arrays of any of these types.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>min</primary>
- </indexterm>
- <function>min</function> ( <replaceable>see text</replaceable> )
- <returnvalue><replaceable>same as input type</replaceable></returnvalue>
- </para>
- <para>
- Computes the minimum of the non-null input
- values. Available for any numeric, string, date/time, or enum type,
- as well as <type>inet</type>, <type>interval</type>,
- <type>money</type>, <type>oid</type>, <type>pg_lsn</type>,
- <type>tid</type>, <type>xid8</type>,
- and arrays of any of these types.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>range_agg</primary>
- </indexterm>
- <function>range_agg</function> ( <parameter>value</parameter>
- <type>anyrange</type> )
- <returnvalue>anymultirange</returnvalue>
- </para>
- <para role="func_signature">
- <function>range_agg</function> ( <parameter>value</parameter>
- <type>anymultirange</type> )
- <returnvalue>anymultirange</returnvalue>
- </para>
- <para>
- Computes the union of the non-null input values.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>range_intersect_agg</primary>
- </indexterm>
- <function>range_intersect_agg</function> ( <parameter>value</parameter>
- <type>anyrange</type> )
- <returnvalue>anyrange</returnvalue>
- </para>
- <para role="func_signature">
- <function>range_intersect_agg</function> ( <parameter>value</parameter>
- <type>anymultirange</type> )
- <returnvalue>anymultirange</returnvalue>
- </para>
- <para>
- Computes the intersection of the non-null input values.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_agg_strict</primary>
- </indexterm>
- <function>json_agg_strict</function> ( <type>anyelement</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_agg_strict</primary>
- </indexterm>
- <function>jsonb_agg_strict</function> ( <type>anyelement</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Collects all the input values, skipping nulls, into a JSON array.
- Values are converted to JSON as per <function>to_json</function>
- or <function>to_jsonb</function>.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>string_agg</primary>
- </indexterm>
- <function>string_agg</function> ( <parameter>value</parameter>
- <type>text</type>, <parameter>delimiter</parameter> <type>text</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>string_agg</function> ( <parameter>value</parameter>
- <type>bytea</type>, <parameter>delimiter</parameter> <type>bytea</type>
- <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>bytea</returnvalue>
- </para>
- <para>
- Concatenates the non-null input values into a string. Each value
- after the first is preceded by the
- corresponding <parameter>delimiter</parameter> (if it's not null).
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>sum</primary>
- </indexterm>
- <function>sum</function> ( <type>smallint</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>integer</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>bigint</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>numeric</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>real</type> )
- <returnvalue>real</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para role="func_signature">
- <function>sum</function> ( <type>money</type> )
- <returnvalue>money</returnvalue>
- </para>
- <para>
- Computes the sum of the non-null input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>xmlagg</primary>
- </indexterm>
- <function>xmlagg</function> ( <type>xml</type> <literal>ORDER BY</literal> <literal>input_sort_columns</literal> )
- <returnvalue>xml</returnvalue>
- </para>
- <para>
- Concatenates the non-null XML input values (see
- <xref linkend="functions-xml-xmlagg"/>).
- </para></entry>
- <entry>No</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- It should be noted that except for <function>count</function>,
- these functions return a null value when no rows are selected. In
- particular, <function>sum</function> of no rows returns null, not
- zero as one might expect, and <function>array_agg</function>
- returns null rather than an empty array when there are no input
- rows. The <function>coalesce</function> function can be used to
- substitute zero or an empty array for null when necessary.
- </para>
-
- <para>
- The aggregate functions <function>array_agg</function>,
- <function>json_agg</function>, <function>jsonb_agg</function>,
- <function>json_agg_strict</function>, <function>jsonb_agg_strict</function>,
- <function>json_object_agg</function>, <function>jsonb_object_agg</function>,
- <function>json_object_agg_strict</function>, <function>jsonb_object_agg_strict</function>,
- <function>json_object_agg_unique</function>, <function>jsonb_object_agg_unique</function>,
- <function>json_object_agg_unique_strict</function>,
- <function>jsonb_object_agg_unique_strict</function>,
- <function>string_agg</function>,
- and <function>xmlagg</function>, as well as similar user-defined
- aggregate functions, produce meaningfully different result values
- depending on the order of the input values. This ordering is
- unspecified by default, but can be controlled by writing an
- <literal>ORDER BY</literal> clause within the aggregate call, as shown in
- <xref linkend="syntax-aggregates"/>.
- Alternatively, supplying the input values from a sorted subquery
- will usually work. For example:
-
-<screen><![CDATA[
-SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
-]]></screen>
-
- Beware that this approach can fail if the outer query level contains
- additional processing, such as a join, because that might cause the
- subquery's output to be reordered before the aggregate is computed.
- </para>
-
- <note>
- <indexterm>
- <primary>ANY</primary>
- </indexterm>
- <indexterm>
- <primary>SOME</primary>
- </indexterm>
- <para>
- The boolean aggregates <function>bool_and</function> and
- <function>bool_or</function> correspond to the standard SQL aggregates
- <function>every</function> and <function>any</function> or
- <function>some</function>.
- <productname>PostgreSQL</productname>
- supports <function>every</function>, but not <function>any</function>
- or <function>some</function>, because there is an ambiguity built into
- the standard syntax:
-<programlisting>
-SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;
-</programlisting>
- Here <function>ANY</function> can be considered either as introducing
- a subquery, or as being an aggregate function, if the subquery
- returns one row with a Boolean value.
- Thus the standard name cannot be given to these aggregates.
- </para>
- </note>
-
- <note>
- <para>
- Users accustomed to working with other SQL database management
- systems might be disappointed by the performance of the
- <function>count</function> aggregate when it is applied to the
- entire table. A query like:
-<programlisting>
-SELECT count(*) FROM sometable;
-</programlisting>
- will require effort proportional to the size of the table:
- <productname>PostgreSQL</productname> will need to scan either the
- entire table or the entirety of an index that includes all rows in
- the table.
- </para>
- </note>
-
- <para>
- <xref linkend="functions-aggregate-statistics-table"/> shows
- aggregate functions typically used in statistical analysis.
- (These are separated out merely to avoid cluttering the listing
- of more-commonly-used aggregates.) Functions shown as
- accepting <replaceable>numeric_type</replaceable> are available for all
- the types <type>smallint</type>, <type>integer</type>,
- <type>bigint</type>, <type>numeric</type>, <type>real</type>,
- and <type>double precision</type>.
- Where the description mentions
- <parameter>N</parameter>, it means the
- number of input rows for which all the input expressions are non-null.
- In all cases, null is returned if the computation is meaningless,
- for example when <parameter>N</parameter> is zero.
- </para>
-
- <indexterm>
- <primary>statistics</primary>
- </indexterm>
- <indexterm>
- <primary>linear regression</primary>
- </indexterm>
-
- <table id="functions-aggregate-statistics-table">
- <title>Aggregate Functions for Statistics</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="10*"/>
- <colspec colname="col2" colwidth="1*"/>
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- <entry>Partial Mode</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>correlation</primary>
- </indexterm>
- <indexterm>
- <primary>corr</primary>
- </indexterm>
- <function>corr</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the correlation coefficient.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>covariance</primary>
- <secondary>population</secondary>
- </indexterm>
- <indexterm>
- <primary>covar_pop</primary>
- </indexterm>
- <function>covar_pop</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the population covariance.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>covariance</primary>
- <secondary>sample</secondary>
- </indexterm>
- <indexterm>
- <primary>covar_samp</primary>
- </indexterm>
- <function>covar_samp</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the sample covariance.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_avgx</primary>
- </indexterm>
- <function>regr_avgx</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the average of the independent variable,
- <literal>sum(<parameter>X</parameter>)/<parameter>N</parameter></literal>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_avgy</primary>
- </indexterm>
- <function>regr_avgy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the average of the dependent variable,
- <literal>sum(<parameter>Y</parameter>)/<parameter>N</parameter></literal>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_count</primary>
- </indexterm>
- <function>regr_count</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the number of rows in which both inputs are non-null.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regression intercept</primary>
- </indexterm>
- <indexterm>
- <primary>regr_intercept</primary>
- </indexterm>
- <function>regr_intercept</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the y-intercept of the least-squares-fit linear equation
- determined by the
- (<parameter>X</parameter>, <parameter>Y</parameter>) pairs.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_r2</primary>
- </indexterm>
- <function>regr_r2</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the square of the correlation coefficient.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regression slope</primary>
- </indexterm>
- <indexterm>
- <primary>regr_slope</primary>
- </indexterm>
- <function>regr_slope</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the slope of the least-squares-fit linear equation determined
- by the (<parameter>X</parameter>, <parameter>Y</parameter>)
- pairs.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_sxx</primary>
- </indexterm>
- <function>regr_sxx</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the <quote>sum of squares</quote> of the independent
- variable,
- <literal>sum(<parameter>X</parameter>^2) - sum(<parameter>X</parameter>)^2/<parameter>N</parameter></literal>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_sxy</primary>
- </indexterm>
- <function>regr_sxy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the <quote>sum of products</quote> of independent times
- dependent variables,
- <literal>sum(<parameter>X</parameter>*<parameter>Y</parameter>) - sum(<parameter>X</parameter>) * sum(<parameter>Y</parameter>)/<parameter>N</parameter></literal>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>regr_syy</primary>
- </indexterm>
- <function>regr_syy</function> ( <parameter>Y</parameter> <type>double precision</type>, <parameter>X</parameter> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the <quote>sum of squares</quote> of the dependent
- variable,
- <literal>sum(<parameter>Y</parameter>^2) - sum(<parameter>Y</parameter>)^2/<parameter>N</parameter></literal>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>standard deviation</primary>
- </indexterm>
- <indexterm>
- <primary>stddev</primary>
- </indexterm>
- <function>stddev</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- This is a historical alias for <function>stddev_samp</function>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>standard deviation</primary>
- <secondary>population</secondary>
- </indexterm>
- <indexterm>
- <primary>stddev_pop</primary>
- </indexterm>
- <function>stddev_pop</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- Computes the population standard deviation of the input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>standard deviation</primary>
- <secondary>sample</secondary>
- </indexterm>
- <indexterm>
- <primary>stddev_samp</primary>
- </indexterm>
- <function>stddev_samp</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- Computes the sample standard deviation of the input values.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>variance</primary>
- </indexterm>
- <function>variance</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- This is a historical alias for <function>var_samp</function>.
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>variance</primary>
- <secondary>population</secondary>
- </indexterm>
- <indexterm>
- <primary>var_pop</primary>
- </indexterm>
- <function>var_pop</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- Computes the population variance of the input values (square of the
- population standard deviation).
- </para></entry>
- <entry>Yes</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>variance</primary>
- <secondary>sample</secondary>
- </indexterm>
- <indexterm>
- <primary>var_samp</primary>
- </indexterm>
- <function>var_samp</function> ( <replaceable>numeric_type</replaceable> )
- <returnvalue></returnvalue> <type>double precision</type>
- for <type>real</type> or <type>double precision</type>,
- otherwise <type>numeric</type>
- </para>
- <para>
- Computes the sample variance of the input values (square of the sample
- standard deviation).
- </para></entry>
- <entry>Yes</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-orderedset-table"/> shows some
- aggregate functions that use the <firstterm>ordered-set aggregate</firstterm>
- syntax. These functions are sometimes referred to as <quote>inverse
- distribution</quote> functions. Their aggregated input is introduced by
- <literal>ORDER BY</literal>, and they may also take a <firstterm>direct
- argument</firstterm> that is not aggregated, but is computed only once.
- All these functions ignore null values in their aggregated input.
- For those that take a <parameter>fraction</parameter> parameter, the
- fraction value must be between 0 and 1; an error is thrown if not.
- However, a null <parameter>fraction</parameter> value simply produces a
- null result.
- </para>
-
- <indexterm>
- <primary>ordered-set aggregate</primary>
- <secondary>built-in</secondary>
- </indexterm>
- <indexterm>
- <primary>inverse distribution</primary>
- </indexterm>
-
- <table id="functions-orderedset-table">
- <title>Ordered-Set Aggregate Functions</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="10*"/>
- <colspec colname="col2" colwidth="1*"/>
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- <entry>Partial Mode</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>mode</primary>
- <secondary>statistical</secondary>
- </indexterm>
- <function>mode</function> () <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
- <returnvalue>anyelement</returnvalue>
- </para>
- <para>
- Computes the <firstterm>mode</firstterm>, the most frequent
- value of the aggregated argument (arbitrarily choosing the first one
- if there are multiple equally-frequent values). The aggregated
- argument must be of a sortable type.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>percentile</primary>
- <secondary>continuous</secondary>
- </indexterm>
- <function>percentile_cont</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>double precision</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para role="func_signature">
- <function>percentile_cont</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Computes the <firstterm>continuous percentile</firstterm>, a value
- corresponding to the specified <parameter>fraction</parameter>
- within the ordered set of aggregated argument values. This will
- interpolate between adjacent input items if needed.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>percentile_cont</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>double precision</type> )
- <returnvalue>double precision[]</returnvalue>
- </para>
- <para role="func_signature">
- <function>percentile_cont</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>interval</type> )
- <returnvalue>interval[]</returnvalue>
- </para>
- <para>
- Computes multiple continuous percentiles. The result is an array of
- the same dimensions as the <parameter>fractions</parameter>
- parameter, with each non-null element replaced by the (possibly
- interpolated) value corresponding to that percentile.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>percentile</primary>
- <secondary>discrete</secondary>
- </indexterm>
- <function>percentile_disc</function> ( <parameter>fraction</parameter> <type>double precision</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
- <returnvalue>anyelement</returnvalue>
- </para>
- <para>
- Computes the <firstterm>discrete percentile</firstterm>, the first
- value within the ordered set of aggregated argument values whose
- position in the ordering equals or exceeds the
- specified <parameter>fraction</parameter>. The aggregated
- argument must be of a sortable type.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>percentile_disc</function> ( <parameter>fractions</parameter> <type>double precision[]</type> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <type>anyelement</type> )
- <returnvalue>anyarray</returnvalue>
- </para>
- <para>
- Computes multiple discrete percentiles. The result is an array of the
- same dimensions as the <parameter>fractions</parameter> parameter,
- with each non-null element replaced by the input value corresponding
- to that percentile.
- The aggregated argument must be of a sortable type.
- </para></entry>
- <entry>No</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <indexterm>
- <primary>hypothetical-set aggregate</primary>
- <secondary>built-in</secondary>
- </indexterm>
-
- <para>
- Each of the <quote>hypothetical-set</quote> aggregates listed in
- <xref linkend="functions-hypothetical-table"/> is associated with a
- window function of the same name defined in
- <xref linkend="functions-window"/>. In each case, the aggregate's result
- is the value that the associated window function would have
- returned for the <quote>hypothetical</quote> row constructed from
- <replaceable>args</replaceable>, if such a row had been added to the sorted
- group of rows represented by the <replaceable>sorted_args</replaceable>.
- For each of these functions, the list of direct arguments
- given in <replaceable>args</replaceable> must match the number and types of
- the aggregated arguments given in <replaceable>sorted_args</replaceable>.
- Unlike most built-in aggregates, these aggregates are not strict, that is
- they do not drop input rows containing nulls. Null values sort according
- to the rule specified in the <literal>ORDER BY</literal> clause.
- </para>
-
- <table id="functions-hypothetical-table">
- <title>Hypothetical-Set Aggregate Functions</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="10*"/>
- <colspec colname="col2" colwidth="1*"/>
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- <entry>Partial Mode</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>rank</primary>
- <secondary>hypothetical</secondary>
- </indexterm>
- <function>rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the rank of the hypothetical row, with gaps; that is, the row
- number of the first row in its peer group.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>dense_rank</primary>
- <secondary>hypothetical</secondary>
- </indexterm>
- <function>dense_rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the rank of the hypothetical row, without gaps; this function
- effectively counts peer groups.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>percent_rank</primary>
- <secondary>hypothetical</secondary>
- </indexterm>
- <function>percent_rank</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the relative rank of the hypothetical row, that is
- (<function>rank</function> - 1) / (total rows - 1).
- The value thus ranges from 0 to 1 inclusive.
- </para></entry>
- <entry>No</entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>cume_dist</primary>
- <secondary>hypothetical</secondary>
- </indexterm>
- <function>cume_dist</function> ( <replaceable>args</replaceable> ) <literal>WITHIN GROUP</literal> ( <literal>ORDER BY</literal> <replaceable>sorted_args</replaceable> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Computes the cumulative distribution, that is (number of rows
- preceding or peers with hypothetical row) / (total rows). The value
- thus ranges from 1/<parameter>N</parameter> to 1.
- </para></entry>
- <entry>No</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-grouping-table">
- <title>Grouping Operations</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>GROUPING</primary>
- </indexterm>
- <function>GROUPING</function> ( <replaceable>group_by_expression(s)</replaceable> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns a bit mask indicating which <literal>GROUP BY</literal>
- expressions are not included in the current grouping set.
- Bits are assigned with the rightmost argument corresponding to the
- least-significant bit; each bit is 0 if the corresponding expression
- is included in the grouping criteria of the grouping set generating
- the current result row, and 1 if it is not included.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The grouping operations shown in
- <xref linkend="functions-grouping-table"/> are used in conjunction with
- grouping sets (see <xref linkend="queries-grouping-sets"/>) to distinguish
- result rows. The arguments to the <literal>GROUPING</literal> function
- are not actually evaluated, but they must exactly match expressions given
- in the <literal>GROUP BY</literal> clause of the associated query level.
- For example:
-<screen>
-<prompt>=></prompt> <userinput>SELECT * FROM items_sold;</userinput>
- make | model | sales
--------+-------+-------
- Foo | GT | 10
- Foo | Tour | 20
- Bar | City | 15
- Bar | Sport | 5
-(4 rows)
-
-<prompt>=></prompt> <userinput>SELECT make, model, GROUPING(make,model), sum(sales) FROM items_sold GROUP BY ROLLUP(make,model);</userinput>
- make | model | grouping | sum
--------+-------+----------+-----
- Foo | GT | 0 | 10
- Foo | Tour | 0 | 20
- Bar | City | 0 | 15
- Bar | Sport | 0 | 5
- Foo | | 1 | 30
- Bar | | 1 | 20
- | | 3 | 50
-(7 rows)
-</screen>
- Here, the <literal>grouping</literal> value <literal>0</literal> in the
- first four rows shows that those have been grouped normally, over both the
- grouping columns. The value <literal>1</literal> indicates
- that <literal>model</literal> was not grouped by in the next-to-last two
- rows, and the value <literal>3</literal> indicates that
- neither <literal>make</literal> nor <literal>model</literal> was grouped
- by in the last row (which therefore is an aggregate over all the input
- rows).
- </para>
-
- </sect1>
+&func-aggregate;
<sect1 id="functions-window">
<title>Window Functions</title>
--
2.34.1
v1-0004-split-sect1-functions-json-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0004-split-sect1-functions-json-from-func.sgml.patchDownload
From 19feb566ae738a0292789886d830035d59d669c7 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Sat, 27 Apr 2024 09:52:10 +0800
Subject: [PATCH v1 4/7] split sect1 ("functions-json") from func.sgml
"functions-json" will live in a new file: doc/src/sgml/func-json.sgml,
it will hold functions-json.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-json.sgml | 3852 ++++++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 3853 +----------------------------------
3 files changed, 3854 insertions(+), 3852 deletions(-)
create mode 100644 doc/src/sgml/func-json.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 1b6dc08e..45330f8e 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -21,6 +21,7 @@
<!ENTITY func-string SYSTEM "func-string.sgml">
<!ENTITY func-matching SYSTEM "func-matching.sgml">
<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-json.sgml b/doc/src/sgml/func-json.sgml
new file mode 100644
index 00000000..f098553f
--- /dev/null
+++ b/doc/src/sgml/func-json.sgml
@@ -0,0 +1,3852 @@
+ <sect1 id="functions-json">
+ <title>JSON Functions and Operators</title>
+
+ <indexterm zone="functions-json">
+ <primary>JSON</primary>
+ <secondary>functions and operators</secondary>
+ </indexterm>
+ <indexterm zone="functions-json">
+ <primary>SQL/JSON</primary>
+ <secondary>functions and expressions</secondary>
+ </indexterm>
+
+ <para>
+ This section describes:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ functions and operators for processing and creating JSON data
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ the SQL/JSON path language
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ the SQL/JSON query functions
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ To provide native support for JSON data types within the SQL environment,
+ <productname>PostgreSQL</productname> implements the
+ <firstterm>SQL/JSON data model</firstterm>.
+ This model comprises sequences of items. Each item can hold SQL scalar
+ values, with an additional SQL/JSON null value, and composite data structures
+ that use JSON arrays and objects. The model is a formalization of the implied
+ data model in the JSON specification
+ <ulink url="https://datatracker.ietf.org/doc/html/rfc7159">RFC 7159</ulink>.
+ </para>
+
+ <para>
+ SQL/JSON allows you to handle JSON data alongside regular SQL data,
+ with transaction support, including:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Uploading JSON data into the database and storing it in
+ regular SQL columns as character or binary strings.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Generating JSON objects and arrays from relational data.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Querying JSON data using SQL/JSON query functions and
+ SQL/JSON path language expressions.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ To learn more about the SQL/JSON standard, see
+ <xref linkend="sqltr-19075-6"/>. For details on JSON types
+ supported in <productname>PostgreSQL</productname>,
+ see <xref linkend="datatype-json"/>.
+ </para>
+
+ <sect2 id="functions-json-processing">
+ <title>Processing and Creating JSON Data</title>
+
+ <para>
+ <xref linkend="functions-json-op-table"/> shows the operators that
+ are available for use with JSON data types (see <xref
+ linkend="datatype-json"/>).
+ In addition, the usual comparison operators shown in <xref
+ linkend="functions-comparison-op-table"/> are available for
+ <type>jsonb</type>, though not for <type>json</type>. The comparison
+ operators follow the ordering rules for B-tree operations outlined in
+ <xref linkend="json-indexing"/>.
+ See also <xref linkend="functions-aggregate"/> for the aggregate
+ function <function>json_agg</function> which aggregates record
+ values as JSON, the aggregate function
+ <function>json_object_agg</function> which aggregates pairs of values
+ into a JSON object, and their <type>jsonb</type> equivalents,
+ <function>jsonb_agg</function> and <function>jsonb_object_agg</function>.
+ </para>
+
+ <table id="functions-json-op-table">
+ <title><type>json</type> and <type>jsonb</type> Operators</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>-></literal> <type>integer</type>
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>-></literal> <type>integer</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Extracts <parameter>n</parameter>'th element of JSON array
+ (array elements are indexed from zero, but negative integers count
+ from the end).
+ </para>
+ <para>
+ <literal>'[{"a":"foo"},{"b":"bar"},{"c":"baz"}]'::json -> 2</literal>
+ <returnvalue>{"c":"baz"}</returnvalue>
+ </para>
+ <para>
+ <literal>'[{"a":"foo"},{"b":"bar"},{"c":"baz"}]'::json -> -3</literal>
+ <returnvalue>{"a":"foo"}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>-></literal> <type>text</type>
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>-></literal> <type>text</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Extracts JSON object field with the given key.
+ </para>
+ <para>
+ <literal>'{"a": {"b":"foo"}}'::json -> 'a'</literal>
+ <returnvalue>{"b":"foo"}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>->></literal> <type>integer</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>->></literal> <type>integer</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts <parameter>n</parameter>'th element of JSON array,
+ as <type>text</type>.
+ </para>
+ <para>
+ <literal>'[1,2,3]'::json ->> 2</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>->></literal> <type>text</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>->></literal> <type>text</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts JSON object field with the given key, as <type>text</type>.
+ </para>
+ <para>
+ <literal>'{"a":1,"b":2}'::json ->> 'b'</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>#></literal> <type>text[]</type>
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>#></literal> <type>text[]</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Extracts JSON sub-object at the specified path, where path elements
+ can be either field keys or array indexes.
+ </para>
+ <para>
+ <literal>'{"a": {"b": ["foo","bar"]}}'::json #> '{a,b,1}'</literal>
+ <returnvalue>"bar"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>json</type> <literal>#>></literal> <type>text[]</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <type>jsonb</type> <literal>#>></literal> <type>text[]</type>
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts JSON sub-object at the specified path as <type>text</type>.
+ </para>
+ <para>
+ <literal>'{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}'</literal>
+ <returnvalue>bar</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ The field/element/path extraction operators return NULL, rather than
+ failing, if the JSON input does not have the right structure to match
+ the request; for example if no such key or array element exists.
+ </para>
+ </note>
+
+ <para>
+ Some further operators exist only for <type>jsonb</type>, as shown
+ in <xref linkend="functions-jsonb-op-table"/>.
+ <xref linkend="json-indexing"/>
+ describes how these operators can be used to effectively search indexed
+ <type>jsonb</type> data.
+ </para>
+
+ <table id="functions-jsonb-op-table">
+ <title>Additional <type>jsonb</type> Operators</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>@></literal> <type>jsonb</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does the first JSON value contain the second?
+ (See <xref linkend="json-containment"/> for details about containment.)
+ </para>
+ <para>
+ <literal>'{"a":1, "b":2}'::jsonb @> '{"b":2}'::jsonb</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal><@</literal> <type>jsonb</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Is the first JSON value contained in the second?
+ </para>
+ <para>
+ <literal>'{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>?</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does the text string exist as a top-level key or array element within
+ the JSON value?
+ </para>
+ <para>
+ <literal>'{"a":1, "b":2}'::jsonb ? 'b'</literal>
+ <returnvalue>t</returnvalue>
+ </para>
+ <para>
+ <literal>'["a", "b", "c"]'::jsonb ? 'b'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>?|</literal> <type>text[]</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Do any of the strings in the text array exist as top-level keys or
+ array elements?
+ </para>
+ <para>
+ <literal>'{"a":1, "b":2, "c":3}'::jsonb ?| array['b', 'd']</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>?&</literal> <type>text[]</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Do all of the strings in the text array exist as top-level keys or
+ array elements?
+ </para>
+ <para>
+ <literal>'["a", "b", "c"]'::jsonb ?& array['a', 'b']</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>||</literal> <type>jsonb</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Concatenates two <type>jsonb</type> values.
+ Concatenating two arrays generates an array containing all the
+ elements of each input. Concatenating two objects generates an
+ object containing the union of their
+ keys, taking the second object's value when there are duplicate keys.
+ All other cases are treated by converting a non-array input into a
+ single-element array, and then proceeding as for two arrays.
+ Does not operate recursively: only the top-level array or object
+ structure is merged.
+ </para>
+ <para>
+ <literal>'["a", "b"]'::jsonb || '["a", "d"]'::jsonb</literal>
+ <returnvalue>["a", "b", "a", "d"]</returnvalue>
+ </para>
+ <para>
+ <literal>'{"a": "b"}'::jsonb || '{"c": "d"}'::jsonb</literal>
+ <returnvalue>{"a": "b", "c": "d"}</returnvalue>
+ </para>
+ <para>
+ <literal>'[1, 2]'::jsonb || '3'::jsonb</literal>
+ <returnvalue>[1, 2, 3]</returnvalue>
+ </para>
+ <para>
+ <literal>'{"a": "b"}'::jsonb || '42'::jsonb</literal>
+ <returnvalue>[{"a": "b"}, 42]</returnvalue>
+ </para>
+ <para>
+ To append an array to another array as a single entry, wrap it
+ in an additional layer of array, for example:
+ </para>
+ <para>
+ <literal>'[1, 2]'::jsonb || jsonb_build_array('[3, 4]'::jsonb)</literal>
+ <returnvalue>[1, 2, [3, 4]]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>-</literal> <type>text</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Deletes a key (and its value) from a JSON object, or matching string
+ value(s) from a JSON array.
+ </para>
+ <para>
+ <literal>'{"a": "b", "c": "d"}'::jsonb - 'a'</literal>
+ <returnvalue>{"c": "d"}</returnvalue>
+ </para>
+ <para>
+ <literal>'["a", "b", "c", "b"]'::jsonb - 'b'</literal>
+ <returnvalue>["a", "c"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>-</literal> <type>text[]</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Deletes all matching keys or array elements from the left operand.
+ </para>
+ <para>
+ <literal>'{"a": "b", "c": "d"}'::jsonb - '{a,c}'::text[]</literal>
+ <returnvalue>{}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>-</literal> <type>integer</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Deletes the array element with specified index (negative
+ integers count from the end). Throws an error if JSON value
+ is not an array.
+ </para>
+ <para>
+ <literal>'["a", "b"]'::jsonb - 1 </literal>
+ <returnvalue>["a"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>#-</literal> <type>text[]</type>
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Deletes the field or array element at the specified path, where path
+ elements can be either field keys or array indexes.
+ </para>
+ <para>
+ <literal>'["a", {"b":1}]'::jsonb #- '{1,b}'</literal>
+ <returnvalue>["a", {}]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>@?</literal> <type>jsonpath</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Does JSON path return any item for the specified JSON value?
+ (This is useful only with SQL-standard JSON path expressions, not
+ <link linkend="functions-sqljson-check-expressions">predicate check
+ expressions</link>, since those always return a value.)
+ </para>
+ <para>
+ <literal>'{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] ? (@ > 2)'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>jsonb</type> <literal>@@</literal> <type>jsonpath</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns the result of a JSON path predicate check for the
+ specified JSON value.
+ (This is useful only
+ with <link linkend="functions-sqljson-check-expressions">predicate
+ check expressions</link>, not SQL-standard JSON path expressions,
+ since it will return <literal>NULL</literal> if the path result is
+ not a single boolean value.)
+ </para>
+ <para>
+ <literal>'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ The <type>jsonpath</type> operators <literal>@?</literal>
+ and <literal>@@</literal> suppress the following errors: missing object
+ field or array element, unexpected JSON item type, datetime and numeric
+ errors. The <type>jsonpath</type>-related functions described below can
+ also be told to suppress these types of errors. This behavior might be
+ helpful when searching JSON document collections of varying structure.
+ </para>
+ </note>
+
+ <para>
+ <xref linkend="functions-json-creation-table"/> shows the functions that are
+ available for constructing <type>json</type> and <type>jsonb</type> values.
+ Some functions in this table have a <literal>RETURNING</literal> clause,
+ which specifies the data type returned. It must be one of <type>json</type>,
+ <type>jsonb</type>, <type>bytea</type>, a character string type (<type>text</type>,
+ <type>char</type>, <type>varchar</type>, or <type>nchar</type>), or a type
+ for which there is a cast from <type>json</type> to that type.
+ By default, the <type>json</type> type is returned.
+ </para>
+
+ <table id="functions-json-creation-table">
+ <title>JSON Creation Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_json</primary>
+ </indexterm>
+ <function>to_json</function> ( <type>anyelement</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>to_jsonb</primary>
+ </indexterm>
+ <function>to_jsonb</function> ( <type>anyelement</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Converts any SQL value to <type>json</type> or <type>jsonb</type>.
+ Arrays and composites are converted recursively to arrays and
+ objects (multidimensional arrays become arrays of arrays in JSON).
+ Otherwise, if there is a cast from the SQL data type
+ to <type>json</type>, the cast function will be used to perform the
+ conversion;<footnote>
+ <para>
+ For example, the <xref linkend="hstore"/> extension has a cast
+ from <type>hstore</type> to <type>json</type>, so that
+ <type>hstore</type> values converted via the JSON creation functions
+ will be represented as JSON objects, not as primitive string values.
+ </para>
+ </footnote>
+ otherwise, a scalar JSON value is produced. For any scalar other than
+ a number, a Boolean, or a null value, the text representation will be
+ used, with escaping as necessary to make it a valid JSON string value.
+ </para>
+ <para>
+ <literal>to_json('Fred said "Hi."'::text)</literal>
+ <returnvalue>"Fred said \"Hi.\""</returnvalue>
+ </para>
+ <para>
+ <literal>to_jsonb(row(42, 'Fred said "Hi."'::text))</literal>
+ <returnvalue>{"f1": 42, "f2": "Fred said \"Hi.\""}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>array_to_json</primary>
+ </indexterm>
+ <function>array_to_json</function> ( <type>anyarray</type> <optional>, <type>boolean</type> </optional> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para>
+ Converts an SQL array to a JSON array. The behavior is the same
+ as <function>to_json</function> except that line feeds will be added
+ between top-level array elements if the optional boolean parameter is
+ true.
+ </para>
+ <para>
+ <literal>array_to_json('{{1,5},{99,100}}'::int[])</literal>
+ <returnvalue>[[1,5],[99,100]]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <!--
+ Note that this is barely legible in the output; it looks like a
+ salad of braces and brackets. It would be better to split it out
+ in multiple lines, but that's surprisingly hard to do in a way that
+ matches in HTML and PDF output. Other standard SQL/JSON functions
+ have the same problem.
+ -->
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_array</primary></indexterm>
+ <function>json_array</function> (
+ <optional> { <replaceable>value_expression</replaceable> <optional> <literal>FORMAT JSON</literal> </optional> } <optional>, ...</optional> </optional>
+ <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
+ </para>
+ <para role="func_signature">
+ <function>json_array</function> (
+ <optional> <replaceable>query_expression</replaceable> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
+ </para>
+ <para>
+ Constructs a JSON array from either a series of
+ <replaceable>value_expression</replaceable> parameters or from the results
+ of <replaceable>query_expression</replaceable>,
+ which must be a SELECT query returning a single column. If
+ <literal>ABSENT ON NULL</literal> is specified, NULL values are ignored.
+ This is always the case if a
+ <replaceable>query_expression</replaceable> is used.
+ </para>
+ <para>
+ <literal>json_array(1,true,json '{"a":null}')</literal>
+ <returnvalue>[1, true, {"a":null}]</returnvalue>
+ </para>
+ <para>
+ <literal>json_array(SELECT * FROM (VALUES(1),(2)) t)</literal>
+ <returnvalue>[1, 2]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>row_to_json</primary>
+ </indexterm>
+ <function>row_to_json</function> ( <type>record</type> <optional>, <type>boolean</type> </optional> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para>
+ Converts an SQL composite value to a JSON object. The behavior is the
+ same as <function>to_json</function> except that line feeds will be
+ added between top-level elements if the optional boolean parameter is
+ true.
+ </para>
+ <para>
+ <literal>row_to_json(row(1,'foo'))</literal>
+ <returnvalue>{"f1":1,"f2":"foo"}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_build_array</primary>
+ </indexterm>
+ <function>json_build_array</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_build_array</primary>
+ </indexterm>
+ <function>jsonb_build_array</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Builds a possibly-heterogeneously-typed JSON array out of a variadic
+ argument list. Each argument is converted as
+ per <function>to_json</function> or <function>to_jsonb</function>.
+ </para>
+ <para>
+ <literal>json_build_array(1, 2, 'foo', 4, 5)</literal>
+ <returnvalue>[1, 2, "foo", 4, 5]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_build_object</primary>
+ </indexterm>
+ <function>json_build_object</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_build_object</primary>
+ </indexterm>
+ <function>jsonb_build_object</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Builds a JSON object out of a variadic argument list. By convention,
+ the argument list consists of alternating keys and values. Key
+ arguments are coerced to text; value arguments are converted as
+ per <function>to_json</function> or <function>to_jsonb</function>.
+ </para>
+ <para>
+ <literal>json_build_object('foo', 1, 2, row(3,'bar'))</literal>
+ <returnvalue>{"foo" : 1, "2" : {"f1":3,"f2":"bar"}}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_object</primary></indexterm>
+ <function>json_object</function> (
+ <optional> { <replaceable>key_expression</replaceable> { <literal>VALUE</literal> | ':' }
+ <replaceable>value_expression</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> }<optional>, ...</optional> </optional>
+ <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
+ <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
+ </para>
+ <para>
+ Constructs a JSON object of all the key/value pairs given,
+ or an empty object if none are given.
+ <replaceable>key_expression</replaceable> is a scalar expression
+ defining the <acronym>JSON</acronym> key, which is
+ converted to the <type>text</type> type.
+ It cannot be <literal>NULL</literal> nor can it
+ belong to a type that has a cast to the <type>json</type> type.
+ If <literal>WITH UNIQUE KEYS</literal> is specified, there must not
+ be any duplicate <replaceable>key_expression</replaceable>.
+ Any pair for which the <replaceable>value_expression</replaceable>
+ evaluates to <literal>NULL</literal> is omitted from the output
+ if <literal>ABSENT ON NULL</literal> is specified;
+ if <literal>NULL ON NULL</literal> is specified or the clause
+ omitted, the key is included with value <literal>NULL</literal>.
+ </para>
+ <para>
+ <literal>json_object('code' VALUE 'P123', 'title': 'Jaws')</literal>
+ <returnvalue>{"code" : "P123", "title" : "Jaws"}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object</primary>
+ </indexterm>
+ <function>json_object</function> ( <type>text[]</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object</primary>
+ </indexterm>
+ <function>jsonb_object</function> ( <type>text[]</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Builds a JSON object out of a text array. The array must have either
+ exactly one dimension with an even number of members, in which case
+ they are taken as alternating key/value pairs, or two dimensions
+ such that each inner array has exactly two elements, which
+ are taken as a key/value pair. All values are converted to JSON
+ strings.
+ </para>
+ <para>
+ <literal>json_object('{a, 1, b, "def", c, 3.5}')</literal>
+ <returnvalue>{"a" : "1", "b" : "def", "c" : "3.5"}</returnvalue>
+ </para>
+ <para><literal>json_object('{{a, 1}, {b, "def"}, {c, 3.5}}')</literal>
+ <returnvalue>{"a" : "1", "b" : "def", "c" : "3.5"}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>json_object</function> ( <parameter>keys</parameter> <type>text[]</type>, <parameter>values</parameter> <type>text[]</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>jsonb_object</function> ( <parameter>keys</parameter> <type>text[]</type>, <parameter>values</parameter> <type>text[]</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ This form of <function>json_object</function> takes keys and values
+ pairwise from separate text arrays. Otherwise it is identical to
+ the one-argument form.
+ </para>
+ <para>
+ <literal>json_object('{a,b}', '{1,2}')</literal>
+ <returnvalue>{"a": "1", "b": "2"}</returnvalue>
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry">
+ <para role="func_signature">
+ <indexterm><primary>json constructor</primary></indexterm>
+ <function>json</function> (
+ <replaceable>expression</replaceable>
+ <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional></optional>
+ <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional></optional> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para>
+ Converts a given expression specified as <type>text</type> or
+ <type>bytea</type> string (in UTF8 encoding) into a JSON
+ value. If <replaceable>expression</replaceable> is NULL, an
+ <acronym>SQL</acronym> null value is returned.
+ If <literal>WITH UNIQUE</literal> is specified, the
+ <replaceable>expression</replaceable> must not contain any duplicate
+ object keys.
+ </para>
+ <para>
+ <literal>json('{"a":123, "b":[true,"foo"], "a":"bar"}')</literal>
+ <returnvalue>{"a":123, "b":[true,"foo"], "a":"bar"}</returnvalue>
+ </para>
+ </entry>
+ </row>
+ <row>
+ <entry role="func_table_entry">
+ <para role="func_signature">
+ <indexterm><primary>json_scalar</primary></indexterm>
+ <function>json_scalar</function> ( <replaceable>expression</replaceable> )
+ </para>
+ <para>
+ Converts a given SQL scalar value into a JSON scalar value.
+ If the input is NULL, an <acronym>SQL</acronym> null is returned. If
+ the input is number or a boolean value, a corresponding JSON number
+ or boolean value is returned. For any other value, a JSON string is
+ returned.
+ </para>
+ <para>
+ <literal>json_scalar(123.45)</literal>
+ <returnvalue>123.45</returnvalue>
+ </para>
+ <para>
+ <literal>json_scalar(CURRENT_TIMESTAMP)</literal>
+ <returnvalue>"2022-05-10T10:51:04.62128-04:00"</returnvalue>
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry">
+ <para role="func_signature">
+ <function>json_serialize</function> (
+ <replaceable>expression</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional> )
+ </para>
+ <para>
+ Converts an SQL/JSON expression into a character or binary string. The
+ <replaceable>expression</replaceable> can be of any JSON type, any
+ character string type, or <type>bytea</type> in UTF8 encoding.
+ The returned type used in <literal> RETURNING</literal> can be any
+ character string type or <type>bytea</type>. The default is
+ <type>text</type>.
+ </para>
+ <para>
+ <literal>json_serialize('{ "a" : 1 } ' RETURNING bytea)</literal>
+ <returnvalue>\x7b20226122203a2031207d20</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-sqljson-misc" /> details SQL/JSON
+ facilities for testing JSON.
+ </para>
+
+ <table id="functions-sqljson-misc">
+ <title>SQL/JSON Testing Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function signature
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>IS JSON</primary></indexterm>
+ <replaceable>expression</replaceable> <literal>IS</literal> <optional> <literal>NOT</literal> </optional> <literal>JSON</literal>
+ <optional> { <literal>VALUE</literal> | <literal>SCALAR</literal> | <literal>ARRAY</literal> | <literal>OBJECT</literal> } </optional>
+ <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
+ </para>
+ <para>
+ This predicate tests whether <replaceable>expression</replaceable> can be
+ parsed as JSON, possibly of a specified type.
+ If <literal>SCALAR</literal> or <literal>ARRAY</literal> or
+ <literal>OBJECT</literal> is specified, the
+ test is whether or not the JSON is of that particular type. If
+ <literal>WITH UNIQUE KEYS</literal> is specified, then any object in the
+ <replaceable>expression</replaceable> is also tested to see if it
+ has duplicate keys.
+ </para>
+ <para>
+<programlisting>
+SELECT js,
+ js IS JSON "json?",
+ js IS JSON SCALAR "scalar?",
+ js IS JSON OBJECT "object?",
+ js IS JSON ARRAY "array?"
+FROM (VALUES
+ ('123'), ('"abc"'), ('{"a": "b"}'), ('[1,2]'),('abc')) foo(js);
+ js | json? | scalar? | object? | array?
+------------+-------+---------+---------+--------
+ 123 | t | t | f | f
+ "abc" | t | t | f | f
+ {"a": "b"} | t | f | t | f
+ [1,2] | t | f | f | t
+ abc | f | f | f | f
+</programlisting>
+ </para>
+ <para>
+<programlisting>
+SELECT js,
+ js IS JSON OBJECT "object?",
+ js IS JSON ARRAY "array?",
+ js IS JSON ARRAY WITH UNIQUE KEYS "array w. UK?",
+ js IS JSON ARRAY WITHOUT UNIQUE KEYS "array w/o UK?"
+FROM (VALUES ('[{"a":"1"},
+ {"b":"2","b":"3"}]')) foo(js);
+-[ RECORD 1 ]-+--------------------
+js | [{"a":"1"}, +
+ | {"b":"2","b":"3"}]
+object? | f
+array? | t
+array w. UK? | f
+array w/o UK? | t
+</programlisting>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-json-processing-table"/> shows the functions that
+ are available for processing <type>json</type> and <type>jsonb</type> values.
+ </para>
+
+ <table id="functions-json-processing-table">
+ <title>JSON Processing Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_array_elements</primary>
+ </indexterm>
+ <function>json_array_elements</function> ( <type>json</type> )
+ <returnvalue>setof json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_array_elements</primary>
+ </indexterm>
+ <function>jsonb_array_elements</function> ( <type>jsonb</type> )
+ <returnvalue>setof jsonb</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON array into a set of JSON values.
+ </para>
+ <para>
+ <literal>select * from json_array_elements('[1,true, [2,false]]')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ value
+-----------
+ 1
+ true
+ [2,false]
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_array_elements_text</primary>
+ </indexterm>
+ <function>json_array_elements_text</function> ( <type>json</type> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_array_elements_text</primary>
+ </indexterm>
+ <function>jsonb_array_elements_text</function> ( <type>jsonb</type> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON array into a set of <type>text</type> values.
+ </para>
+ <para>
+ <literal>select * from json_array_elements_text('["foo", "bar"]')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ value
+-----------
+ foo
+ bar
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_array_length</primary>
+ </indexterm>
+ <function>json_array_length</function> ( <type>json</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_array_length</primary>
+ </indexterm>
+ <function>jsonb_array_length</function> ( <type>jsonb</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of elements in the top-level JSON array.
+ </para>
+ <para>
+ <literal>json_array_length('[1,2,3,{"f1":1,"f2":[5,6]},4]')</literal>
+ <returnvalue>5</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_array_length('[]')</literal>
+ <returnvalue>0</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_each</primary>
+ </indexterm>
+ <function>json_each</function> ( <type>json</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>key</parameter> <type>text</type>,
+ <parameter>value</parameter> <type>json</type> )
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_each</primary>
+ </indexterm>
+ <function>jsonb_each</function> ( <type>jsonb</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>key</parameter> <type>text</type>,
+ <parameter>value</parameter> <type>jsonb</type> )
+ </para>
+ <para>
+ Expands the top-level JSON object into a set of key/value pairs.
+ </para>
+ <para>
+ <literal>select * from json_each('{"a":"foo", "b":"bar"}')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ key | value
+-----+-------
+ a | "foo"
+ b | "bar"
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_each_text</primary>
+ </indexterm>
+ <function>json_each_text</function> ( <type>json</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>key</parameter> <type>text</type>,
+ <parameter>value</parameter> <type>text</type> )
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_each_text</primary>
+ </indexterm>
+ <function>jsonb_each_text</function> ( <type>jsonb</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>key</parameter> <type>text</type>,
+ <parameter>value</parameter> <type>text</type> )
+ </para>
+ <para>
+ Expands the top-level JSON object into a set of key/value pairs.
+ The returned <parameter>value</parameter>s will be of
+ type <type>text</type>.
+ </para>
+ <para>
+ <literal>select * from json_each_text('{"a":"foo", "b":"bar"}')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ key | value
+-----+-------
+ a | foo
+ b | bar
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_extract_path</primary>
+ </indexterm>
+ <function>json_extract_path</function> ( <parameter>from_json</parameter> <type>json</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_extract_path</primary>
+ </indexterm>
+ <function>jsonb_extract_path</function> ( <parameter>from_json</parameter> <type>jsonb</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Extracts JSON sub-object at the specified path.
+ (This is functionally equivalent to the <literal>#></literal>
+ operator, but writing the path out as a variadic list can be more
+ convenient in some cases.)
+ </para>
+ <para>
+ <literal>json_extract_path('{"f2":{"f3":1},"f4":{"f5":99,"f6":"foo"}}', 'f4', 'f6')</literal>
+ <returnvalue>"foo"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_extract_path_text</primary>
+ </indexterm>
+ <function>json_extract_path_text</function> ( <parameter>from_json</parameter> <type>json</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_extract_path_text</primary>
+ </indexterm>
+ <function>jsonb_extract_path_text</function> ( <parameter>from_json</parameter> <type>jsonb</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Extracts JSON sub-object at the specified path as <type>text</type>.
+ (This is functionally equivalent to the <literal>#>></literal>
+ operator.)
+ </para>
+ <para>
+ <literal>json_extract_path_text('{"f2":{"f3":1},"f4":{"f5":99,"f6":"foo"}}', 'f4', 'f6')</literal>
+ <returnvalue>foo</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_object_keys</primary>
+ </indexterm>
+ <function>json_object_keys</function> ( <type>json</type> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_object_keys</primary>
+ </indexterm>
+ <function>jsonb_object_keys</function> ( <type>jsonb</type> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Returns the set of keys in the top-level JSON object.
+ </para>
+ <para>
+ <literal>select * from json_object_keys('{"f1":"abc","f2":{"f3":"a", "f4":"b"}}')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ json_object_keys
+------------------
+ f1
+ f2
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_populate_record</primary>
+ </indexterm>
+ <function>json_populate_record</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
+ <returnvalue>anyelement</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_populate_record</primary>
+ </indexterm>
+ <function>jsonb_populate_record</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>jsonb</type> )
+ <returnvalue>anyelement</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON object to a row having the composite type
+ of the <parameter>base</parameter> argument. The JSON object
+ is scanned for fields whose names match column names of the output row
+ type, and their values are inserted into those columns of the output.
+ (Fields that do not correspond to any output column name are ignored.)
+ In typical use, the value of <parameter>base</parameter> is just
+ <literal>NULL</literal>, which means that any output columns that do
+ not match any object field will be filled with nulls. However,
+ if <parameter>base</parameter> isn't <literal>NULL</literal> then
+ the values it contains will be used for unmatched columns.
+ </para>
+ <para>
+ To convert a JSON value to the SQL type of an output column, the
+ following rules are applied in sequence:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ A JSON null value is converted to an SQL null in all cases.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the output column is of type <type>json</type>
+ or <type>jsonb</type>, the JSON value is just reproduced exactly.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the output column is a composite (row) type, and the JSON value
+ is a JSON object, the fields of the object are converted to columns
+ of the output row type by recursive application of these rules.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Likewise, if the output column is an array type and the JSON value
+ is a JSON array, the elements of the JSON array are converted to
+ elements of the output array by recursive application of these
+ rules.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Otherwise, if the JSON value is a string, the contents of the
+ string are fed to the input conversion function for the column's
+ data type.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Otherwise, the ordinary text representation of the JSON value is
+ fed to the input conversion function for the column's data type.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ While the example below uses a constant JSON value, typical use would
+ be to reference a <type>json</type> or <type>jsonb</type> column
+ laterally from another table in the query's <literal>FROM</literal>
+ clause. Writing <function>json_populate_record</function> in
+ the <literal>FROM</literal> clause is good practice, since all of the
+ extracted columns are available for use without duplicate function
+ calls.
+ </para>
+ <para>
+ <literal>create type subrowtype as (d int, e text);</literal>
+ <literal>create type myrowtype as (a int, b text[], c subrowtype);</literal>
+ </para>
+ <para>
+ <literal>select * from json_populate_record(null::myrowtype,
+ '{"a": 1, "b": ["2", "a b"], "c": {"d": 4, "e": "a b c"}, "x": "foo"}')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ a | b | c
+---+-----------+-------------
+ 1 | {2,"a b"} | (4,"a b c")
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_populate_record_valid</primary>
+ </indexterm>
+ <function>jsonb_populate_record_valid</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Function for testing <function>jsonb_populate_record</function>. Returns
+ <literal>true</literal> if the input <function>jsonb_populate_record</function>
+ would finish without an error for the given input JSON object; that is, it's
+ valid input, <literal>false</literal> otherwise.
+ </para>
+ <para>
+ <literal>create type jsb_char2 as (a char(2));</literal>
+ </para>
+ <para>
+ <literal>select jsonb_populate_record_valid(NULL::jsb_char2, '{"a": "aaa"}');</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ jsonb_populate_record_valid
+-----------------------------
+ f
+(1 row)
+</programlisting>
+
+ <literal>select * from jsonb_populate_record(NULL::jsb_char2, '{"a": "aaa"}') q;</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ERROR: value too long for type character(2)
+</programlisting>
+ <literal>select jsonb_populate_record_valid(NULL::jsb_char2, '{"a": "aa"}');</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ jsonb_populate_record_valid
+-----------------------------
+ t
+(1 row)
+</programlisting>
+
+ <literal>select * from jsonb_populate_record(NULL::jsb_char2, '{"a": "aa"}') q;</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ a
+----
+ aa
+(1 row)
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_populate_recordset</primary>
+ </indexterm>
+ <function>json_populate_recordset</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
+ <returnvalue>setof anyelement</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_populate_recordset</primary>
+ </indexterm>
+ <function>jsonb_populate_recordset</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>jsonb</type> )
+ <returnvalue>setof anyelement</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON array of objects to a set of rows having
+ the composite type of the <parameter>base</parameter> argument.
+ Each element of the JSON array is processed as described above
+ for <function>json[b]_populate_record</function>.
+ </para>
+ <para>
+ <literal>create type twoints as (a int, b int);</literal>
+ </para>
+ <para>
+ <literal>select * from json_populate_recordset(null::twoints, '[{"a":1,"b":2}, {"a":3,"b":4}]')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ a | b
+---+---
+ 1 | 2
+ 3 | 4
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_to_record</primary>
+ </indexterm>
+ <function>json_to_record</function> ( <type>json</type> )
+ <returnvalue>record</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_to_record</primary>
+ </indexterm>
+ <function>jsonb_to_record</function> ( <type>jsonb</type> )
+ <returnvalue>record</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON object to a row having the composite type
+ defined by an <literal>AS</literal> clause. (As with all functions
+ returning <type>record</type>, the calling query must explicitly
+ define the structure of the record with an <literal>AS</literal>
+ clause.) The output record is filled from fields of the JSON object,
+ in the same way as described above
+ for <function>json[b]_populate_record</function>. Since there is no
+ input record value, unmatched columns are always filled with nulls.
+ </para>
+ <para>
+ <literal>create type myrowtype as (a int, b text);</literal>
+ </para>
+ <para>
+ <literal>select * from json_to_record('{"a":1,"b":[1,2,3],"c":[1,2,3],"e":"bar","r": {"a": 123, "b": "a b c"}}') as x(a int, b text, c int[], d text, r myrowtype)</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ a | b | c | d | r
+---+---------+---------+---+---------------
+ 1 | [1,2,3] | {1,2,3} | | (123,"a b c")
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_to_recordset</primary>
+ </indexterm>
+ <function>json_to_recordset</function> ( <type>json</type> )
+ <returnvalue>setof record</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_to_recordset</primary>
+ </indexterm>
+ <function>jsonb_to_recordset</function> ( <type>jsonb</type> )
+ <returnvalue>setof record</returnvalue>
+ </para>
+ <para>
+ Expands the top-level JSON array of objects to a set of rows having
+ the composite type defined by an <literal>AS</literal> clause. (As
+ with all functions returning <type>record</type>, the calling query
+ must explicitly define the structure of the record with
+ an <literal>AS</literal> clause.) Each element of the JSON array is
+ processed as described above
+ for <function>json[b]_populate_record</function>.
+ </para>
+ <para>
+ <literal>select * from json_to_recordset('[{"a":1,"b":"foo"}, {"a":"2","c":"bar"}]') as x(a int, b text)</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ a | b
+---+-----
+ 1 | foo
+ 2 |
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_set</primary>
+ </indexterm>
+ <function>jsonb_set</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>create_if_missing</parameter> <type>boolean</type> </optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Returns <parameter>target</parameter>
+ with the item designated by <parameter>path</parameter>
+ replaced by <parameter>new_value</parameter>, or with
+ <parameter>new_value</parameter> added if
+ <parameter>create_if_missing</parameter> is true (which is the
+ default) and the item designated by <parameter>path</parameter>
+ does not exist.
+ All earlier steps in the path must exist, or
+ the <parameter>target</parameter> is returned unchanged.
+ As with the path oriented operators, negative integers that
+ appear in the <parameter>path</parameter> count from the end
+ of JSON arrays.
+ If the last path step is an array index that is out of range,
+ and <parameter>create_if_missing</parameter> is true, the new
+ value is added at the beginning of the array if the index is negative,
+ or at the end of the array if it is positive.
+ </para>
+ <para>
+ <literal>jsonb_set('[{"f1":1,"f2":null},2,null,3]', '{0,f1}', '[2,3,4]', false)</literal>
+ <returnvalue>[{"f1": [2, 3, 4], "f2": null}, 2, null, 3]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_set('[{"f1":1,"f2":null},2]', '{0,f3}', '[2,3,4]')</literal>
+ <returnvalue>[{"f1": 1, "f2": null, "f3": [2, 3, 4]}, 2]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_set_lax</primary>
+ </indexterm>
+ <function>jsonb_set_lax</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>create_if_missing</parameter> <type>boolean</type> <optional>, <parameter>null_value_treatment</parameter> <type>text</type> </optional></optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ If <parameter>new_value</parameter> is not <literal>NULL</literal>,
+ behaves identically to <literal>jsonb_set</literal>. Otherwise behaves
+ according to the value
+ of <parameter>null_value_treatment</parameter> which must be one
+ of <literal>'raise_exception'</literal>,
+ <literal>'use_json_null'</literal>, <literal>'delete_key'</literal>, or
+ <literal>'return_target'</literal>. The default is
+ <literal>'use_json_null'</literal>.
+ </para>
+ <para>
+ <literal>jsonb_set_lax('[{"f1":1,"f2":null},2,null,3]', '{0,f1}', null)</literal>
+ <returnvalue>[{"f1": null, "f2": null}, 2, null, 3]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_set_lax('[{"f1":99,"f2":null},2]', '{0,f3}', null, true, 'return_target')</literal>
+ <returnvalue>[{"f1": 99, "f2": null}, 2]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_insert</primary>
+ </indexterm>
+ <function>jsonb_insert</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>insert_after</parameter> <type>boolean</type> </optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Returns <parameter>target</parameter>
+ with <parameter>new_value</parameter> inserted. If the item
+ designated by the <parameter>path</parameter> is an array
+ element, <parameter>new_value</parameter> will be inserted before
+ that item if <parameter>insert_after</parameter> is false (which
+ is the default), or after it
+ if <parameter>insert_after</parameter> is true. If the item
+ designated by the <parameter>path</parameter> is an object
+ field, <parameter>new_value</parameter> will be inserted only if
+ the object does not already contain that key.
+ All earlier steps in the path must exist, or
+ the <parameter>target</parameter> is returned unchanged.
+ As with the path oriented operators, negative integers that
+ appear in the <parameter>path</parameter> count from the end
+ of JSON arrays.
+ If the last path step is an array index that is out of range, the new
+ value is added at the beginning of the array if the index is negative,
+ or at the end of the array if it is positive.
+ </para>
+ <para>
+ <literal>jsonb_insert('{"a": [0,1,2]}', '{a, 1}', '"new_value"')</literal>
+ <returnvalue>{"a": [0, "new_value", 1, 2]}</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_insert('{"a": [0,1,2]}', '{a, 1}', '"new_value"', true)</literal>
+ <returnvalue>{"a": [0, 1, "new_value", 2]}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_strip_nulls</primary>
+ </indexterm>
+ <function>json_strip_nulls</function> ( <type>json</type> )
+ <returnvalue>json</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_strip_nulls</primary>
+ </indexterm>
+ <function>jsonb_strip_nulls</function> ( <type>jsonb</type> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Deletes all object fields that have null values from the given JSON
+ value, recursively. Null values that are not object fields are
+ untouched.
+ </para>
+ <para>
+ <literal>json_strip_nulls('[{"f1":1, "f2":null}, 2, null, 3]')</literal>
+ <returnvalue>[{"f1":1},2,null,3]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_exists</primary>
+ </indexterm>
+ <function>jsonb_path_exists</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Checks whether the JSON path returns any item for the specified JSON
+ value.
+ (This is useful only with SQL-standard JSON path expressions, not
+ <link linkend="functions-sqljson-check-expressions">predicate check
+ expressions</link>, since those always return a value.)
+ If the <parameter>vars</parameter> argument is specified, it must
+ be a JSON object, and its fields provide named values to be
+ substituted into the <type>jsonpath</type> expression.
+ If the <parameter>silent</parameter> argument is specified and
+ is <literal>true</literal>, the function suppresses the same errors
+ as the <literal>@?</literal> and <literal>@@</literal> operators do.
+ </para>
+ <para>
+ <literal>jsonb_path_exists('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_match</primary>
+ </indexterm>
+ <function>jsonb_path_match</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns the result of a JSON path predicate check for the specified
+ JSON value.
+ (This is useful only
+ with <link linkend="functions-sqljson-check-expressions">predicate
+ check expressions</link>, not SQL-standard JSON path expressions,
+ since it will either fail or return <literal>NULL</literal> if the
+ path result is not a single boolean value.)
+ The optional <parameter>vars</parameter>
+ and <parameter>silent</parameter> arguments act the same as
+ for <function>jsonb_path_exists</function>.
+ </para>
+ <para>
+ <literal>jsonb_path_match('{"a":[1,2,3,4,5]}', 'exists($.a[*] ? (@ >= $min && @ <= $max))', '{"min":2, "max":4}')</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query</primary>
+ </indexterm>
+ <function>jsonb_path_query</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>setof jsonb</returnvalue>
+ </para>
+ <para>
+ Returns all JSON items returned by the JSON path for the specified
+ JSON value.
+ For SQL-standard JSON path expressions it returns the JSON
+ values selected from <parameter>target</parameter>.
+ For <link linkend="functions-sqljson-check-expressions">predicate
+ check expressions</link> it returns the result of the predicate
+ check: <literal>true</literal>, <literal>false</literal>,
+ or <literal>null</literal>.
+ The optional <parameter>vars</parameter>
+ and <parameter>silent</parameter> arguments act the same as
+ for <function>jsonb_path_exists</function>.
+ </para>
+ <para>
+ <literal>select * from jsonb_path_query('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ jsonb_path_query
+------------------
+ 2
+ 3
+ 4
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query_array</primary>
+ </indexterm>
+ <function>jsonb_path_query_array</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Returns all JSON items returned by the JSON path for the specified
+ JSON value, as a JSON array.
+ The parameters are the same as
+ for <function>jsonb_path_query</function>.
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
+ <returnvalue>[2, 3, 4]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query_first</primary>
+ </indexterm>
+ <function>jsonb_path_query_first</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ Returns the first JSON item returned by the JSON path for the
+ specified JSON value, or <literal>NULL</literal> if there are no
+ results.
+ The parameters are the same as
+ for <function>jsonb_path_query</function>.
+ </para>
+ <para>
+ <literal>jsonb_path_query_first('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_exists_tz</primary>
+ </indexterm>
+ <function>jsonb_path_exists_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_match_tz</primary>
+ </indexterm>
+ <function>jsonb_path_match_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query_tz</primary>
+ </indexterm>
+ <function>jsonb_path_query_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>setof jsonb</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query_array_tz</primary>
+ </indexterm>
+ <function>jsonb_path_query_array_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_path_query_first_tz</primary>
+ </indexterm>
+ <function>jsonb_path_query_first_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
+ <returnvalue>jsonb</returnvalue>
+ </para>
+ <para>
+ These functions act like their counterparts described above without
+ the <literal>_tz</literal> suffix, except that these functions support
+ comparisons of date/time values that require timezone-aware
+ conversions. The example below requires interpretation of the
+ date-only value <literal>2015-08-02</literal> as a timestamp with time
+ zone, so the result depends on the current
+ <xref linkend="guc-timezone"/> setting. Due to this dependency, these
+ functions are marked as stable, which means these functions cannot be
+ used in indexes. Their counterparts are immutable, and so can be used
+ in indexes; but they will throw errors if asked to make such
+ comparisons.
+ </para>
+ <para>
+ <literal>jsonb_path_exists_tz('["2015-08-01 12:00:00-05"]', '$[*] ? (@.datetime() < "2015-08-02".datetime())')</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>jsonb_pretty</primary>
+ </indexterm>
+ <function>jsonb_pretty</function> ( <type>jsonb</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts the given JSON value to pretty-printed, indented text.
+ </para>
+ <para>
+ <literal>jsonb_pretty('[{"f1":1,"f2":null}, 2]')</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+[
+ {
+ "f1": 1,
+ "f2": null
+ },
+ 2
+]
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>json_typeof</primary>
+ </indexterm>
+ <function>json_typeof</function> ( <type>json</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <indexterm>
+ <primary>jsonb_typeof</primary>
+ </indexterm>
+ <function>jsonb_typeof</function> ( <type>jsonb</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the type of the top-level JSON value as a text string.
+ Possible types are
+ <literal>object</literal>, <literal>array</literal>,
+ <literal>string</literal>, <literal>number</literal>,
+ <literal>boolean</literal>, and <literal>null</literal>.
+ (The <literal>null</literal> result should not be confused
+ with an SQL NULL; see the examples.)
+ </para>
+ <para>
+ <literal>json_typeof('-123.4')</literal>
+ <returnvalue>number</returnvalue>
+ </para>
+ <para>
+ <literal>json_typeof('null'::json)</literal>
+ <returnvalue>null</returnvalue>
+ </para>
+ <para>
+ <literal>json_typeof(NULL::json) IS NULL</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </sect2>
+
+ <sect2 id="functions-sqljson-path">
+ <title>The SQL/JSON Path Language</title>
+
+ <indexterm zone="functions-sqljson-path">
+ <primary>SQL/JSON path language</primary>
+ </indexterm>
+
+ <para>
+ SQL/JSON path expressions specify item(s) to be retrieved
+ from a JSON value, similarly to XPath expressions used
+ for access to XML content. In <productname>PostgreSQL</productname>,
+ path expressions are implemented as the <type>jsonpath</type>
+ data type and can use any elements described in
+ <xref linkend="datatype-jsonpath"/>.
+ </para>
+
+ <para>
+ JSON query functions and operators
+ pass the provided path expression to the <firstterm>path engine</firstterm>
+ for evaluation. If the expression matches the queried JSON data,
+ the corresponding JSON item, or set of items, is returned.
+ If there is no match, the result will be <literal>NULL</literal>,
+ <literal>false</literal>, or an error, depending on the function.
+ Path expressions are written in the SQL/JSON path language
+ and can include arithmetic expressions and functions.
+ </para>
+
+ <para>
+ A path expression consists of a sequence of elements allowed
+ by the <type>jsonpath</type> data type.
+ The path expression is normally evaluated from left to right, but
+ you can use parentheses to change the order of operations.
+ If the evaluation is successful, a sequence of JSON items is produced,
+ and the evaluation result is returned to the JSON query function
+ that completes the specified computation.
+ </para>
+
+ <para>
+ To refer to the JSON value being queried (the
+ <firstterm>context item</firstterm>), use the <literal>$</literal> variable
+ in the path expression. The first element of a path must always
+ be <literal>$</literal>. It can be followed by one or more
+ <link linkend="type-jsonpath-accessors">accessor operators</link>,
+ which go down the JSON structure level by level to retrieve sub-items
+ of the context item. Each accessor operator acts on the
+ result(s) of the previous evaluation step, producing zero, one, or more
+ output items from each input item.
+ </para>
+
+ <para>
+ For example, suppose you have some JSON data from a GPS tracker that you
+ would like to parse, such as:
+<programlisting>
+SELECT '{
+ "track": {
+ "segments": [
+ {
+ "location": [ 47.763, 13.4034 ],
+ "start time": "2018-10-14 10:05:14",
+ "HR": 73
+ },
+ {
+ "location": [ 47.706, 13.2635 ],
+ "start time": "2018-10-14 10:39:21",
+ "HR": 135
+ }
+ ]
+ }
+}' AS json \gset
+</programlisting>
+ (The above example can be copied-and-pasted
+ into <application>psql</application> to set things up for the following
+ examples. Then <application>psql</application> will
+ expand <literal>:'json'</literal> into a suitably-quoted string
+ constant containing the JSON value.)
+ </para>
+
+ <para>
+ To retrieve the available track segments, you need to use the
+ <literal>.<replaceable>key</replaceable></literal> accessor
+ operator to descend through surrounding JSON objects, for example:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments');</userinput>
+ jsonb_path_query
+-----------------------------------------------------------&zwsp;-----------------------------------------------------------&zwsp;---------------------------------------------
+ [{"HR": 73, "location": [47.763, 13.4034], "start time": "2018-10-14 10:05:14"}, {"HR": 135, "location": [47.706, 13.2635], "start time": "2018-10-14 10:39:21"}]
+</screen>
+ </para>
+
+ <para>
+ To retrieve the contents of an array, you typically use the
+ <literal>[*]</literal> operator.
+ The following example will return the location coordinates for all
+ the available track segments:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].location');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+ [47.706, 13.2635]
+</screen>
+ Here we started with the whole JSON input value (<literal>$</literal>),
+ then the <literal>.track</literal> accessor selected the JSON object
+ associated with the <literal>"track"</literal> object key, then
+ the <literal>.segments</literal> accessor selected the JSON array
+ associated with the <literal>"segments"</literal> key within that
+ object, then the <literal>[*]</literal> accessor selected each element
+ of that array (producing a series of items), then
+ the <literal>.location</literal> accessor selected the JSON array
+ associated with the <literal>"location"</literal> key within each of
+ those objects. In this example, each of those objects had
+ a <literal>"location"</literal> key; but if any of them did not,
+ the <literal>.location</literal> accessor would have simply produced no
+ output for that input item.
+ </para>
+
+ <para>
+ To return the coordinates of the first segment only, you can
+ specify the corresponding subscript in the <literal>[]</literal>
+ accessor operator. Recall that JSON array indexes are 0-relative:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[0].location');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+</screen>
+ </para>
+
+ <para>
+ The result of each path evaluation step can be processed
+ by one or more of the <type>jsonpath</type> operators and methods
+ listed in <xref linkend="functions-sqljson-path-operators"/>.
+ Each method name must be preceded by a dot. For example,
+ you can get the size of an array:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments.size()');</userinput>
+ jsonb_path_query
+------------------
+ 2
+</screen>
+ More examples of using <type>jsonpath</type> operators
+ and methods within path expressions appear below in
+ <xref linkend="functions-sqljson-path-operators"/>.
+ </para>
+
+ <para>
+ A path can also contain
+ <firstterm>filter expressions</firstterm> that work similarly to the
+ <literal>WHERE</literal> clause in SQL. A filter expression begins with
+ a question mark and provides a condition in parentheses:
+
+<synopsis>
+? (<replaceable>condition</replaceable>)
+</synopsis>
+ </para>
+
+ <para>
+ Filter expressions must be written just after the path evaluation step
+ to which they should apply. The result of that step is filtered to include
+ only those items that satisfy the provided condition. SQL/JSON defines
+ three-valued logic, so the condition can
+ produce <literal>true</literal>, <literal>false</literal>,
+ or <literal>unknown</literal>. The <literal>unknown</literal> value
+ plays the same role as SQL <literal>NULL</literal> and can be tested
+ for with the <literal>is unknown</literal> predicate. Further path
+ evaluation steps use only those items for which the filter expression
+ returned <literal>true</literal>.
+ </para>
+
+ <para>
+ The functions and operators that can be used in filter expressions are
+ listed in <xref linkend="functions-sqljson-filter-ex-table"/>. Within a
+ filter expression, the <literal>@</literal> variable denotes the value
+ being considered (i.e., one result of the preceding path step). You can
+ write accessor operators after <literal>@</literal> to retrieve component
+ items.
+ </para>
+
+ <para>
+ For example, suppose you would like to retrieve all heart rate values higher
+ than 130. You can achieve this as follows:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].HR ? (@ > 130)');</userinput>
+ jsonb_path_query
+------------------
+ 135
+</screen>
+ </para>
+
+ <para>
+ To get the start times of segments with such values, you have to
+ filter out irrelevant segments before selecting the start times, so the
+ filter expression is applied to the previous step, and the path used
+ in the condition is different:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.HR > 130)."start time"');</userinput>
+ jsonb_path_query
+-----------------------
+ "2018-10-14 10:39:21"
+</screen>
+ </para>
+
+ <para>
+ You can use several filter expressions in sequence, if required.
+ The following example selects start times of all segments that
+ contain locations with relevant coordinates and high heart rate values:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.location[1] < 13.4) ? (@.HR > 130)."start time"');</userinput>
+ jsonb_path_query
+-----------------------
+ "2018-10-14 10:39:21"
+</screen>
+ </para>
+
+ <para>
+ Using filter expressions at different nesting levels is also allowed.
+ The following example first filters all segments by location, and then
+ returns high heart rate values for these segments, if available:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.location[1] < 13.4).HR ? (@ > 130)');</userinput>
+ jsonb_path_query
+------------------
+ 135
+</screen>
+ </para>
+
+ <para>
+ You can also nest filter expressions within each other.
+ This example returns the size of the track if it contains any
+ segments with high heart rate values, or an empty sequence otherwise:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track ? (exists(@.segments[*] ? (@.HR > 130))).segments.size()');</userinput>
+ jsonb_path_query
+------------------
+ 2
+</screen>
+ </para>
+
+ <sect3 id="functions-sqljson-deviations">
+ <title>Deviations from the SQL Standard</title>
+ <para>
+ <productname>PostgreSQL</productname>'s implementation of the SQL/JSON path
+ language has the following deviations from the SQL/JSON standard.
+ </para>
+
+ <sect4 id="functions-sqljson-check-expressions">
+ <title>Boolean Predicate Check Expressions</title>
+ <para>
+ As an extension to the SQL standard,
+ a <productname>PostgreSQL</productname> path expression can be a
+ Boolean predicate, whereas the SQL standard allows predicates only within
+ filters. While SQL-standard path expressions return the relevant
+ element(s) of the queried JSON value, predicate check expressions
+ return the single three-valued result of the
+ predicate: <literal>true</literal>,
+ <literal>false</literal>, or <literal>unknown</literal>.
+ For example, we could write this SQL-standard filter expression:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments ?(@[*].HR > 130)');</userinput>
+ jsonb_path_query
+-----------------------------------------------------------&zwsp;----------------------
+ {"HR": 135, "location": [47.706, 13.2635], "start time": "2018-10-14 10:39:21"}
+</screen>
+ The similar predicate check expression simply
+ returns <literal>true</literal>, indicating that a match exists:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].HR > 130');</userinput>
+ jsonb_path_query
+------------------
+ true
+</screen>
+ </para>
+
+ <note>
+ <para>
+ Predicate check expressions are required in the
+ <literal>@@</literal> operator (and the
+ <function>jsonb_path_match</function> function), and should not be used
+ with the <literal>@?</literal> operator (or the
+ <function>jsonb_path_exists</function> function).
+ </para>
+ </note>
+ </sect4>
+
+ <sect4 id="functions-sqljson-regular-expression-deviation">
+ <title>Regular Expression Interpretation</title>
+ <para>
+ There are minor differences in the interpretation of regular
+ expression patterns used in <literal>like_regex</literal> filters, as
+ described in <xref linkend="jsonpath-regular-expressions"/>.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3 id="functions-sqljson-strict-and-lax-modes">
+ <title>Strict and Lax Modes</title>
+ <para>
+ When you query JSON data, the path expression may not match the
+ actual JSON data structure. An attempt to access a non-existent
+ member of an object or element of an array is defined as a
+ structural error. SQL/JSON path expressions have two modes
+ of handling structural errors:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ lax (default) — the path engine implicitly adapts
+ the queried data to the specified path.
+ Any structural errors that cannot be fixed as described below
+ are suppressed, producing no match.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ strict — if a structural error occurs, an error is raised.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Lax mode facilitates matching of a JSON document and path
+ expression when the JSON data does not conform to the expected schema.
+ If an operand does not match the requirements of a particular operation,
+ it can be automatically wrapped as an SQL/JSON array, or unwrapped by
+ converting its elements into an SQL/JSON sequence before performing
+ the operation. Also, comparison operators automatically unwrap their
+ operands in lax mode, so you can compare SQL/JSON arrays
+ out-of-the-box. An array of size 1 is considered equal to its sole element.
+ Automatic unwrapping is not performed when:
+ <itemizedlist>
+ <listitem>
+ <para>
+ The path expression contains <literal>type()</literal> or
+ <literal>size()</literal> methods that return the type
+ and the number of elements in the array, respectively.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The queried JSON data contain nested arrays. In this case, only
+ the outermost array is unwrapped, while all the inner arrays
+ remain unchanged. Thus, implicit unwrapping can only go one
+ level down within each path evaluation step.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ For example, when querying the GPS data listed above, you can
+ abstract from the fact that it stores an array of segments
+ when using lax mode:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments.location');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+ [47.706, 13.2635]
+</screen>
+ </para>
+
+ <para>
+ In strict mode, the specified path must exactly match the structure of
+ the queried JSON document, so using this path
+ expression will cause an error:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments.location');</userinput>
+ERROR: jsonpath member accessor can only be applied to an object
+</screen>
+ To get the same result as in lax mode, you have to explicitly unwrap the
+ <literal>segments</literal> array:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments[*].location');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+ [47.706, 13.2635]
+</screen>
+ </para>
+
+ <para>
+ The unwrapping behavior of lax mode can lead to surprising results. For
+ instance, the following query using the <literal>.**</literal> accessor
+ selects every <literal>HR</literal> value twice:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.**.HR');</userinput>
+ jsonb_path_query
+------------------
+ 73
+ 135
+ 73
+ 135
+</screen>
+ This happens because the <literal>.**</literal> accessor selects both
+ the <literal>segments</literal> array and each of its elements, while
+ the <literal>.HR</literal> accessor automatically unwraps arrays when
+ using lax mode. To avoid surprising results, we recommend using
+ the <literal>.**</literal> accessor only in strict mode. The
+ following query selects each <literal>HR</literal> value just once:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.**.HR');</userinput>
+ jsonb_path_query
+------------------
+ 73
+ 135
+</screen>
+ </para>
+
+ <para>
+ The unwrapping of arrays can also lead to unexpected results. Consider this
+ example, which selects all the <literal>location</literal> arrays:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments[*].location');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+ [47.706, 13.2635]
+(2 rows)
+</screen>
+ As expected it returns the full arrays. But applying a filter expression
+ causes the arrays to be unwrapped to evaluate each item, returning only the
+ items that match the expression:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments[*].location ?(@[*] > 15)');</userinput>
+ jsonb_path_query
+------------------
+ 47.763
+ 47.706
+(2 rows)
+</screen>
+ This despite the fact that the full arrays are selected by the path
+ expression. Use strict mode to restore selecting the arrays:
+<screen>
+<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments[*].location ?(@[*] > 15)');</userinput>
+ jsonb_path_query
+-------------------
+ [47.763, 13.4034]
+ [47.706, 13.2635]
+(2 rows)
+</screen>
+ </para>
+ </sect3>
+
+ <sect3 id="functions-sqljson-path-operators">
+ <title>SQL/JSON Path Operators and Methods</title>
+
+ <para>
+ <xref linkend="functions-sqljson-op-table"/> shows the operators and
+ methods available in <type>jsonpath</type>. Note that while the unary
+ operators and methods can be applied to multiple values resulting from a
+ preceding path step, the binary operators (addition etc.) can only be
+ applied to single values.
+ </para>
+
+ <table id="functions-sqljson-op-table">
+ <title><type>jsonpath</type> Operators and Methods</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator/Method
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>+</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Addition
+ </para>
+ <para>
+ <literal>jsonb_path_query('[2]', '$[0] + 3')</literal>
+ <returnvalue>5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>+</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Unary plus (no operation); unlike addition, this can iterate over
+ multiple values
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('{"x": [2,3,4]}', '+ $.x')</literal>
+ <returnvalue>[2, 3, 4]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>-</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Subtraction
+ </para>
+ <para>
+ <literal>jsonb_path_query('[2]', '7 - $[0]')</literal>
+ <returnvalue>5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>-</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Negation; unlike subtraction, this can iterate over
+ multiple values
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('{"x": [2,3,4]}', '- $.x')</literal>
+ <returnvalue>[-2, -3, -4]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>*</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Multiplication
+ </para>
+ <para>
+ <literal>jsonb_path_query('[4]', '2 * $[0]')</literal>
+ <returnvalue>8</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>/</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Division
+ </para>
+ <para>
+ <literal>jsonb_path_query('[8.5]', '$[0] / 2')</literal>
+ <returnvalue>4.2500000000000000</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>%</literal> <replaceable>number</replaceable>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Modulo (remainder)
+ </para>
+ <para>
+ <literal>jsonb_path_query('[32]', '$[0] % 10')</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>type()</literal>
+ <returnvalue><replaceable>string</replaceable></returnvalue>
+ </para>
+ <para>
+ Type of the JSON item (see <function>json_typeof</function>)
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, "2", {}]', '$[*].type()')</literal>
+ <returnvalue>["number", "string", "object"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>size()</literal>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Size of the JSON item (number of array elements, or 1 if not an
+ array)
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"m": [11, 15]}', '$.m.size()')</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>boolean()</literal>
+ <returnvalue><replaceable>boolean</replaceable></returnvalue>
+ </para>
+ <para>
+ Boolean value converted from a JSON boolean, number, or string
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, "yes", false]', '$[*].boolean()')</literal>
+ <returnvalue>[true, true, false]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>string()</literal>
+ <returnvalue><replaceable>string</replaceable></returnvalue>
+ </para>
+ <para>
+ String value converted from a JSON boolean, number, string, or datetime
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1.23, "xyz", false]', '$[*].string()')</literal>
+ <returnvalue>["1.23", "xyz", "false"]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15"', '$.datetime().string()')</literal>
+ <returnvalue>"2023-08-15"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>double()</literal>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Approximate floating-point number converted from a JSON number or
+ string
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"len": "1.9"}', '$.len.double() * 2')</literal>
+ <returnvalue>3.8</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>.</literal> <literal>ceiling()</literal>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Nearest integer greater than or equal to the given number
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"h": 1.3}', '$.h.ceiling()')</literal>
+ <returnvalue>2</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>.</literal> <literal>floor()</literal>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Nearest integer less than or equal to the given number
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"h": 1.7}', '$.h.floor()')</literal>
+ <returnvalue>1</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>number</replaceable> <literal>.</literal> <literal>abs()</literal>
+ <returnvalue><replaceable>number</replaceable></returnvalue>
+ </para>
+ <para>
+ Absolute value of the given number
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"z": -0.3}', '$.z.abs()')</literal>
+ <returnvalue>0.3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>bigint()</literal>
+ <returnvalue><replaceable>bigint</replaceable></returnvalue>
+ </para>
+ <para>
+ Big integer value converted from a JSON number or string
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"len": "9876543219"}', '$.len.bigint()')</literal>
+ <returnvalue>9876543219</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>decimal( [ <replaceable>precision</replaceable> [ , <replaceable>scale</replaceable> ] ] )</literal>
+ <returnvalue><replaceable>decimal</replaceable></returnvalue>
+ </para>
+ <para>
+ Rounded decimal value converted from a JSON number or string. <literal>precision</literal> and <literal>scale</literal> must be integer values.
+ </para>
+ <para>
+ <literal>jsonb_path_query('1234.5678', '$.decimal(6, 2)')</literal>
+ <returnvalue>1234.57</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>integer()</literal>
+ <returnvalue><replaceable>integer</replaceable></returnvalue>
+ </para>
+ <para>
+ Integer value converted from a JSON number or string
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"len": "12345"}', '$.len.integer()')</literal>
+ <returnvalue>12345</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>.</literal> <literal>number()</literal>
+ <returnvalue><replaceable>numeric</replaceable></returnvalue>
+ </para>
+ <para>
+ Numeric value converted from a JSON number or string
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"len": "123.45"}', '$.len.number()')</literal>
+ <returnvalue>123.45</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>datetime()</literal>
+ <returnvalue><replaceable>datetime_type</replaceable></returnvalue>
+ (see note)
+ </para>
+ <para>
+ Date/time value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('["2015-8-1", "2015-08-12"]', '$[*] ? (@.datetime() < "2015-08-2".datetime())')</literal>
+ <returnvalue>"2015-8-1"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>datetime(<replaceable>template</replaceable>)</literal>
+ <returnvalue><replaceable>datetime_type</replaceable></returnvalue>
+ (see note)
+ </para>
+ <para>
+ Date/time value converted from a string using the
+ specified <function>to_timestamp</function> template
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('["12:30", "18:40"]', '$[*].datetime("HH24:MI")')</literal>
+ <returnvalue>["12:30:00", "18:40:00"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>date()</literal>
+ <returnvalue><replaceable>date</replaceable></returnvalue>
+ </para>
+ <para>
+ Date value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15"', '$.date()')</literal>
+ <returnvalue>"2023-08-15"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>time()</literal>
+ <returnvalue><replaceable>time without time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Time without time zone value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('"12:34:56"', '$.time()')</literal>
+ <returnvalue>"12:34:56"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>time(<replaceable>precision</replaceable>)</literal>
+ <returnvalue><replaceable>time without time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Time without time zone value converted from a string, with fractional
+ seconds adjusted to the given precision.
+ </para>
+ <para>
+ <literal>jsonb_path_query('"12:34:56.789"', '$.time(2)')</literal>
+ <returnvalue>"12:34:56.79"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>time_tz()</literal>
+ <returnvalue><replaceable>time with time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Time with time zone value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('"12:34:56 +05:30"', '$.time_tz()')</literal>
+ <returnvalue>"12:34:56+05:30"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>time_tz(<replaceable>precision</replaceable>)</literal>
+ <returnvalue><replaceable>time with time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Time with time zone value converted from a string, with fractional
+ seconds adjusted to the given precision.
+ </para>
+ <para>
+ <literal>jsonb_path_query('"12:34:56.789 +05:30"', '$.time_tz(2)')</literal>
+ <returnvalue>"12:34:56.79+05:30"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp()</literal>
+ <returnvalue><replaceable>timestamp without time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Timestamp without time zone value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15 12:34:56"', '$.timestamp()')</literal>
+ <returnvalue>"2023-08-15T12:34:56"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp(<replaceable>precision</replaceable>)</literal>
+ <returnvalue><replaceable>timestamp without time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Timestamp without time zone value converted from a string, with
+ fractional seconds adjusted to the given precision.
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15 12:34:56.789"', '$.timestamp(2)')</literal>
+ <returnvalue>"2023-08-15T12:34:56.79"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp_tz()</literal>
+ <returnvalue><replaceable>timestamp with time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Timestamp with time zone value converted from a string
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15 12:34:56 +05:30"', '$.timestamp_tz()')</literal>
+ <returnvalue>"2023-08-15T12:34:56+05:30"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp_tz(<replaceable>precision</replaceable>)</literal>
+ <returnvalue><replaceable>timestamp with time zone</replaceable></returnvalue>
+ </para>
+ <para>
+ Timestamp with time zone value converted from a string, with fractional
+ seconds adjusted to the given precision.
+ </para>
+ <para>
+ <literal>jsonb_path_query('"2023-08-15 12:34:56.789 +05:30"', '$.timestamp_tz(2)')</literal>
+ <returnvalue>"2023-08-15T12:34:56.79+05:30"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>object</replaceable> <literal>.</literal> <literal>keyvalue()</literal>
+ <returnvalue><replaceable>array</replaceable></returnvalue>
+ </para>
+ <para>
+ The object's key-value pairs, represented as an array of objects
+ containing three fields: <literal>"key"</literal>,
+ <literal>"value"</literal>, and <literal>"id"</literal>;
+ <literal>"id"</literal> is a unique identifier of the object the
+ key-value pair belongs to
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('{"x": "20", "y": 32}', '$.keyvalue()')</literal>
+ <returnvalue>[{"id": 0, "key": "x", "value": "20"}, {"id": 0, "key": "y", "value": 32}]</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ The result type of the <literal>datetime()</literal> and
+ <literal>datetime(<replaceable>template</replaceable>)</literal>
+ methods can be <type>date</type>, <type>timetz</type>, <type>time</type>,
+ <type>timestamptz</type>, or <type>timestamp</type>.
+ Both methods determine their result type dynamically.
+ </para>
+ <para>
+ The <literal>datetime()</literal> method sequentially tries to
+ match its input string to the ISO formats
+ for <type>date</type>, <type>timetz</type>, <type>time</type>,
+ <type>timestamptz</type>, and <type>timestamp</type>. It stops on
+ the first matching format and emits the corresponding data type.
+ </para>
+ <para>
+ The <literal>datetime(<replaceable>template</replaceable>)</literal>
+ method determines the result type according to the fields used in the
+ provided template string.
+ </para>
+ <para>
+ The <literal>datetime()</literal> and
+ <literal>datetime(<replaceable>template</replaceable>)</literal> methods
+ use the same parsing rules as the <literal>to_timestamp</literal> SQL
+ function does (see <xref linkend="functions-formatting"/>), with three
+ exceptions. First, these methods don't allow unmatched template
+ patterns. Second, only the following separators are allowed in the
+ template string: minus sign, period, solidus (slash), comma, apostrophe,
+ semicolon, colon and space. Third, separators in the template string
+ must exactly match the input string.
+ </para>
+ <para>
+ If different date/time types need to be compared, an implicit cast is
+ applied. A <type>date</type> value can be cast to <type>timestamp</type>
+ or <type>timestamptz</type>, <type>timestamp</type> can be cast to
+ <type>timestamptz</type>, and <type>time</type> to <type>timetz</type>.
+ However, all but the first of these conversions depend on the current
+ <xref linkend="guc-timezone"/> setting, and thus can only be performed
+ within timezone-aware <type>jsonpath</type> functions. Similarly, other
+ date/time-related methods that convert strings to date/time types
+ also do this casting, which may involve the current
+ <xref linkend="guc-timezone"/> setting. Therefore, these conversions can
+ also only be performed within timezone-aware <type>jsonpath</type>
+ functions.
+ </para>
+ </note>
+
+ <para>
+ <xref linkend="functions-sqljson-filter-ex-table"/> shows the available
+ filter expression elements.
+ </para>
+
+ <table id="functions-sqljson-filter-ex-table">
+ <title><type>jsonpath</type> Filter Expression Elements</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Predicate/Value
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>==</literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Equality comparison (this, and the other comparison operators, work on
+ all JSON scalar values)
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, "a", 1, 3]', '$[*] ? (@ == 1)')</literal>
+ <returnvalue>[1, 1]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, "a", 1, 3]', '$[*] ? (@ == "a")')</literal>
+ <returnvalue>["a"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>!=</literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <replaceable>value</replaceable> <literal><></literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Non-equality comparison
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, 2, 1, 3]', '$[*] ? (@ != 1)')</literal>
+ <returnvalue>[2, 3]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('["a", "b", "c"]', '$[*] ? (@ <> "b")')</literal>
+ <returnvalue>["a", "c"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal><</literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Less-than comparison
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ < 2)')</literal>
+ <returnvalue>[1]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal><=</literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Less-than-or-equal-to comparison
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('["a", "b", "c"]', '$[*] ? (@ <= "b")')</literal>
+ <returnvalue>["a", "b"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>></literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Greater-than comparison
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ > 2)')</literal>
+ <returnvalue>[3]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>value</replaceable> <literal>>=</literal> <replaceable>value</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Greater-than-or-equal-to comparison
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ >= 2)')</literal>
+ <returnvalue>[2, 3]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>true</literal>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ JSON constant <literal>true</literal>
+ </para>
+ <para>
+ <literal>jsonb_path_query('[{"name": "John", "parent": false}, {"name": "Chris", "parent": true}]', '$[*] ? (@.parent == true)')</literal>
+ <returnvalue>{"name": "Chris", "parent": true}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>false</literal>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ JSON constant <literal>false</literal>
+ </para>
+ <para>
+ <literal>jsonb_path_query('[{"name": "John", "parent": false}, {"name": "Chris", "parent": true}]', '$[*] ? (@.parent == false)')</literal>
+ <returnvalue>{"name": "John", "parent": false}</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>null</literal>
+ <returnvalue><replaceable>value</replaceable></returnvalue>
+ </para>
+ <para>
+ JSON constant <literal>null</literal> (note that, unlike in SQL,
+ comparison to <literal>null</literal> works normally)
+ </para>
+ <para>
+ <literal>jsonb_path_query('[{"name": "Mary", "job": null}, {"name": "Michael", "job": "driver"}]', '$[*] ? (@.job == null) .name')</literal>
+ <returnvalue>"Mary"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>boolean</replaceable> <literal>&&</literal> <replaceable>boolean</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Boolean AND
+ </para>
+ <para>
+ <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (@ > 1 && @ < 5)')</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>boolean</replaceable> <literal>||</literal> <replaceable>boolean</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Boolean OR
+ </para>
+ <para>
+ <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (@ < 1 || @ > 5)')</literal>
+ <returnvalue>7</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>!</literal> <replaceable>boolean</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Boolean NOT
+ </para>
+ <para>
+ <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (!(@ < 5))')</literal>
+ <returnvalue>7</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>boolean</replaceable> <literal>is unknown</literal>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether a Boolean condition is <literal>unknown</literal>.
+ </para>
+ <para>
+ <literal>jsonb_path_query('[-1, 2, 7, "foo"]', '$[*] ? ((@ > 0) is unknown)')</literal>
+ <returnvalue>"foo"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>like_regex</literal> <replaceable>string</replaceable> <optional> <literal>flag</literal> <replaceable>string</replaceable> </optional>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether the first operand matches the regular expression
+ given by the second operand, optionally with modifications
+ described by a string of <literal>flag</literal> characters (see
+ <xref linkend="jsonpath-regular-expressions"/>).
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('["abc", "abd", "aBdC", "abdacb", "babc"]', '$[*] ? (@ like_regex "^ab.*c")')</literal>
+ <returnvalue>["abc", "abdacb"]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('["abc", "abd", "aBdC", "abdacb", "babc"]', '$[*] ? (@ like_regex "^ab.*c" flag "i")')</literal>
+ <returnvalue>["abc", "aBdC", "abdacb"]</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <replaceable>string</replaceable> <literal>starts with</literal> <replaceable>string</replaceable>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether the second operand is an initial substring of the first
+ operand.
+ </para>
+ <para>
+ <literal>jsonb_path_query('["John Smith", "Mary Stone", "Bob Johnson"]', '$[*] ? (@ starts with "John")')</literal>
+ <returnvalue>"John Smith"</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>exists</literal> <literal>(</literal> <replaceable>path_expression</replaceable> <literal>)</literal>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Tests whether a path expression matches at least one SQL/JSON item.
+ Returns <literal>unknown</literal> if the path expression would result
+ in an error; the second example uses this to avoid a no-such-key error
+ in strict mode.
+ </para>
+ <para>
+ <literal>jsonb_path_query('{"x": [1, 2], "y": [2, 4]}', 'strict $.* ? (exists (@ ? (@[*] > 2)))')</literal>
+ <returnvalue>[2, 4]</returnvalue>
+ </para>
+ <para>
+ <literal>jsonb_path_query_array('{"value": 41}', 'strict $ ? (exists (@.name)) .name')</literal>
+ <returnvalue>[]</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect3>
+
+ <sect3 id="jsonpath-regular-expressions">
+ <title>SQL/JSON Regular Expressions</title>
+
+ <indexterm zone="jsonpath-regular-expressions">
+ <primary><literal>LIKE_REGEX</literal></primary>
+ <secondary>in SQL/JSON</secondary>
+ </indexterm>
+
+ <para>
+ SQL/JSON path expressions allow matching text to a regular expression
+ with the <literal>like_regex</literal> filter. For example, the
+ following SQL/JSON path query would case-insensitively match all
+ strings in an array that start with an English vowel:
+<programlisting>
+$[*] ? (@ like_regex "^[aeiou]" flag "i")
+</programlisting>
+ </para>
+
+ <para>
+ The optional <literal>flag</literal> string may include one or more of
+ the characters
+ <literal>i</literal> for case-insensitive match,
+ <literal>m</literal> to allow <literal>^</literal>
+ and <literal>$</literal> to match at newlines,
+ <literal>s</literal> to allow <literal>.</literal> to match a newline,
+ and <literal>q</literal> to quote the whole pattern (reducing the
+ behavior to a simple substring match).
+ </para>
+
+ <para>
+ The SQL/JSON standard borrows its definition for regular expressions
+ from the <literal>LIKE_REGEX</literal> operator, which in turn uses the
+ XQuery standard. PostgreSQL does not currently support the
+ <literal>LIKE_REGEX</literal> operator. Therefore,
+ the <literal>like_regex</literal> filter is implemented using the
+ POSIX regular expression engine described in
+ <xref linkend="functions-posix-regexp"/>. This leads to various minor
+ discrepancies from standard SQL/JSON behavior, which are cataloged in
+ <xref linkend="posix-vs-xquery"/>.
+ Note, however, that the flag-letter incompatibilities described there
+ do not apply to SQL/JSON, as it translates the XQuery flag letters to
+ match what the POSIX engine expects.
+ </para>
+
+ <para>
+ Keep in mind that the pattern argument of <literal>like_regex</literal>
+ is a JSON path string literal, written according to the rules given in
+ <xref linkend="datatype-jsonpath"/>. This means in particular that any
+ backslashes you want to use in the regular expression must be doubled.
+ For example, to match string values of the root document that contain
+ only digits:
+<programlisting>
+$.* ? (@ like_regex "^\\d+$")
+</programlisting>
+ </para>
+ </sect3>
+ </sect2>
+
+ <sect2 id="sqljson-query-functions">
+ <title>SQL/JSON Query Functions</title>
+ <para>
+ SQL/JSON functions <literal>JSON_EXISTS()</literal>,
+ <literal>JSON_QUERY()</literal>, and <literal>JSON_VALUE()</literal>
+ described in <xref linkend="functions-sqljson-querying"/> can be used
+ to query JSON documents. Each of these functions apply a
+ <replaceable>path_expression</replaceable> (the query) to a
+ <replaceable>context_item</replaceable> (the document); see
+ <xref linkend="functions-sqljson-path"/> for more details on what
+ <replaceable>path_expression</replaceable> can contain.
+ </para>
+
+ <table id="functions-sqljson-querying">
+ <title>SQL/JSON Query Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function signature
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_exists</primary></indexterm>
+ <function>json_exists</function> (
+ <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
+ <optional> { <literal>TRUE</literal> | <literal>FALSE</literal> |<literal> UNKNOWN</literal> | <literal>ERROR</literal> } <literal>ON ERROR</literal> </optional>)
+ </para>
+ <para>
+ Returns true if the SQL/JSON <replaceable>path_expression</replaceable>
+ applied to the <replaceable>context_item</replaceable> using the
+ <literal>PASSING</literal> <replaceable>value</replaceable>s yields any
+ items.
+ </para>
+ <para>
+ The <literal>ON ERROR</literal> clause specifies the behavior if
+ an error occurs; the default is to return the <type>boolean</type>
+ <literal>FALSE</literal> value. Note that if the
+ <replaceable>path_expression</replaceable> is <literal>strict</literal>
+ and <literal>ON ERROR</literal> behavior is <literal>ERROR</literal>,
+ an error is generated if it yields no items.
+ </para>
+ <para>
+ Examples:
+ </para>
+ <para>
+ <literal>select json_exists(jsonb '{"key1": [1,2,3]}', 'strict $.key1[*] ? (@ > 2)')</literal>
+ <returnvalue>t</returnvalue>
+ </para>
+ <para>
+ <literal>select json_exists(jsonb '{"a": [1,2,3]}', 'lax $.a[5]' ERROR ON ERROR)</literal>
+ <returnvalue>f</returnvalue>
+ </para>
+ <para>
+ <literal>select json_exists(jsonb '{"a": [1,2,3]}', 'strict $.a[5]' ERROR ON ERROR)</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ERROR: jsonpath array subscript is out of bounds
+</programlisting>
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_query</primary></indexterm>
+ <function>json_query</function> (
+ <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>
+ <optional> { <literal>WITHOUT</literal> | <literal>WITH</literal> { <literal>CONDITIONAL</literal> | <optional><literal>UNCONDITIONAL</literal></optional> } } <optional> <literal>ARRAY</literal> </optional> <literal>WRAPPER</literal> </optional>
+ <optional> { <literal>KEEP</literal> | <literal>OMIT</literal> } <literal>QUOTES</literal> <optional> <literal>ON SCALAR STRING</literal> </optional> </optional>
+ <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>EMPTY</literal> { <optional> <literal>ARRAY</literal> </optional> | <literal>OBJECT</literal> } | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON EMPTY</literal> </optional>
+ <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>EMPTY</literal> { <optional> <literal>ARRAY</literal> </optional> | <literal>OBJECT</literal> } | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON ERROR</literal> </optional>)
+ </para>
+ <para>
+ Returns the result of applying the SQL/JSON
+ <replaceable>path_expression</replaceable> to the
+ <replaceable>context_item</replaceable> using the
+ <literal>PASSING</literal> <replaceable>value</replaceable>s.
+ </para>
+ <para>
+ If the path expression returns multiple SQL/JSON items, it might be
+ necessary to wrap the result using the <literal>WITH WRAPPER</literal>
+ clause to make it a valid JSON string. If the wrapper is
+ <literal>UNCONDITIONAL</literal>, an array wrapper will always be
+ applied, even if the returned value is already a single JSON object
+ or an array. If it is <literal>CONDITIONAL</literal>, it will not be
+ applied to a single JSON object or an array.
+ <literal>UNCONDITIONAL</literal> is the default.
+ </para>
+ <para>
+ If the result is a scalar string, by default, the returned value will
+ be surrounded by quotes, making it a valid JSON value. It can be made
+ explicit by specifying <literal>KEEP QUOTES</literal>. Conversely,
+ quotes can be omitted by specifying <literal>OMIT QUOTES</literal>.
+ Note that <literal>OMIT QUOTES</literal> cannot be specified when
+ <literal>WITH WRAPPER</literal> is also specified.
+ </para>
+ <para>
+ The <literal>RETURNING</literal> clause can be used to specify the
+ <replaceable>data_type</replaceable> of the result value. By default,
+ the returned value will be of type <type>jsonb</type>.
+ </para>
+ <para>
+ The <literal>ON EMPTY</literal> clause specifies the behavior if
+ evaluating <replaceable>path_expression</replaceable> yields no value
+ at all. The default when <literal>ON EMPTY</literal> is not specified
+ is to return a null value.
+ </para>
+ <para>
+ The <literal>ON ERROR</literal> clause specifies the
+ behavior if an error occurs when evaluating
+ <replaceable>path_expression</replaceable>, including the operation to
+ coerce the result value to the output type, or during the execution of
+ <literal>ON EMPTY</literal> behavior (that is caused by empty result
+ of <replaceable>path_expression</replaceable> evaluation). The default
+ when <literal>ON ERROR</literal> is not specified is to return a null
+ value.
+ </para>
+ <para>
+ Examples:
+ </para>
+ <para>
+ <literal>select json_query(jsonb '[1,[2,3],null]', 'lax $[*][1]' WITH CONDITIONAL WRAPPER)</literal>
+ <returnvalue>[3]</returnvalue>
+ </para>
+ <para>
+ <literal>select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a' OMIT QUOTES);</literal>
+ <returnvalue>[1, 2]</returnvalue>
+ </para>
+ <para>
+ <literal>select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a' RETURNING int[] OMIT QUOTES ERROR ON ERROR);</literal>
+ <returnvalue></returnvalue>
+<programlisting>
+ERROR: malformed array literal: "[1, 2]"
+DETAIL: Missing "]" after array dimensions.
+</programlisting>
+ </para>
+ </entry>
+ </row>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm><primary>json_value</primary></indexterm>
+ <function>json_value</function> (
+ <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable>
+ <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
+ <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> </optional>
+ <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON EMPTY</literal> </optional>
+ <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON ERROR</literal> </optional>)
+ </para>
+ <para>
+ Returns the result of applying the SQL/JSON
+ <replaceable>path_expression</replaceable> to the
+ <replaceable>context_item</replaceable> using the
+ <literal>PASSING</literal> <replaceable>value</replaceable>s.
+ </para>
+ <para>
+ The extracted value must be a single <acronym>SQL/JSON</acronym>
+ scalar item; an error is thrown if that's not the case. If you expect
+ that extracted value might be an object or an array, use the
+ <function>json_query</function> function instead.
+ </para>
+ <para>
+ The <literal>RETURNING</literal> clause can be used to specify the
+ <replaceable>data_type</replaceable> of the result value. By default,
+ the returned value will be of type <type>text</type>.
+ </para>
+ <para>
+ The <literal>ON ERROR</literal> and <literal>ON EMPTY</literal>
+ clauses have similar semantics as mentioned in the description of
+ <function>json_query</function>.
+ </para>
+ <para>
+ Note that scalar strings returned by <function>json_value</function>
+ always have their quotes removed, equivalent to specifying
+ <literal>OMIT QUOTES</literal> in <function>json_query</function>.
+ </para>
+ <para>
+ Examples:
+ </para>
+ <para>
+ <literal>select json_value(jsonb '"123.45"', '$' RETURNING float)</literal>
+ <returnvalue>123.45</returnvalue>
+ </para>
+ <para>
+ <literal>select json_value(jsonb '"03:04 2015-02-01"', '$.datetime("HH24:MI YYYY-MM-DD")' RETURNING date)</literal>
+ <returnvalue>2015-02-01</returnvalue>
+ </para>
+ <para>
+ <literal>select json_value(jsonb '[1,2]', 'strict $[*]' DEFAULT 9 ON ERROR)</literal>
+ <returnvalue>9</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </sect2>
+
+ <sect2 id="functions-sqljson-table">
+ <title>JSON_TABLE</title>
+ <indexterm>
+ <primary>json_table</primary>
+ </indexterm>
+
+ <para>
+ <function>JSON_TABLE</function> is an SQL/JSON function which
+ queries <acronym>JSON</acronym> data
+ and presents the results as a relational view, which can be accessed as a
+ regular SQL table. You can use <function>JSON_TABLE</function> inside
+ the <literal>FROM</literal> clause of a <literal>SELECT</literal>,
+ <literal>UPDATE</literal>, or <literal>DELETE</literal> and as data source
+ in a <literal>MERGE</literal> statement.
+ </para>
+
+ <para>
+ Taking JSON data as input, <function>JSON_TABLE</function> uses a JSON path
+ expression to extract a part of the provided data to use as a
+ <firstterm>row pattern</firstterm> for the constructed view. Each SQL/JSON
+ value given by the row pattern serves as source for a separate row in the
+ constructed view.
+ </para>
+
+ <para>
+ To split the row pattern into columns, <function>JSON_TABLE</function>
+ provides the <literal>COLUMNS</literal> clause that defines the
+ schema of the created view. For each column, a separate JSON path expression
+ can be specified to be evaluated against the row pattern to get an SQL/JSON
+ value that will become the value for the specified column in a given output
+ row.
+ </para>
+
+ <para>
+ JSON data stored at a nested level of the row pattern can be extracted using
+ the <literal>NESTED PATH</literal> clause. Each
+ <literal>NESTED PATH</literal> clause can be used to generate one or more
+ columns using the data from a nested level of the row pattern. Those
+ columns can be specified using a <literal>COLUMNS</literal> clause that
+ looks similar to the top-level COLUMNS clause. Rows constructed from
+ NESTED COLUMNS are called <firstterm>child rows</firstterm> and are joined
+ against the row constructed from the columns specified in the parent
+ <literal>COLUMNS</literal> clause to get the row in the final view. Child
+ columns themselves may contain a <literal>NESTED PATH</literal>
+ specification thus allowing to extract data located at arbitrary nesting
+ levels. Columns produced by multiple <literal>NESTED PATH</literal>s at the
+ same level are considered to be <firstterm>siblings</firstterm> of each
+ other and their rows after joining with the parent row are combined using
+ UNION.
+ </para>
+
+ <para>
+ The rows produced by <function>JSON_TABLE</function> are laterally
+ joined to the row that generated them, so you do not have to explicitly join
+ the constructed view with the original table holding <acronym>JSON</acronym>
+ data.
+ </para>
+
+ <para>
+ The syntax is:
+ </para>
+
+<synopsis>
+JSON_TABLE (
+ <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> AS <replaceable>json_path_name</replaceable> </optional> <optional> PASSING { <replaceable>value</replaceable> AS <replaceable>varname</replaceable> } <optional>, ...</optional> </optional>
+ COLUMNS ( <replaceable class="parameter">json_table_column</replaceable> <optional>, ...</optional> )
+ <optional> { <literal>ERROR</literal> | <literal>EMPTY</literal> } <literal>ON ERROR</literal> </optional>
+)
+
+<phrase>
+where <replaceable class="parameter">json_table_column</replaceable> is:
+</phrase>
+ <replaceable>name</replaceable> FOR ORDINALITY
+ | <replaceable>name</replaceable> <replaceable>type</replaceable>
+ <optional> FORMAT JSON <optional>ENCODING <literal>UTF8</literal></optional></optional>
+ <optional> PATH <replaceable>path_expression</replaceable> </optional>
+ <optional> { WITHOUT | WITH { CONDITIONAL | <optional>UNCONDITIONAL</optional> } } <optional> ARRAY </optional> WRAPPER </optional>
+ <optional> { KEEP | OMIT } QUOTES <optional> ON SCALAR STRING </optional> </optional>
+ <optional> { ERROR | NULL | EMPTY { ARRAY | OBJECT } | DEFAULT <replaceable>expression</replaceable> } ON EMPTY </optional>
+ <optional> { ERROR | NULL | EMPTY { ARRAY | OBJECT } | DEFAULT <replaceable>expression</replaceable> } ON ERROR </optional>
+ | <replaceable>name</replaceable> <replaceable>type</replaceable> EXISTS <optional> PATH <replaceable>path_expression</replaceable> </optional>
+ <optional> { ERROR | TRUE | FALSE | UNKNOWN } ON ERROR </optional>
+ | NESTED <optional> PATH </optional> <replaceable>path_expression</replaceable> <optional> AS <replaceable>json_path_name</replaceable> </optional> COLUMNS ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
+</synopsis>
+
+ <para>
+ Each syntax element is described below in more detail.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>
+ <literal><replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>AS</literal> <replaceable>json_path_name</replaceable> </optional> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional></literal>
+ </term>
+ <listitem>
+ <para>
+ The input data to query (<replaceable>context_item</replaceable>),
+ the JSON path expression defining the query (<replaceable>path_expression</replaceable>)
+ with an optional name (<replaceable>json_path_name</replaceable>), and an
+ optional <literal>PASSING</literal> clause, which can provide data values
+ to the <replaceable>path_expression</replaceable>. The result of the input
+ data evaluation using the aforementioned elements is called the
+ <firstterm>row pattern</firstterm>, which is used as the source for row
+ values in the constructed view.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>COLUMNS</literal> ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
+ </term>
+ <listitem>
+
+ <para>
+ The <literal>COLUMNS</literal> clause defining the schema of the
+ constructed view. In this clause, you can specify each column to be
+ filled with an SQL/JSON value obtained by applying a JSON path expression
+ against the row pattern. <replaceable>json_table_column</replaceable> has
+ the following variants:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>
+ <replaceable>name</replaceable> <literal>FOR ORDINALITY</literal>
+ </term>
+ <listitem>
+ <para>
+ Adds an ordinality column that provides sequential row numbering starting
+ from 1. Each <literal>NESTED PATH</literal> (see below) gets its own
+ counter for any nested ordinality columns.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal><replaceable>name</replaceable> <replaceable>type</replaceable>
+ <optional><literal>FORMAT JSON</literal> <optional>ENCODING <literal>UTF8</literal></optional></optional>
+ <optional> <literal>PATH</literal> <replaceable>path_expression</replaceable> </optional></literal>
+ </term>
+ <listitem>
+ <para>
+ Inserts an SQL/JSON value obtained by applying
+ <replaceable>path_expression</replaceable> against the row pattern into
+ the view's output row after coercing it to specified
+ <replaceable>type</replaceable>.
+ </para>
+ <para>
+ Specifying <literal>FORMAT JSON</literal> makes it explicit that you
+ expect the value to be a valid <type>json</type> object. It only
+ makes sense to specify <literal>FORMAT JSON</literal> if
+ <replaceable>type</replaceable> is one of <type>bpchar</type>,
+ <type>bytea</type>, <type>character varying</type>, <type>name</type>,
+ <type>json</type>, <type>jsonb</type>, <type>text</type>, or a domain over
+ these types.
+ </para>
+ <para>
+ Optionally, you can specify <literal>WRAPPER</literal> and
+ <literal>QUOTES</literal> clauses to format the output. Note that
+ specifying <literal>OMIT QUOTES</literal> overrides
+ <literal>FORMAT JSON</literal> if also specified, because unquoted
+ literals do not constitute valid <type>json</type> values.
+ </para>
+ <para>
+ Optionally, you can use <literal>ON EMPTY</literal> and
+ <literal>ON ERROR</literal> clauses to specify whether to throw the error
+ or return the specified value when the result of JSON path evaluation is
+ empty and when an error occurs during JSON path evaluation or when
+ coercing the SQL/JSON value to the specified type, respectively. The
+ default for both is to return a <literal>NULL</literal> value.
+ </para>
+ <note>
+ <para>
+ This clause is internally turned into and has the same semantics as
+ <function>JSON_VALUE</function> or <function>JSON_QUERY</function>.
+ The latter if the specified type is not a scalar type or if either of
+ <literal>FORMAT JSON</literal>, <literal>WRAPPER</literal>, or
+ <literal>QUOTES</literal> clause is present.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <replaceable>name</replaceable> <replaceable>type</replaceable>
+ <literal>EXISTS</literal> <optional> <literal>PATH</literal> <replaceable>path_expression</replaceable> </optional>
+ </term>
+ <listitem>
+ <para>
+ Inserts a boolean value obtained by applying
+ <replaceable>path_expression</replaceable> against the row pattern
+ into the view's output row after coercing it to specified
+ <replaceable>type</replaceable>.
+ </para>
+ <para>
+ The value corresponds to whether applying the <literal>PATH</literal>
+ expression to the row pattern yields any values.
+ </para>
+ <para>
+ The specified <replaceable>type</replaceable> should have a cast from the
+ <type>boolean</type> type.
+ </para>
+ <para>
+ Optionally, you can use <literal>ON ERROR</literal> to specify whether to
+ throw the error or return the specified value when an error occurs during
+ JSON path evaluation or when coercing SQL/JSON value to the specified
+ type. The default is to return a boolean value
+ <literal>FALSE</literal>.
+ </para>
+ <note>
+ <para>
+ This clause is internally turned into and has the same semantics as
+ <function>JSON_EXISTS</function>.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>NESTED <optional> PATH </optional></literal> <replaceable>path_expression</replaceable> <optional> <literal>AS</literal> <replaceable>json_path_name</replaceable> </optional>
+ <literal>COLUMNS</literal> ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
+ </term>
+ <listitem>
+
+ <para>
+ Extracts SQL/JSON values from nested levels of the row pattern,
+ generates one or more columns as defined by the <literal>COLUMNS</literal>
+ subclause, and inserts the extracted SQL/JSON values into those
+ columns. The <replaceable>json_table_column</replaceable>
+ expression in the <literal>COLUMNS</literal> subclause uses the same
+ syntax as in the parent <literal>COLUMNS</literal> clause.
+ </para>
+
+ <para>
+ The <literal>NESTED PATH</literal> syntax is recursive,
+ so you can go down multiple nested levels by specifying several
+ <literal>NESTED PATH</literal> subclauses within each other.
+ It allows to unnest the hierarchy of JSON objects and arrays
+ in a single function invocation rather than chaining several
+ <function>JSON_TABLE</function> expressions in an SQL statement.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <note>
+ <para>
+ In each variant of <replaceable>json_table_column</replaceable> described
+ above, if the <literal>PATH</literal> clause is omitted, path expression
+ <literal>$.<replaceable>name</replaceable></literal> is used, where
+ <replaceable>name</replaceable> is the provided column name.
+ </para>
+ </note>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>AS</literal> <replaceable>json_path_name</replaceable>
+ </term>
+ <listitem>
+
+ <para>
+ The optional <replaceable>json_path_name</replaceable> serves as an
+ identifier of the provided <replaceable>path_expression</replaceable>.
+ The name must be unique and distinct from the column names.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ { <literal>ERROR</literal> | <literal>EMPTY</literal> } <literal>ON ERROR</literal>
+ </term>
+ <listitem>
+
+ <para>
+ The optional <literal>ON ERROR</literal> can be used to specify how to
+ handle errors when evaluating the top-level
+ <replaceable>path_expression</replaceable>. Use <literal>ERROR</literal>
+ if you want the errors to be thrown and <literal>EMPTY</literal> to
+ return an empty table, that is, a table containing 0 rows. Note that
+ this clause does not affect the errors that occur when evaluating
+ columns, for which the behavior depends on whether the
+ <literal>ON ERROR</literal> clause is specified against a given column.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Examples</para>
+
+ <para>
+ In the examples that follow, the following table containing JSON data
+ will be used:
+
+<programlisting>
+CREATE TABLE my_films ( js jsonb );
+
+INSERT INTO my_films VALUES (
+'{ "favorites" : [
+ { "kind" : "comedy", "films" : [
+ { "title" : "Bananas",
+ "director" : "Woody Allen"},
+ { "title" : "The Dinner Game",
+ "director" : "Francis Veber" } ] },
+ { "kind" : "horror", "films" : [
+ { "title" : "Psycho",
+ "director" : "Alfred Hitchcock" } ] },
+ { "kind" : "thriller", "films" : [
+ { "title" : "Vertigo",
+ "director" : "Alfred Hitchcock" } ] },
+ { "kind" : "drama", "films" : [
+ { "title" : "Yojimbo",
+ "director" : "Akira Kurosawa" } ] }
+ ] }');
+</programlisting>
+
+ </para>
+ <para>
+ The following query shows how to use <function>JSON_TABLE</function> to
+ turn the JSON objects in the <structname>my_films</structname> table
+ to a view containing columns for the keys <literal>kind</literal>,
+ <literal>title</literal>, and <literal>director</literal> contained in
+ the original JSON along with an ordinality column:
+
+<programlisting>
+SELECT jt.* FROM
+ my_films,
+ JSON_TABLE (js, '$.favorites[*]' COLUMNS (
+ id FOR ORDINALITY,
+ kind text PATH '$.kind',
+ title text PATH '$.films[*].title' WITH WRAPPER,
+ director text PATH '$.films[*].director' WITH WRAPPER)) AS jt;
+</programlisting>
+
+<screen>
+ id | kind | title | director
+----+----------+--------------------------------+----------------------------------
+ 1 | comedy | ["Bananas", "The Dinner Game"] | ["Woody Allen", "Francis Veber"]
+ 2 | horror | ["Psycho"] | ["Alfred Hitchcock"]
+ 3 | thriller | ["Vertigo"] | ["Alfred Hitchcock"]
+ 4 | drama | ["Yojimbo"] | ["Akira Kurosawa"]
+(4 rows)
+</screen>
+
+ </para>
+ <para>
+ The following is a modified version of the above query to show the
+ usage of <literal>PASSING</literal> arguments in the filter specified in
+ the top-level JSON path expression and the various options for the
+ individual columns:
+
+<programlisting>
+SELECT jt.* FROM
+ my_films,
+ JSON_TABLE (js, '$.favorites[*] ? (@.films[*].director == $filter)'
+ PASSING 'Alfred Hitchcock' AS filter, 'Vertigo' AS filter2
+ COLUMNS (
+ id FOR ORDINALITY,
+ kind text PATH '$.kind',
+ title text FORMAT JSON PATH '$.films[*].title' OMIT QUOTES,
+ director text PATH '$.films[*].director' KEEP QUOTES)) AS jt;
+</programlisting>
+
+<screen>
+ id | kind | title | director
+----+----------+---------+--------------------
+ 1 | horror | Psycho | "Alfred Hitchcock"
+ 2 | thriller | Vertigo | "Alfred Hitchcock"
+(2 rows)
+</screen>
+
+ </para>
+ <para>
+ The following is a modified version of the above query to show the usage
+ of <literal>NESTED PATH</literal> for populating title and director
+ columns, illustrating how they are joined to the parent columns id and
+ kind:
+
+<programlisting>
+SELECT jt.* FROM
+ my_films,
+ JSON_TABLE ( js, '$.favorites[*] ? (@.films[*].director == $filter)'
+ PASSING 'Alfred Hitchcock' AS filter
+ COLUMNS (
+ id FOR ORDINALITY,
+ kind text PATH '$.kind',
+ NESTED PATH '$.films[*]' COLUMNS (
+ title text FORMAT JSON PATH '$.title' OMIT QUOTES,
+ director text PATH '$.director' KEEP QUOTES))) AS jt;
+</programlisting>
+
+<screen>
+ id | kind | title | director
+----+----------+---------+--------------------
+ 1 | horror | Psycho | "Alfred Hitchcock"
+ 2 | thriller | Vertigo | "Alfred Hitchcock"
+(2 rows)
+</screen>
+
+ </para>
+
+ <para>
+ The following is the same query but without the filter in the root
+ path:
+
+<programlisting>
+SELECT jt.* FROM
+ my_films,
+ JSON_TABLE ( js, '$.favorites[*]'
+ COLUMNS (
+ id FOR ORDINALITY,
+ kind text PATH '$.kind',
+ NESTED PATH '$.films[*]' COLUMNS (
+ title text FORMAT JSON PATH '$.title' OMIT QUOTES,
+ director text PATH '$.director' KEEP QUOTES))) AS jt;
+</programlisting>
+
+<screen>
+ id | kind | title | director
+----+----------+-----------------+--------------------
+ 1 | comedy | Bananas | "Woody Allen"
+ 1 | comedy | The Dinner Game | "Francis Veber"
+ 2 | horror | Psycho | "Alfred Hitchcock"
+ 3 | thriller | Vertigo | "Alfred Hitchcock"
+ 4 | drama | Yojimbo | "Akira Kurosawa"
+(5 rows)
+</screen>
+
+ </para>
+
+ <para>
+ The following shows another query using a different <type>JSON</type>
+ object as input. It shows the UNION "sibling join" between
+ <literal>NESTED</literal> paths <literal>$.movies[*]</literal> and
+ <literal>$.books[*]</literal> and also the usage of
+ <literal>FOR ORDINALITY</literal> column at <literal>NESTED</literal>
+ levels (columns <literal>movie_id</literal>, <literal>book_id</literal>,
+ and <literal>author_id</literal>):
+
+<programlisting>
+SELECT * FROM JSON_TABLE (
+'{"favorites":
+ {"movies":
+ [{"name": "One", "director": "John Doe"},
+ {"name": "Two", "director": "Don Joe"}],
+ "books":
+ [{"name": "Mystery", "authors": [{"name": "Brown Dan"}]},
+ {"name": "Wonder", "authors": [{"name": "Jun Murakami"}, {"name":"Craig Doe"}]}]
+}}'::json, '$.favorites[*]'
+COLUMNS (
+ user_id FOR ORDINALITY,
+ NESTED '$.movies[*]'
+ COLUMNS (
+ movie_id FOR ORDINALITY,
+ mname text PATH '$.name',
+ director text),
+ NESTED '$.books[*]'
+ COLUMNS (
+ book_id FOR ORDINALITY,
+ bname text PATH '$.name',
+ NESTED '$.authors[*]'
+ COLUMNS (
+ author_id FOR ORDINALITY,
+ author_name text PATH '$.name'))));
+</programlisting>
+
+<screen>
+ user_id | movie_id | mname | director | book_id | bname | author_id | author_name
+---------+----------+-------+----------+---------+---------+-----------+--------------
+ 1 | 1 | One | John Doe | | | |
+ 1 | 2 | Two | Don Joe | | | |
+ 1 | | | | 1 | Mystery | 1 | Brown Dan
+ 1 | | | | 2 | Wonder | 1 | Jun Murakami
+ 1 | | | | 2 | Wonder | 2 | Craig Doe
+(5 rows)
+</screen>
+
+ </para>
+ </sect2>
+ </sect1>
\ No newline at end of file
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index ca33edc7..7ee6b51f 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -9110,3858 +9110,7 @@ table2-mapping
</sect2>
</sect1>
- <sect1 id="functions-json">
- <title>JSON Functions and Operators</title>
-
- <indexterm zone="functions-json">
- <primary>JSON</primary>
- <secondary>functions and operators</secondary>
- </indexterm>
- <indexterm zone="functions-json">
- <primary>SQL/JSON</primary>
- <secondary>functions and expressions</secondary>
- </indexterm>
-
- <para>
- This section describes:
-
- <itemizedlist>
- <listitem>
- <para>
- functions and operators for processing and creating JSON data
- </para>
- </listitem>
- <listitem>
- <para>
- the SQL/JSON path language
- </para>
- </listitem>
- <listitem>
- <para>
- the SQL/JSON query functions
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- To provide native support for JSON data types within the SQL environment,
- <productname>PostgreSQL</productname> implements the
- <firstterm>SQL/JSON data model</firstterm>.
- This model comprises sequences of items. Each item can hold SQL scalar
- values, with an additional SQL/JSON null value, and composite data structures
- that use JSON arrays and objects. The model is a formalization of the implied
- data model in the JSON specification
- <ulink url="https://datatracker.ietf.org/doc/html/rfc7159">RFC 7159</ulink>.
- </para>
-
- <para>
- SQL/JSON allows you to handle JSON data alongside regular SQL data,
- with transaction support, including:
-
- <itemizedlist>
- <listitem>
- <para>
- Uploading JSON data into the database and storing it in
- regular SQL columns as character or binary strings.
- </para>
- </listitem>
- <listitem>
- <para>
- Generating JSON objects and arrays from relational data.
- </para>
- </listitem>
- <listitem>
- <para>
- Querying JSON data using SQL/JSON query functions and
- SQL/JSON path language expressions.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- To learn more about the SQL/JSON standard, see
- <xref linkend="sqltr-19075-6"/>. For details on JSON types
- supported in <productname>PostgreSQL</productname>,
- see <xref linkend="datatype-json"/>.
- </para>
-
- <sect2 id="functions-json-processing">
- <title>Processing and Creating JSON Data</title>
-
- <para>
- <xref linkend="functions-json-op-table"/> shows the operators that
- are available for use with JSON data types (see <xref
- linkend="datatype-json"/>).
- In addition, the usual comparison operators shown in <xref
- linkend="functions-comparison-op-table"/> are available for
- <type>jsonb</type>, though not for <type>json</type>. The comparison
- operators follow the ordering rules for B-tree operations outlined in
- <xref linkend="json-indexing"/>.
- See also <xref linkend="functions-aggregate"/> for the aggregate
- function <function>json_agg</function> which aggregates record
- values as JSON, the aggregate function
- <function>json_object_agg</function> which aggregates pairs of values
- into a JSON object, and their <type>jsonb</type> equivalents,
- <function>jsonb_agg</function> and <function>jsonb_object_agg</function>.
- </para>
-
- <table id="functions-json-op-table">
- <title><type>json</type> and <type>jsonb</type> Operators</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>-></literal> <type>integer</type>
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>-></literal> <type>integer</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Extracts <parameter>n</parameter>'th element of JSON array
- (array elements are indexed from zero, but negative integers count
- from the end).
- </para>
- <para>
- <literal>'[{"a":"foo"},{"b":"bar"},{"c":"baz"}]'::json -> 2</literal>
- <returnvalue>{"c":"baz"}</returnvalue>
- </para>
- <para>
- <literal>'[{"a":"foo"},{"b":"bar"},{"c":"baz"}]'::json -> -3</literal>
- <returnvalue>{"a":"foo"}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>-></literal> <type>text</type>
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>-></literal> <type>text</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Extracts JSON object field with the given key.
- </para>
- <para>
- <literal>'{"a": {"b":"foo"}}'::json -> 'a'</literal>
- <returnvalue>{"b":"foo"}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>->></literal> <type>integer</type>
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>->></literal> <type>integer</type>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts <parameter>n</parameter>'th element of JSON array,
- as <type>text</type>.
- </para>
- <para>
- <literal>'[1,2,3]'::json ->> 2</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>->></literal> <type>text</type>
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>->></literal> <type>text</type>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts JSON object field with the given key, as <type>text</type>.
- </para>
- <para>
- <literal>'{"a":1,"b":2}'::json ->> 'b'</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>#></literal> <type>text[]</type>
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>#></literal> <type>text[]</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Extracts JSON sub-object at the specified path, where path elements
- can be either field keys or array indexes.
- </para>
- <para>
- <literal>'{"a": {"b": ["foo","bar"]}}'::json #> '{a,b,1}'</literal>
- <returnvalue>"bar"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>json</type> <literal>#>></literal> <type>text[]</type>
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <type>jsonb</type> <literal>#>></literal> <type>text[]</type>
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts JSON sub-object at the specified path as <type>text</type>.
- </para>
- <para>
- <literal>'{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}'</literal>
- <returnvalue>bar</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <note>
- <para>
- The field/element/path extraction operators return NULL, rather than
- failing, if the JSON input does not have the right structure to match
- the request; for example if no such key or array element exists.
- </para>
- </note>
-
- <para>
- Some further operators exist only for <type>jsonb</type>, as shown
- in <xref linkend="functions-jsonb-op-table"/>.
- <xref linkend="json-indexing"/>
- describes how these operators can be used to effectively search indexed
- <type>jsonb</type> data.
- </para>
-
- <table id="functions-jsonb-op-table">
- <title>Additional <type>jsonb</type> Operators</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>@></literal> <type>jsonb</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does the first JSON value contain the second?
- (See <xref linkend="json-containment"/> for details about containment.)
- </para>
- <para>
- <literal>'{"a":1, "b":2}'::jsonb @> '{"b":2}'::jsonb</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal><@</literal> <type>jsonb</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Is the first JSON value contained in the second?
- </para>
- <para>
- <literal>'{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>?</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does the text string exist as a top-level key or array element within
- the JSON value?
- </para>
- <para>
- <literal>'{"a":1, "b":2}'::jsonb ? 'b'</literal>
- <returnvalue>t</returnvalue>
- </para>
- <para>
- <literal>'["a", "b", "c"]'::jsonb ? 'b'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>?|</literal> <type>text[]</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Do any of the strings in the text array exist as top-level keys or
- array elements?
- </para>
- <para>
- <literal>'{"a":1, "b":2, "c":3}'::jsonb ?| array['b', 'd']</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>?&</literal> <type>text[]</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Do all of the strings in the text array exist as top-level keys or
- array elements?
- </para>
- <para>
- <literal>'["a", "b", "c"]'::jsonb ?& array['a', 'b']</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>||</literal> <type>jsonb</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Concatenates two <type>jsonb</type> values.
- Concatenating two arrays generates an array containing all the
- elements of each input. Concatenating two objects generates an
- object containing the union of their
- keys, taking the second object's value when there are duplicate keys.
- All other cases are treated by converting a non-array input into a
- single-element array, and then proceeding as for two arrays.
- Does not operate recursively: only the top-level array or object
- structure is merged.
- </para>
- <para>
- <literal>'["a", "b"]'::jsonb || '["a", "d"]'::jsonb</literal>
- <returnvalue>["a", "b", "a", "d"]</returnvalue>
- </para>
- <para>
- <literal>'{"a": "b"}'::jsonb || '{"c": "d"}'::jsonb</literal>
- <returnvalue>{"a": "b", "c": "d"}</returnvalue>
- </para>
- <para>
- <literal>'[1, 2]'::jsonb || '3'::jsonb</literal>
- <returnvalue>[1, 2, 3]</returnvalue>
- </para>
- <para>
- <literal>'{"a": "b"}'::jsonb || '42'::jsonb</literal>
- <returnvalue>[{"a": "b"}, 42]</returnvalue>
- </para>
- <para>
- To append an array to another array as a single entry, wrap it
- in an additional layer of array, for example:
- </para>
- <para>
- <literal>'[1, 2]'::jsonb || jsonb_build_array('[3, 4]'::jsonb)</literal>
- <returnvalue>[1, 2, [3, 4]]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>-</literal> <type>text</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Deletes a key (and its value) from a JSON object, or matching string
- value(s) from a JSON array.
- </para>
- <para>
- <literal>'{"a": "b", "c": "d"}'::jsonb - 'a'</literal>
- <returnvalue>{"c": "d"}</returnvalue>
- </para>
- <para>
- <literal>'["a", "b", "c", "b"]'::jsonb - 'b'</literal>
- <returnvalue>["a", "c"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>-</literal> <type>text[]</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Deletes all matching keys or array elements from the left operand.
- </para>
- <para>
- <literal>'{"a": "b", "c": "d"}'::jsonb - '{a,c}'::text[]</literal>
- <returnvalue>{}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>-</literal> <type>integer</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Deletes the array element with specified index (negative
- integers count from the end). Throws an error if JSON value
- is not an array.
- </para>
- <para>
- <literal>'["a", "b"]'::jsonb - 1 </literal>
- <returnvalue>["a"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>#-</literal> <type>text[]</type>
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Deletes the field or array element at the specified path, where path
- elements can be either field keys or array indexes.
- </para>
- <para>
- <literal>'["a", {"b":1}]'::jsonb #- '{1,b}'</literal>
- <returnvalue>["a", {}]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>@?</literal> <type>jsonpath</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Does JSON path return any item for the specified JSON value?
- (This is useful only with SQL-standard JSON path expressions, not
- <link linkend="functions-sqljson-check-expressions">predicate check
- expressions</link>, since those always return a value.)
- </para>
- <para>
- <literal>'{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] ? (@ > 2)'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>jsonb</type> <literal>@@</literal> <type>jsonpath</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns the result of a JSON path predicate check for the
- specified JSON value.
- (This is useful only
- with <link linkend="functions-sqljson-check-expressions">predicate
- check expressions</link>, not SQL-standard JSON path expressions,
- since it will return <literal>NULL</literal> if the path result is
- not a single boolean value.)
- </para>
- <para>
- <literal>'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <note>
- <para>
- The <type>jsonpath</type> operators <literal>@?</literal>
- and <literal>@@</literal> suppress the following errors: missing object
- field or array element, unexpected JSON item type, datetime and numeric
- errors. The <type>jsonpath</type>-related functions described below can
- also be told to suppress these types of errors. This behavior might be
- helpful when searching JSON document collections of varying structure.
- </para>
- </note>
-
- <para>
- <xref linkend="functions-json-creation-table"/> shows the functions that are
- available for constructing <type>json</type> and <type>jsonb</type> values.
- Some functions in this table have a <literal>RETURNING</literal> clause,
- which specifies the data type returned. It must be one of <type>json</type>,
- <type>jsonb</type>, <type>bytea</type>, a character string type (<type>text</type>,
- <type>char</type>, <type>varchar</type>, or <type>nchar</type>), or a type
- for which there is a cast from <type>json</type> to that type.
- By default, the <type>json</type> type is returned.
- </para>
-
- <table id="functions-json-creation-table">
- <title>JSON Creation Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_json</primary>
- </indexterm>
- <function>to_json</function> ( <type>anyelement</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>to_jsonb</primary>
- </indexterm>
- <function>to_jsonb</function> ( <type>anyelement</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Converts any SQL value to <type>json</type> or <type>jsonb</type>.
- Arrays and composites are converted recursively to arrays and
- objects (multidimensional arrays become arrays of arrays in JSON).
- Otherwise, if there is a cast from the SQL data type
- to <type>json</type>, the cast function will be used to perform the
- conversion;<footnote>
- <para>
- For example, the <xref linkend="hstore"/> extension has a cast
- from <type>hstore</type> to <type>json</type>, so that
- <type>hstore</type> values converted via the JSON creation functions
- will be represented as JSON objects, not as primitive string values.
- </para>
- </footnote>
- otherwise, a scalar JSON value is produced. For any scalar other than
- a number, a Boolean, or a null value, the text representation will be
- used, with escaping as necessary to make it a valid JSON string value.
- </para>
- <para>
- <literal>to_json('Fred said "Hi."'::text)</literal>
- <returnvalue>"Fred said \"Hi.\""</returnvalue>
- </para>
- <para>
- <literal>to_jsonb(row(42, 'Fred said "Hi."'::text))</literal>
- <returnvalue>{"f1": 42, "f2": "Fred said \"Hi.\""}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>array_to_json</primary>
- </indexterm>
- <function>array_to_json</function> ( <type>anyarray</type> <optional>, <type>boolean</type> </optional> )
- <returnvalue>json</returnvalue>
- </para>
- <para>
- Converts an SQL array to a JSON array. The behavior is the same
- as <function>to_json</function> except that line feeds will be added
- between top-level array elements if the optional boolean parameter is
- true.
- </para>
- <para>
- <literal>array_to_json('{{1,5},{99,100}}'::int[])</literal>
- <returnvalue>[[1,5],[99,100]]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <!--
- Note that this is barely legible in the output; it looks like a
- salad of braces and brackets. It would be better to split it out
- in multiple lines, but that's surprisingly hard to do in a way that
- matches in HTML and PDF output. Other standard SQL/JSON functions
- have the same problem.
- -->
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_array</primary></indexterm>
- <function>json_array</function> (
- <optional> { <replaceable>value_expression</replaceable> <optional> <literal>FORMAT JSON</literal> </optional> } <optional>, ...</optional> </optional>
- <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
- </para>
- <para role="func_signature">
- <function>json_array</function> (
- <optional> <replaceable>query_expression</replaceable> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
- </para>
- <para>
- Constructs a JSON array from either a series of
- <replaceable>value_expression</replaceable> parameters or from the results
- of <replaceable>query_expression</replaceable>,
- which must be a SELECT query returning a single column. If
- <literal>ABSENT ON NULL</literal> is specified, NULL values are ignored.
- This is always the case if a
- <replaceable>query_expression</replaceable> is used.
- </para>
- <para>
- <literal>json_array(1,true,json '{"a":null}')</literal>
- <returnvalue>[1, true, {"a":null}]</returnvalue>
- </para>
- <para>
- <literal>json_array(SELECT * FROM (VALUES(1),(2)) t)</literal>
- <returnvalue>[1, 2]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>row_to_json</primary>
- </indexterm>
- <function>row_to_json</function> ( <type>record</type> <optional>, <type>boolean</type> </optional> )
- <returnvalue>json</returnvalue>
- </para>
- <para>
- Converts an SQL composite value to a JSON object. The behavior is the
- same as <function>to_json</function> except that line feeds will be
- added between top-level elements if the optional boolean parameter is
- true.
- </para>
- <para>
- <literal>row_to_json(row(1,'foo'))</literal>
- <returnvalue>{"f1":1,"f2":"foo"}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_build_array</primary>
- </indexterm>
- <function>json_build_array</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_build_array</primary>
- </indexterm>
- <function>jsonb_build_array</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Builds a possibly-heterogeneously-typed JSON array out of a variadic
- argument list. Each argument is converted as
- per <function>to_json</function> or <function>to_jsonb</function>.
- </para>
- <para>
- <literal>json_build_array(1, 2, 'foo', 4, 5)</literal>
- <returnvalue>[1, 2, "foo", 4, 5]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_build_object</primary>
- </indexterm>
- <function>json_build_object</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_build_object</primary>
- </indexterm>
- <function>jsonb_build_object</function> ( <literal>VARIADIC</literal> <type>"any"</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Builds a JSON object out of a variadic argument list. By convention,
- the argument list consists of alternating keys and values. Key
- arguments are coerced to text; value arguments are converted as
- per <function>to_json</function> or <function>to_jsonb</function>.
- </para>
- <para>
- <literal>json_build_object('foo', 1, 2, row(3,'bar'))</literal>
- <returnvalue>{"foo" : 1, "2" : {"f1":3,"f2":"bar"}}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_object</primary></indexterm>
- <function>json_object</function> (
- <optional> { <replaceable>key_expression</replaceable> { <literal>VALUE</literal> | ':' }
- <replaceable>value_expression</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> }<optional>, ...</optional> </optional>
- <optional> { <literal>NULL</literal> | <literal>ABSENT</literal> } <literal>ON NULL</literal> </optional>
- <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>)
- </para>
- <para>
- Constructs a JSON object of all the key/value pairs given,
- or an empty object if none are given.
- <replaceable>key_expression</replaceable> is a scalar expression
- defining the <acronym>JSON</acronym> key, which is
- converted to the <type>text</type> type.
- It cannot be <literal>NULL</literal> nor can it
- belong to a type that has a cast to the <type>json</type> type.
- If <literal>WITH UNIQUE KEYS</literal> is specified, there must not
- be any duplicate <replaceable>key_expression</replaceable>.
- Any pair for which the <replaceable>value_expression</replaceable>
- evaluates to <literal>NULL</literal> is omitted from the output
- if <literal>ABSENT ON NULL</literal> is specified;
- if <literal>NULL ON NULL</literal> is specified or the clause
- omitted, the key is included with value <literal>NULL</literal>.
- </para>
- <para>
- <literal>json_object('code' VALUE 'P123', 'title': 'Jaws')</literal>
- <returnvalue>{"code" : "P123", "title" : "Jaws"}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object</primary>
- </indexterm>
- <function>json_object</function> ( <type>text[]</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object</primary>
- </indexterm>
- <function>jsonb_object</function> ( <type>text[]</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Builds a JSON object out of a text array. The array must have either
- exactly one dimension with an even number of members, in which case
- they are taken as alternating key/value pairs, or two dimensions
- such that each inner array has exactly two elements, which
- are taken as a key/value pair. All values are converted to JSON
- strings.
- </para>
- <para>
- <literal>json_object('{a, 1, b, "def", c, 3.5}')</literal>
- <returnvalue>{"a" : "1", "b" : "def", "c" : "3.5"}</returnvalue>
- </para>
- <para><literal>json_object('{{a, 1}, {b, "def"}, {c, 3.5}}')</literal>
- <returnvalue>{"a" : "1", "b" : "def", "c" : "3.5"}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>json_object</function> ( <parameter>keys</parameter> <type>text[]</type>, <parameter>values</parameter> <type>text[]</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <function>jsonb_object</function> ( <parameter>keys</parameter> <type>text[]</type>, <parameter>values</parameter> <type>text[]</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- This form of <function>json_object</function> takes keys and values
- pairwise from separate text arrays. Otherwise it is identical to
- the one-argument form.
- </para>
- <para>
- <literal>json_object('{a,b}', '{1,2}')</literal>
- <returnvalue>{"a": "1", "b": "2"}</returnvalue>
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry">
- <para role="func_signature">
- <indexterm><primary>json constructor</primary></indexterm>
- <function>json</function> (
- <replaceable>expression</replaceable>
- <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional></optional>
- <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional></optional> )
- <returnvalue>json</returnvalue>
- </para>
- <para>
- Converts a given expression specified as <type>text</type> or
- <type>bytea</type> string (in UTF8 encoding) into a JSON
- value. If <replaceable>expression</replaceable> is NULL, an
- <acronym>SQL</acronym> null value is returned.
- If <literal>WITH UNIQUE</literal> is specified, the
- <replaceable>expression</replaceable> must not contain any duplicate
- object keys.
- </para>
- <para>
- <literal>json('{"a":123, "b":[true,"foo"], "a":"bar"}')</literal>
- <returnvalue>{"a":123, "b":[true,"foo"], "a":"bar"}</returnvalue>
- </para>
- </entry>
- </row>
- <row>
- <entry role="func_table_entry">
- <para role="func_signature">
- <indexterm><primary>json_scalar</primary></indexterm>
- <function>json_scalar</function> ( <replaceable>expression</replaceable> )
- </para>
- <para>
- Converts a given SQL scalar value into a JSON scalar value.
- If the input is NULL, an <acronym>SQL</acronym> null is returned. If
- the input is number or a boolean value, a corresponding JSON number
- or boolean value is returned. For any other value, a JSON string is
- returned.
- </para>
- <para>
- <literal>json_scalar(123.45)</literal>
- <returnvalue>123.45</returnvalue>
- </para>
- <para>
- <literal>json_scalar(CURRENT_TIMESTAMP)</literal>
- <returnvalue>"2022-05-10T10:51:04.62128-04:00"</returnvalue>
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry">
- <para role="func_signature">
- <function>json_serialize</function> (
- <replaceable>expression</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional> )
- </para>
- <para>
- Converts an SQL/JSON expression into a character or binary string. The
- <replaceable>expression</replaceable> can be of any JSON type, any
- character string type, or <type>bytea</type> in UTF8 encoding.
- The returned type used in <literal> RETURNING</literal> can be any
- character string type or <type>bytea</type>. The default is
- <type>text</type>.
- </para>
- <para>
- <literal>json_serialize('{ "a" : 1 } ' RETURNING bytea)</literal>
- <returnvalue>\x7b20226122203a2031207d20</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-sqljson-misc" /> details SQL/JSON
- facilities for testing JSON.
- </para>
-
- <table id="functions-sqljson-misc">
- <title>SQL/JSON Testing Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function signature
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>IS JSON</primary></indexterm>
- <replaceable>expression</replaceable> <literal>IS</literal> <optional> <literal>NOT</literal> </optional> <literal>JSON</literal>
- <optional> { <literal>VALUE</literal> | <literal>SCALAR</literal> | <literal>ARRAY</literal> | <literal>OBJECT</literal> } </optional>
- <optional> { <literal>WITH</literal> | <literal>WITHOUT</literal> } <literal>UNIQUE</literal> <optional> <literal>KEYS</literal> </optional> </optional>
- </para>
- <para>
- This predicate tests whether <replaceable>expression</replaceable> can be
- parsed as JSON, possibly of a specified type.
- If <literal>SCALAR</literal> or <literal>ARRAY</literal> or
- <literal>OBJECT</literal> is specified, the
- test is whether or not the JSON is of that particular type. If
- <literal>WITH UNIQUE KEYS</literal> is specified, then any object in the
- <replaceable>expression</replaceable> is also tested to see if it
- has duplicate keys.
- </para>
- <para>
-<programlisting>
-SELECT js,
- js IS JSON "json?",
- js IS JSON SCALAR "scalar?",
- js IS JSON OBJECT "object?",
- js IS JSON ARRAY "array?"
-FROM (VALUES
- ('123'), ('"abc"'), ('{"a": "b"}'), ('[1,2]'),('abc')) foo(js);
- js | json? | scalar? | object? | array?
-------------+-------+---------+---------+--------
- 123 | t | t | f | f
- "abc" | t | t | f | f
- {"a": "b"} | t | f | t | f
- [1,2] | t | f | f | t
- abc | f | f | f | f
-</programlisting>
- </para>
- <para>
-<programlisting>
-SELECT js,
- js IS JSON OBJECT "object?",
- js IS JSON ARRAY "array?",
- js IS JSON ARRAY WITH UNIQUE KEYS "array w. UK?",
- js IS JSON ARRAY WITHOUT UNIQUE KEYS "array w/o UK?"
-FROM (VALUES ('[{"a":"1"},
- {"b":"2","b":"3"}]')) foo(js);
--[ RECORD 1 ]-+--------------------
-js | [{"a":"1"}, +
- | {"b":"2","b":"3"}]
-object? | f
-array? | t
-array w. UK? | f
-array w/o UK? | t
-</programlisting>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-json-processing-table"/> shows the functions that
- are available for processing <type>json</type> and <type>jsonb</type> values.
- </para>
-
- <table id="functions-json-processing-table">
- <title>JSON Processing Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_array_elements</primary>
- </indexterm>
- <function>json_array_elements</function> ( <type>json</type> )
- <returnvalue>setof json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_array_elements</primary>
- </indexterm>
- <function>jsonb_array_elements</function> ( <type>jsonb</type> )
- <returnvalue>setof jsonb</returnvalue>
- </para>
- <para>
- Expands the top-level JSON array into a set of JSON values.
- </para>
- <para>
- <literal>select * from json_array_elements('[1,true, [2,false]]')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- value
------------
- 1
- true
- [2,false]
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_array_elements_text</primary>
- </indexterm>
- <function>json_array_elements_text</function> ( <type>json</type> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_array_elements_text</primary>
- </indexterm>
- <function>jsonb_array_elements_text</function> ( <type>jsonb</type> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Expands the top-level JSON array into a set of <type>text</type> values.
- </para>
- <para>
- <literal>select * from json_array_elements_text('["foo", "bar"]')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- value
------------
- foo
- bar
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_array_length</primary>
- </indexterm>
- <function>json_array_length</function> ( <type>json</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_array_length</primary>
- </indexterm>
- <function>jsonb_array_length</function> ( <type>jsonb</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Returns the number of elements in the top-level JSON array.
- </para>
- <para>
- <literal>json_array_length('[1,2,3,{"f1":1,"f2":[5,6]},4]')</literal>
- <returnvalue>5</returnvalue>
- </para>
- <para>
- <literal>jsonb_array_length('[]')</literal>
- <returnvalue>0</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_each</primary>
- </indexterm>
- <function>json_each</function> ( <type>json</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>key</parameter> <type>text</type>,
- <parameter>value</parameter> <type>json</type> )
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_each</primary>
- </indexterm>
- <function>jsonb_each</function> ( <type>jsonb</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>key</parameter> <type>text</type>,
- <parameter>value</parameter> <type>jsonb</type> )
- </para>
- <para>
- Expands the top-level JSON object into a set of key/value pairs.
- </para>
- <para>
- <literal>select * from json_each('{"a":"foo", "b":"bar"}')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- key | value
------+-------
- a | "foo"
- b | "bar"
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_each_text</primary>
- </indexterm>
- <function>json_each_text</function> ( <type>json</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>key</parameter> <type>text</type>,
- <parameter>value</parameter> <type>text</type> )
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_each_text</primary>
- </indexterm>
- <function>jsonb_each_text</function> ( <type>jsonb</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>key</parameter> <type>text</type>,
- <parameter>value</parameter> <type>text</type> )
- </para>
- <para>
- Expands the top-level JSON object into a set of key/value pairs.
- The returned <parameter>value</parameter>s will be of
- type <type>text</type>.
- </para>
- <para>
- <literal>select * from json_each_text('{"a":"foo", "b":"bar"}')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- key | value
------+-------
- a | foo
- b | bar
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_extract_path</primary>
- </indexterm>
- <function>json_extract_path</function> ( <parameter>from_json</parameter> <type>json</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_extract_path</primary>
- </indexterm>
- <function>jsonb_extract_path</function> ( <parameter>from_json</parameter> <type>jsonb</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Extracts JSON sub-object at the specified path.
- (This is functionally equivalent to the <literal>#></literal>
- operator, but writing the path out as a variadic list can be more
- convenient in some cases.)
- </para>
- <para>
- <literal>json_extract_path('{"f2":{"f3":1},"f4":{"f5":99,"f6":"foo"}}', 'f4', 'f6')</literal>
- <returnvalue>"foo"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_extract_path_text</primary>
- </indexterm>
- <function>json_extract_path_text</function> ( <parameter>from_json</parameter> <type>json</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_extract_path_text</primary>
- </indexterm>
- <function>jsonb_extract_path_text</function> ( <parameter>from_json</parameter> <type>jsonb</type>, <literal>VARIADIC</literal> <parameter>path_elems</parameter> <type>text[]</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Extracts JSON sub-object at the specified path as <type>text</type>.
- (This is functionally equivalent to the <literal>#>></literal>
- operator.)
- </para>
- <para>
- <literal>json_extract_path_text('{"f2":{"f3":1},"f4":{"f5":99,"f6":"foo"}}', 'f4', 'f6')</literal>
- <returnvalue>foo</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_object_keys</primary>
- </indexterm>
- <function>json_object_keys</function> ( <type>json</type> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_object_keys</primary>
- </indexterm>
- <function>jsonb_object_keys</function> ( <type>jsonb</type> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Returns the set of keys in the top-level JSON object.
- </para>
- <para>
- <literal>select * from json_object_keys('{"f1":"abc","f2":{"f3":"a", "f4":"b"}}')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- json_object_keys
-------------------
- f1
- f2
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_populate_record</primary>
- </indexterm>
- <function>json_populate_record</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
- <returnvalue>anyelement</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_populate_record</primary>
- </indexterm>
- <function>jsonb_populate_record</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>jsonb</type> )
- <returnvalue>anyelement</returnvalue>
- </para>
- <para>
- Expands the top-level JSON object to a row having the composite type
- of the <parameter>base</parameter> argument. The JSON object
- is scanned for fields whose names match column names of the output row
- type, and their values are inserted into those columns of the output.
- (Fields that do not correspond to any output column name are ignored.)
- In typical use, the value of <parameter>base</parameter> is just
- <literal>NULL</literal>, which means that any output columns that do
- not match any object field will be filled with nulls. However,
- if <parameter>base</parameter> isn't <literal>NULL</literal> then
- the values it contains will be used for unmatched columns.
- </para>
- <para>
- To convert a JSON value to the SQL type of an output column, the
- following rules are applied in sequence:
- <itemizedlist spacing="compact">
- <listitem>
- <para>
- A JSON null value is converted to an SQL null in all cases.
- </para>
- </listitem>
- <listitem>
- <para>
- If the output column is of type <type>json</type>
- or <type>jsonb</type>, the JSON value is just reproduced exactly.
- </para>
- </listitem>
- <listitem>
- <para>
- If the output column is a composite (row) type, and the JSON value
- is a JSON object, the fields of the object are converted to columns
- of the output row type by recursive application of these rules.
- </para>
- </listitem>
- <listitem>
- <para>
- Likewise, if the output column is an array type and the JSON value
- is a JSON array, the elements of the JSON array are converted to
- elements of the output array by recursive application of these
- rules.
- </para>
- </listitem>
- <listitem>
- <para>
- Otherwise, if the JSON value is a string, the contents of the
- string are fed to the input conversion function for the column's
- data type.
- </para>
- </listitem>
- <listitem>
- <para>
- Otherwise, the ordinary text representation of the JSON value is
- fed to the input conversion function for the column's data type.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- While the example below uses a constant JSON value, typical use would
- be to reference a <type>json</type> or <type>jsonb</type> column
- laterally from another table in the query's <literal>FROM</literal>
- clause. Writing <function>json_populate_record</function> in
- the <literal>FROM</literal> clause is good practice, since all of the
- extracted columns are available for use without duplicate function
- calls.
- </para>
- <para>
- <literal>create type subrowtype as (d int, e text);</literal>
- <literal>create type myrowtype as (a int, b text[], c subrowtype);</literal>
- </para>
- <para>
- <literal>select * from json_populate_record(null::myrowtype,
- '{"a": 1, "b": ["2", "a b"], "c": {"d": 4, "e": "a b c"}, "x": "foo"}')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- a | b | c
----+-----------+-------------
- 1 | {2,"a b"} | (4,"a b c")
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_populate_record_valid</primary>
- </indexterm>
- <function>jsonb_populate_record_valid</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Function for testing <function>jsonb_populate_record</function>. Returns
- <literal>true</literal> if the input <function>jsonb_populate_record</function>
- would finish without an error for the given input JSON object; that is, it's
- valid input, <literal>false</literal> otherwise.
- </para>
- <para>
- <literal>create type jsb_char2 as (a char(2));</literal>
- </para>
- <para>
- <literal>select jsonb_populate_record_valid(NULL::jsb_char2, '{"a": "aaa"}');</literal>
- <returnvalue></returnvalue>
-<programlisting>
- jsonb_populate_record_valid
------------------------------
- f
-(1 row)
-</programlisting>
-
- <literal>select * from jsonb_populate_record(NULL::jsb_char2, '{"a": "aaa"}') q;</literal>
- <returnvalue></returnvalue>
-<programlisting>
-ERROR: value too long for type character(2)
-</programlisting>
- <literal>select jsonb_populate_record_valid(NULL::jsb_char2, '{"a": "aa"}');</literal>
- <returnvalue></returnvalue>
-<programlisting>
- jsonb_populate_record_valid
------------------------------
- t
-(1 row)
-</programlisting>
-
- <literal>select * from jsonb_populate_record(NULL::jsb_char2, '{"a": "aa"}') q;</literal>
- <returnvalue></returnvalue>
-<programlisting>
- a
-----
- aa
-(1 row)
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_populate_recordset</primary>
- </indexterm>
- <function>json_populate_recordset</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>json</type> )
- <returnvalue>setof anyelement</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_populate_recordset</primary>
- </indexterm>
- <function>jsonb_populate_recordset</function> ( <parameter>base</parameter> <type>anyelement</type>, <parameter>from_json</parameter> <type>jsonb</type> )
- <returnvalue>setof anyelement</returnvalue>
- </para>
- <para>
- Expands the top-level JSON array of objects to a set of rows having
- the composite type of the <parameter>base</parameter> argument.
- Each element of the JSON array is processed as described above
- for <function>json[b]_populate_record</function>.
- </para>
- <para>
- <literal>create type twoints as (a int, b int);</literal>
- </para>
- <para>
- <literal>select * from json_populate_recordset(null::twoints, '[{"a":1,"b":2}, {"a":3,"b":4}]')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- a | b
----+---
- 1 | 2
- 3 | 4
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_to_record</primary>
- </indexterm>
- <function>json_to_record</function> ( <type>json</type> )
- <returnvalue>record</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_to_record</primary>
- </indexterm>
- <function>jsonb_to_record</function> ( <type>jsonb</type> )
- <returnvalue>record</returnvalue>
- </para>
- <para>
- Expands the top-level JSON object to a row having the composite type
- defined by an <literal>AS</literal> clause. (As with all functions
- returning <type>record</type>, the calling query must explicitly
- define the structure of the record with an <literal>AS</literal>
- clause.) The output record is filled from fields of the JSON object,
- in the same way as described above
- for <function>json[b]_populate_record</function>. Since there is no
- input record value, unmatched columns are always filled with nulls.
- </para>
- <para>
- <literal>create type myrowtype as (a int, b text);</literal>
- </para>
- <para>
- <literal>select * from json_to_record('{"a":1,"b":[1,2,3],"c":[1,2,3],"e":"bar","r": {"a": 123, "b": "a b c"}}') as x(a int, b text, c int[], d text, r myrowtype)</literal>
- <returnvalue></returnvalue>
-<programlisting>
- a | b | c | d | r
----+---------+---------+---+---------------
- 1 | [1,2,3] | {1,2,3} | | (123,"a b c")
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_to_recordset</primary>
- </indexterm>
- <function>json_to_recordset</function> ( <type>json</type> )
- <returnvalue>setof record</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_to_recordset</primary>
- </indexterm>
- <function>jsonb_to_recordset</function> ( <type>jsonb</type> )
- <returnvalue>setof record</returnvalue>
- </para>
- <para>
- Expands the top-level JSON array of objects to a set of rows having
- the composite type defined by an <literal>AS</literal> clause. (As
- with all functions returning <type>record</type>, the calling query
- must explicitly define the structure of the record with
- an <literal>AS</literal> clause.) Each element of the JSON array is
- processed as described above
- for <function>json[b]_populate_record</function>.
- </para>
- <para>
- <literal>select * from json_to_recordset('[{"a":1,"b":"foo"}, {"a":"2","c":"bar"}]') as x(a int, b text)</literal>
- <returnvalue></returnvalue>
-<programlisting>
- a | b
----+-----
- 1 | foo
- 2 |
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_set</primary>
- </indexterm>
- <function>jsonb_set</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>create_if_missing</parameter> <type>boolean</type> </optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Returns <parameter>target</parameter>
- with the item designated by <parameter>path</parameter>
- replaced by <parameter>new_value</parameter>, or with
- <parameter>new_value</parameter> added if
- <parameter>create_if_missing</parameter> is true (which is the
- default) and the item designated by <parameter>path</parameter>
- does not exist.
- All earlier steps in the path must exist, or
- the <parameter>target</parameter> is returned unchanged.
- As with the path oriented operators, negative integers that
- appear in the <parameter>path</parameter> count from the end
- of JSON arrays.
- If the last path step is an array index that is out of range,
- and <parameter>create_if_missing</parameter> is true, the new
- value is added at the beginning of the array if the index is negative,
- or at the end of the array if it is positive.
- </para>
- <para>
- <literal>jsonb_set('[{"f1":1,"f2":null},2,null,3]', '{0,f1}', '[2,3,4]', false)</literal>
- <returnvalue>[{"f1": [2, 3, 4], "f2": null}, 2, null, 3]</returnvalue>
- </para>
- <para>
- <literal>jsonb_set('[{"f1":1,"f2":null},2]', '{0,f3}', '[2,3,4]')</literal>
- <returnvalue>[{"f1": 1, "f2": null, "f3": [2, 3, 4]}, 2]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_set_lax</primary>
- </indexterm>
- <function>jsonb_set_lax</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>create_if_missing</parameter> <type>boolean</type> <optional>, <parameter>null_value_treatment</parameter> <type>text</type> </optional></optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- If <parameter>new_value</parameter> is not <literal>NULL</literal>,
- behaves identically to <literal>jsonb_set</literal>. Otherwise behaves
- according to the value
- of <parameter>null_value_treatment</parameter> which must be one
- of <literal>'raise_exception'</literal>,
- <literal>'use_json_null'</literal>, <literal>'delete_key'</literal>, or
- <literal>'return_target'</literal>. The default is
- <literal>'use_json_null'</literal>.
- </para>
- <para>
- <literal>jsonb_set_lax('[{"f1":1,"f2":null},2,null,3]', '{0,f1}', null)</literal>
- <returnvalue>[{"f1": null, "f2": null}, 2, null, 3]</returnvalue>
- </para>
- <para>
- <literal>jsonb_set_lax('[{"f1":99,"f2":null},2]', '{0,f3}', null, true, 'return_target')</literal>
- <returnvalue>[{"f1": 99, "f2": null}, 2]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_insert</primary>
- </indexterm>
- <function>jsonb_insert</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>text[]</type>, <parameter>new_value</parameter> <type>jsonb</type> <optional>, <parameter>insert_after</parameter> <type>boolean</type> </optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Returns <parameter>target</parameter>
- with <parameter>new_value</parameter> inserted. If the item
- designated by the <parameter>path</parameter> is an array
- element, <parameter>new_value</parameter> will be inserted before
- that item if <parameter>insert_after</parameter> is false (which
- is the default), or after it
- if <parameter>insert_after</parameter> is true. If the item
- designated by the <parameter>path</parameter> is an object
- field, <parameter>new_value</parameter> will be inserted only if
- the object does not already contain that key.
- All earlier steps in the path must exist, or
- the <parameter>target</parameter> is returned unchanged.
- As with the path oriented operators, negative integers that
- appear in the <parameter>path</parameter> count from the end
- of JSON arrays.
- If the last path step is an array index that is out of range, the new
- value is added at the beginning of the array if the index is negative,
- or at the end of the array if it is positive.
- </para>
- <para>
- <literal>jsonb_insert('{"a": [0,1,2]}', '{a, 1}', '"new_value"')</literal>
- <returnvalue>{"a": [0, "new_value", 1, 2]}</returnvalue>
- </para>
- <para>
- <literal>jsonb_insert('{"a": [0,1,2]}', '{a, 1}', '"new_value"', true)</literal>
- <returnvalue>{"a": [0, 1, "new_value", 2]}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_strip_nulls</primary>
- </indexterm>
- <function>json_strip_nulls</function> ( <type>json</type> )
- <returnvalue>json</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_strip_nulls</primary>
- </indexterm>
- <function>jsonb_strip_nulls</function> ( <type>jsonb</type> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Deletes all object fields that have null values from the given JSON
- value, recursively. Null values that are not object fields are
- untouched.
- </para>
- <para>
- <literal>json_strip_nulls('[{"f1":1, "f2":null}, 2, null, 3]')</literal>
- <returnvalue>[{"f1":1},2,null,3]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_exists</primary>
- </indexterm>
- <function>jsonb_path_exists</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Checks whether the JSON path returns any item for the specified JSON
- value.
- (This is useful only with SQL-standard JSON path expressions, not
- <link linkend="functions-sqljson-check-expressions">predicate check
- expressions</link>, since those always return a value.)
- If the <parameter>vars</parameter> argument is specified, it must
- be a JSON object, and its fields provide named values to be
- substituted into the <type>jsonpath</type> expression.
- If the <parameter>silent</parameter> argument is specified and
- is <literal>true</literal>, the function suppresses the same errors
- as the <literal>@?</literal> and <literal>@@</literal> operators do.
- </para>
- <para>
- <literal>jsonb_path_exists('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_match</primary>
- </indexterm>
- <function>jsonb_path_match</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns the result of a JSON path predicate check for the specified
- JSON value.
- (This is useful only
- with <link linkend="functions-sqljson-check-expressions">predicate
- check expressions</link>, not SQL-standard JSON path expressions,
- since it will either fail or return <literal>NULL</literal> if the
- path result is not a single boolean value.)
- The optional <parameter>vars</parameter>
- and <parameter>silent</parameter> arguments act the same as
- for <function>jsonb_path_exists</function>.
- </para>
- <para>
- <literal>jsonb_path_match('{"a":[1,2,3,4,5]}', 'exists($.a[*] ? (@ >= $min && @ <= $max))', '{"min":2, "max":4}')</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query</primary>
- </indexterm>
- <function>jsonb_path_query</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>setof jsonb</returnvalue>
- </para>
- <para>
- Returns all JSON items returned by the JSON path for the specified
- JSON value.
- For SQL-standard JSON path expressions it returns the JSON
- values selected from <parameter>target</parameter>.
- For <link linkend="functions-sqljson-check-expressions">predicate
- check expressions</link> it returns the result of the predicate
- check: <literal>true</literal>, <literal>false</literal>,
- or <literal>null</literal>.
- The optional <parameter>vars</parameter>
- and <parameter>silent</parameter> arguments act the same as
- for <function>jsonb_path_exists</function>.
- </para>
- <para>
- <literal>select * from jsonb_path_query('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
- <returnvalue></returnvalue>
-<programlisting>
- jsonb_path_query
-------------------
- 2
- 3
- 4
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query_array</primary>
- </indexterm>
- <function>jsonb_path_query_array</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Returns all JSON items returned by the JSON path for the specified
- JSON value, as a JSON array.
- The parameters are the same as
- for <function>jsonb_path_query</function>.
- </para>
- <para>
- <literal>jsonb_path_query_array('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
- <returnvalue>[2, 3, 4]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query_first</primary>
- </indexterm>
- <function>jsonb_path_query_first</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- Returns the first JSON item returned by the JSON path for the
- specified JSON value, or <literal>NULL</literal> if there are no
- results.
- The parameters are the same as
- for <function>jsonb_path_query</function>.
- </para>
- <para>
- <literal>jsonb_path_query_first('{"a":[1,2,3,4,5]}', '$.a[*] ? (@ >= $min && @ <= $max)', '{"min":2, "max":4}')</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_path_exists_tz</primary>
- </indexterm>
- <function>jsonb_path_exists_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_path_match_tz</primary>
- </indexterm>
- <function>jsonb_path_match_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query_tz</primary>
- </indexterm>
- <function>jsonb_path_query_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>setof jsonb</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query_array_tz</primary>
- </indexterm>
- <function>jsonb_path_query_array_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_path_query_first_tz</primary>
- </indexterm>
- <function>jsonb_path_query_first_tz</function> ( <parameter>target</parameter> <type>jsonb</type>, <parameter>path</parameter> <type>jsonpath</type> <optional>, <parameter>vars</parameter> <type>jsonb</type> <optional>, <parameter>silent</parameter> <type>boolean</type> </optional></optional> )
- <returnvalue>jsonb</returnvalue>
- </para>
- <para>
- These functions act like their counterparts described above without
- the <literal>_tz</literal> suffix, except that these functions support
- comparisons of date/time values that require timezone-aware
- conversions. The example below requires interpretation of the
- date-only value <literal>2015-08-02</literal> as a timestamp with time
- zone, so the result depends on the current
- <xref linkend="guc-timezone"/> setting. Due to this dependency, these
- functions are marked as stable, which means these functions cannot be
- used in indexes. Their counterparts are immutable, and so can be used
- in indexes; but they will throw errors if asked to make such
- comparisons.
- </para>
- <para>
- <literal>jsonb_path_exists_tz('["2015-08-01 12:00:00-05"]', '$[*] ? (@.datetime() < "2015-08-02".datetime())')</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>jsonb_pretty</primary>
- </indexterm>
- <function>jsonb_pretty</function> ( <type>jsonb</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts the given JSON value to pretty-printed, indented text.
- </para>
- <para>
- <literal>jsonb_pretty('[{"f1":1,"f2":null}, 2]')</literal>
- <returnvalue></returnvalue>
-<programlisting>
-[
- {
- "f1": 1,
- "f2": null
- },
- 2
-]
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>json_typeof</primary>
- </indexterm>
- <function>json_typeof</function> ( <type>json</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <indexterm>
- <primary>jsonb_typeof</primary>
- </indexterm>
- <function>jsonb_typeof</function> ( <type>jsonb</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the type of the top-level JSON value as a text string.
- Possible types are
- <literal>object</literal>, <literal>array</literal>,
- <literal>string</literal>, <literal>number</literal>,
- <literal>boolean</literal>, and <literal>null</literal>.
- (The <literal>null</literal> result should not be confused
- with an SQL NULL; see the examples.)
- </para>
- <para>
- <literal>json_typeof('-123.4')</literal>
- <returnvalue>number</returnvalue>
- </para>
- <para>
- <literal>json_typeof('null'::json)</literal>
- <returnvalue>null</returnvalue>
- </para>
- <para>
- <literal>json_typeof(NULL::json) IS NULL</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </sect2>
-
- <sect2 id="functions-sqljson-path">
- <title>The SQL/JSON Path Language</title>
-
- <indexterm zone="functions-sqljson-path">
- <primary>SQL/JSON path language</primary>
- </indexterm>
-
- <para>
- SQL/JSON path expressions specify item(s) to be retrieved
- from a JSON value, similarly to XPath expressions used
- for access to XML content. In <productname>PostgreSQL</productname>,
- path expressions are implemented as the <type>jsonpath</type>
- data type and can use any elements described in
- <xref linkend="datatype-jsonpath"/>.
- </para>
-
- <para>
- JSON query functions and operators
- pass the provided path expression to the <firstterm>path engine</firstterm>
- for evaluation. If the expression matches the queried JSON data,
- the corresponding JSON item, or set of items, is returned.
- If there is no match, the result will be <literal>NULL</literal>,
- <literal>false</literal>, or an error, depending on the function.
- Path expressions are written in the SQL/JSON path language
- and can include arithmetic expressions and functions.
- </para>
-
- <para>
- A path expression consists of a sequence of elements allowed
- by the <type>jsonpath</type> data type.
- The path expression is normally evaluated from left to right, but
- you can use parentheses to change the order of operations.
- If the evaluation is successful, a sequence of JSON items is produced,
- and the evaluation result is returned to the JSON query function
- that completes the specified computation.
- </para>
-
- <para>
- To refer to the JSON value being queried (the
- <firstterm>context item</firstterm>), use the <literal>$</literal> variable
- in the path expression. The first element of a path must always
- be <literal>$</literal>. It can be followed by one or more
- <link linkend="type-jsonpath-accessors">accessor operators</link>,
- which go down the JSON structure level by level to retrieve sub-items
- of the context item. Each accessor operator acts on the
- result(s) of the previous evaluation step, producing zero, one, or more
- output items from each input item.
- </para>
-
- <para>
- For example, suppose you have some JSON data from a GPS tracker that you
- would like to parse, such as:
-<programlisting>
-SELECT '{
- "track": {
- "segments": [
- {
- "location": [ 47.763, 13.4034 ],
- "start time": "2018-10-14 10:05:14",
- "HR": 73
- },
- {
- "location": [ 47.706, 13.2635 ],
- "start time": "2018-10-14 10:39:21",
- "HR": 135
- }
- ]
- }
-}' AS json \gset
-</programlisting>
- (The above example can be copied-and-pasted
- into <application>psql</application> to set things up for the following
- examples. Then <application>psql</application> will
- expand <literal>:'json'</literal> into a suitably-quoted string
- constant containing the JSON value.)
- </para>
-
- <para>
- To retrieve the available track segments, you need to use the
- <literal>.<replaceable>key</replaceable></literal> accessor
- operator to descend through surrounding JSON objects, for example:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments');</userinput>
- jsonb_path_query
------------------------------------------------------------&zwsp;-----------------------------------------------------------&zwsp;---------------------------------------------
- [{"HR": 73, "location": [47.763, 13.4034], "start time": "2018-10-14 10:05:14"}, {"HR": 135, "location": [47.706, 13.2635], "start time": "2018-10-14 10:39:21"}]
-</screen>
- </para>
-
- <para>
- To retrieve the contents of an array, you typically use the
- <literal>[*]</literal> operator.
- The following example will return the location coordinates for all
- the available track segments:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].location');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
- [47.706, 13.2635]
-</screen>
- Here we started with the whole JSON input value (<literal>$</literal>),
- then the <literal>.track</literal> accessor selected the JSON object
- associated with the <literal>"track"</literal> object key, then
- the <literal>.segments</literal> accessor selected the JSON array
- associated with the <literal>"segments"</literal> key within that
- object, then the <literal>[*]</literal> accessor selected each element
- of that array (producing a series of items), then
- the <literal>.location</literal> accessor selected the JSON array
- associated with the <literal>"location"</literal> key within each of
- those objects. In this example, each of those objects had
- a <literal>"location"</literal> key; but if any of them did not,
- the <literal>.location</literal> accessor would have simply produced no
- output for that input item.
- </para>
-
- <para>
- To return the coordinates of the first segment only, you can
- specify the corresponding subscript in the <literal>[]</literal>
- accessor operator. Recall that JSON array indexes are 0-relative:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[0].location');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
-</screen>
- </para>
-
- <para>
- The result of each path evaluation step can be processed
- by one or more of the <type>jsonpath</type> operators and methods
- listed in <xref linkend="functions-sqljson-path-operators"/>.
- Each method name must be preceded by a dot. For example,
- you can get the size of an array:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments.size()');</userinput>
- jsonb_path_query
-------------------
- 2
-</screen>
- More examples of using <type>jsonpath</type> operators
- and methods within path expressions appear below in
- <xref linkend="functions-sqljson-path-operators"/>.
- </para>
-
- <para>
- A path can also contain
- <firstterm>filter expressions</firstterm> that work similarly to the
- <literal>WHERE</literal> clause in SQL. A filter expression begins with
- a question mark and provides a condition in parentheses:
-
-<synopsis>
-? (<replaceable>condition</replaceable>)
-</synopsis>
- </para>
-
- <para>
- Filter expressions must be written just after the path evaluation step
- to which they should apply. The result of that step is filtered to include
- only those items that satisfy the provided condition. SQL/JSON defines
- three-valued logic, so the condition can
- produce <literal>true</literal>, <literal>false</literal>,
- or <literal>unknown</literal>. The <literal>unknown</literal> value
- plays the same role as SQL <literal>NULL</literal> and can be tested
- for with the <literal>is unknown</literal> predicate. Further path
- evaluation steps use only those items for which the filter expression
- returned <literal>true</literal>.
- </para>
-
- <para>
- The functions and operators that can be used in filter expressions are
- listed in <xref linkend="functions-sqljson-filter-ex-table"/>. Within a
- filter expression, the <literal>@</literal> variable denotes the value
- being considered (i.e., one result of the preceding path step). You can
- write accessor operators after <literal>@</literal> to retrieve component
- items.
- </para>
-
- <para>
- For example, suppose you would like to retrieve all heart rate values higher
- than 130. You can achieve this as follows:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].HR ? (@ > 130)');</userinput>
- jsonb_path_query
-------------------
- 135
-</screen>
- </para>
-
- <para>
- To get the start times of segments with such values, you have to
- filter out irrelevant segments before selecting the start times, so the
- filter expression is applied to the previous step, and the path used
- in the condition is different:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.HR > 130)."start time"');</userinput>
- jsonb_path_query
------------------------
- "2018-10-14 10:39:21"
-</screen>
- </para>
-
- <para>
- You can use several filter expressions in sequence, if required.
- The following example selects start times of all segments that
- contain locations with relevant coordinates and high heart rate values:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.location[1] < 13.4) ? (@.HR > 130)."start time"');</userinput>
- jsonb_path_query
------------------------
- "2018-10-14 10:39:21"
-</screen>
- </para>
-
- <para>
- Using filter expressions at different nesting levels is also allowed.
- The following example first filters all segments by location, and then
- returns high heart rate values for these segments, if available:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*] ? (@.location[1] < 13.4).HR ? (@ > 130)');</userinput>
- jsonb_path_query
-------------------
- 135
-</screen>
- </para>
-
- <para>
- You can also nest filter expressions within each other.
- This example returns the size of the track if it contains any
- segments with high heart rate values, or an empty sequence otherwise:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track ? (exists(@.segments[*] ? (@.HR > 130))).segments.size()');</userinput>
- jsonb_path_query
-------------------
- 2
-</screen>
- </para>
-
- <sect3 id="functions-sqljson-deviations">
- <title>Deviations from the SQL Standard</title>
- <para>
- <productname>PostgreSQL</productname>'s implementation of the SQL/JSON path
- language has the following deviations from the SQL/JSON standard.
- </para>
-
- <sect4 id="functions-sqljson-check-expressions">
- <title>Boolean Predicate Check Expressions</title>
- <para>
- As an extension to the SQL standard,
- a <productname>PostgreSQL</productname> path expression can be a
- Boolean predicate, whereas the SQL standard allows predicates only within
- filters. While SQL-standard path expressions return the relevant
- element(s) of the queried JSON value, predicate check expressions
- return the single three-valued result of the
- predicate: <literal>true</literal>,
- <literal>false</literal>, or <literal>unknown</literal>.
- For example, we could write this SQL-standard filter expression:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments ?(@[*].HR > 130)');</userinput>
- jsonb_path_query
------------------------------------------------------------&zwsp;----------------------
- {"HR": 135, "location": [47.706, 13.2635], "start time": "2018-10-14 10:39:21"}
-</screen>
- The similar predicate check expression simply
- returns <literal>true</literal>, indicating that a match exists:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', '$.track.segments[*].HR > 130');</userinput>
- jsonb_path_query
-------------------
- true
-</screen>
- </para>
-
- <note>
- <para>
- Predicate check expressions are required in the
- <literal>@@</literal> operator (and the
- <function>jsonb_path_match</function> function), and should not be used
- with the <literal>@?</literal> operator (or the
- <function>jsonb_path_exists</function> function).
- </para>
- </note>
- </sect4>
-
- <sect4 id="functions-sqljson-regular-expression-deviation">
- <title>Regular Expression Interpretation</title>
- <para>
- There are minor differences in the interpretation of regular
- expression patterns used in <literal>like_regex</literal> filters, as
- described in <xref linkend="jsonpath-regular-expressions"/>.
- </para>
- </sect4>
- </sect3>
-
- <sect3 id="functions-sqljson-strict-and-lax-modes">
- <title>Strict and Lax Modes</title>
- <para>
- When you query JSON data, the path expression may not match the
- actual JSON data structure. An attempt to access a non-existent
- member of an object or element of an array is defined as a
- structural error. SQL/JSON path expressions have two modes
- of handling structural errors:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- lax (default) — the path engine implicitly adapts
- the queried data to the specified path.
- Any structural errors that cannot be fixed as described below
- are suppressed, producing no match.
- </para>
- </listitem>
- <listitem>
- <para>
- strict — if a structural error occurs, an error is raised.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- Lax mode facilitates matching of a JSON document and path
- expression when the JSON data does not conform to the expected schema.
- If an operand does not match the requirements of a particular operation,
- it can be automatically wrapped as an SQL/JSON array, or unwrapped by
- converting its elements into an SQL/JSON sequence before performing
- the operation. Also, comparison operators automatically unwrap their
- operands in lax mode, so you can compare SQL/JSON arrays
- out-of-the-box. An array of size 1 is considered equal to its sole element.
- Automatic unwrapping is not performed when:
- <itemizedlist>
- <listitem>
- <para>
- The path expression contains <literal>type()</literal> or
- <literal>size()</literal> methods that return the type
- and the number of elements in the array, respectively.
- </para>
- </listitem>
- <listitem>
- <para>
- The queried JSON data contain nested arrays. In this case, only
- the outermost array is unwrapped, while all the inner arrays
- remain unchanged. Thus, implicit unwrapping can only go one
- level down within each path evaluation step.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- For example, when querying the GPS data listed above, you can
- abstract from the fact that it stores an array of segments
- when using lax mode:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments.location');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
- [47.706, 13.2635]
-</screen>
- </para>
-
- <para>
- In strict mode, the specified path must exactly match the structure of
- the queried JSON document, so using this path
- expression will cause an error:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments.location');</userinput>
-ERROR: jsonpath member accessor can only be applied to an object
-</screen>
- To get the same result as in lax mode, you have to explicitly unwrap the
- <literal>segments</literal> array:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments[*].location');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
- [47.706, 13.2635]
-</screen>
- </para>
-
- <para>
- The unwrapping behavior of lax mode can lead to surprising results. For
- instance, the following query using the <literal>.**</literal> accessor
- selects every <literal>HR</literal> value twice:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.**.HR');</userinput>
- jsonb_path_query
-------------------
- 73
- 135
- 73
- 135
-</screen>
- This happens because the <literal>.**</literal> accessor selects both
- the <literal>segments</literal> array and each of its elements, while
- the <literal>.HR</literal> accessor automatically unwraps arrays when
- using lax mode. To avoid surprising results, we recommend using
- the <literal>.**</literal> accessor only in strict mode. The
- following query selects each <literal>HR</literal> value just once:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.**.HR');</userinput>
- jsonb_path_query
-------------------
- 73
- 135
-</screen>
- </para>
-
- <para>
- The unwrapping of arrays can also lead to unexpected results. Consider this
- example, which selects all the <literal>location</literal> arrays:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments[*].location');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
- [47.706, 13.2635]
-(2 rows)
-</screen>
- As expected it returns the full arrays. But applying a filter expression
- causes the arrays to be unwrapped to evaluate each item, returning only the
- items that match the expression:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'lax $.track.segments[*].location ?(@[*] > 15)');</userinput>
- jsonb_path_query
-------------------
- 47.763
- 47.706
-(2 rows)
-</screen>
- This despite the fact that the full arrays are selected by the path
- expression. Use strict mode to restore selecting the arrays:
-<screen>
-<prompt>=></prompt> <userinput>select jsonb_path_query(:'json', 'strict $.track.segments[*].location ?(@[*] > 15)');</userinput>
- jsonb_path_query
--------------------
- [47.763, 13.4034]
- [47.706, 13.2635]
-(2 rows)
-</screen>
- </para>
- </sect3>
-
- <sect3 id="functions-sqljson-path-operators">
- <title>SQL/JSON Path Operators and Methods</title>
-
- <para>
- <xref linkend="functions-sqljson-op-table"/> shows the operators and
- methods available in <type>jsonpath</type>. Note that while the unary
- operators and methods can be applied to multiple values resulting from a
- preceding path step, the binary operators (addition etc.) can only be
- applied to single values.
- </para>
-
- <table id="functions-sqljson-op-table">
- <title><type>jsonpath</type> Operators and Methods</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator/Method
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>+</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Addition
- </para>
- <para>
- <literal>jsonb_path_query('[2]', '$[0] + 3')</literal>
- <returnvalue>5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>+</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Unary plus (no operation); unlike addition, this can iterate over
- multiple values
- </para>
- <para>
- <literal>jsonb_path_query_array('{"x": [2,3,4]}', '+ $.x')</literal>
- <returnvalue>[2, 3, 4]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>-</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Subtraction
- </para>
- <para>
- <literal>jsonb_path_query('[2]', '7 - $[0]')</literal>
- <returnvalue>5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>-</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Negation; unlike subtraction, this can iterate over
- multiple values
- </para>
- <para>
- <literal>jsonb_path_query_array('{"x": [2,3,4]}', '- $.x')</literal>
- <returnvalue>[-2, -3, -4]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>*</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Multiplication
- </para>
- <para>
- <literal>jsonb_path_query('[4]', '2 * $[0]')</literal>
- <returnvalue>8</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>/</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Division
- </para>
- <para>
- <literal>jsonb_path_query('[8.5]', '$[0] / 2')</literal>
- <returnvalue>4.2500000000000000</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>%</literal> <replaceable>number</replaceable>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Modulo (remainder)
- </para>
- <para>
- <literal>jsonb_path_query('[32]', '$[0] % 10')</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>type()</literal>
- <returnvalue><replaceable>string</replaceable></returnvalue>
- </para>
- <para>
- Type of the JSON item (see <function>json_typeof</function>)
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, "2", {}]', '$[*].type()')</literal>
- <returnvalue>["number", "string", "object"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>size()</literal>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Size of the JSON item (number of array elements, or 1 if not an
- array)
- </para>
- <para>
- <literal>jsonb_path_query('{"m": [11, 15]}', '$.m.size()')</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>boolean()</literal>
- <returnvalue><replaceable>boolean</replaceable></returnvalue>
- </para>
- <para>
- Boolean value converted from a JSON boolean, number, or string
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, "yes", false]', '$[*].boolean()')</literal>
- <returnvalue>[true, true, false]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>string()</literal>
- <returnvalue><replaceable>string</replaceable></returnvalue>
- </para>
- <para>
- String value converted from a JSON boolean, number, string, or datetime
- </para>
- <para>
- <literal>jsonb_path_query_array('[1.23, "xyz", false]', '$[*].string()')</literal>
- <returnvalue>["1.23", "xyz", "false"]</returnvalue>
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15"', '$.datetime().string()')</literal>
- <returnvalue>"2023-08-15"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>double()</literal>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Approximate floating-point number converted from a JSON number or
- string
- </para>
- <para>
- <literal>jsonb_path_query('{"len": "1.9"}', '$.len.double() * 2')</literal>
- <returnvalue>3.8</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>.</literal> <literal>ceiling()</literal>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Nearest integer greater than or equal to the given number
- </para>
- <para>
- <literal>jsonb_path_query('{"h": 1.3}', '$.h.ceiling()')</literal>
- <returnvalue>2</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>.</literal> <literal>floor()</literal>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Nearest integer less than or equal to the given number
- </para>
- <para>
- <literal>jsonb_path_query('{"h": 1.7}', '$.h.floor()')</literal>
- <returnvalue>1</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>number</replaceable> <literal>.</literal> <literal>abs()</literal>
- <returnvalue><replaceable>number</replaceable></returnvalue>
- </para>
- <para>
- Absolute value of the given number
- </para>
- <para>
- <literal>jsonb_path_query('{"z": -0.3}', '$.z.abs()')</literal>
- <returnvalue>0.3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>bigint()</literal>
- <returnvalue><replaceable>bigint</replaceable></returnvalue>
- </para>
- <para>
- Big integer value converted from a JSON number or string
- </para>
- <para>
- <literal>jsonb_path_query('{"len": "9876543219"}', '$.len.bigint()')</literal>
- <returnvalue>9876543219</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>decimal( [ <replaceable>precision</replaceable> [ , <replaceable>scale</replaceable> ] ] )</literal>
- <returnvalue><replaceable>decimal</replaceable></returnvalue>
- </para>
- <para>
- Rounded decimal value converted from a JSON number or string. <literal>precision</literal> and <literal>scale</literal> must be integer values.
- </para>
- <para>
- <literal>jsonb_path_query('1234.5678', '$.decimal(6, 2)')</literal>
- <returnvalue>1234.57</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>integer()</literal>
- <returnvalue><replaceable>integer</replaceable></returnvalue>
- </para>
- <para>
- Integer value converted from a JSON number or string
- </para>
- <para>
- <literal>jsonb_path_query('{"len": "12345"}', '$.len.integer()')</literal>
- <returnvalue>12345</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>.</literal> <literal>number()</literal>
- <returnvalue><replaceable>numeric</replaceable></returnvalue>
- </para>
- <para>
- Numeric value converted from a JSON number or string
- </para>
- <para>
- <literal>jsonb_path_query('{"len": "123.45"}', '$.len.number()')</literal>
- <returnvalue>123.45</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>datetime()</literal>
- <returnvalue><replaceable>datetime_type</replaceable></returnvalue>
- (see note)
- </para>
- <para>
- Date/time value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('["2015-8-1", "2015-08-12"]', '$[*] ? (@.datetime() < "2015-08-2".datetime())')</literal>
- <returnvalue>"2015-8-1"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>datetime(<replaceable>template</replaceable>)</literal>
- <returnvalue><replaceable>datetime_type</replaceable></returnvalue>
- (see note)
- </para>
- <para>
- Date/time value converted from a string using the
- specified <function>to_timestamp</function> template
- </para>
- <para>
- <literal>jsonb_path_query_array('["12:30", "18:40"]', '$[*].datetime("HH24:MI")')</literal>
- <returnvalue>["12:30:00", "18:40:00"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>date()</literal>
- <returnvalue><replaceable>date</replaceable></returnvalue>
- </para>
- <para>
- Date value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15"', '$.date()')</literal>
- <returnvalue>"2023-08-15"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>time()</literal>
- <returnvalue><replaceable>time without time zone</replaceable></returnvalue>
- </para>
- <para>
- Time without time zone value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('"12:34:56"', '$.time()')</literal>
- <returnvalue>"12:34:56"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>time(<replaceable>precision</replaceable>)</literal>
- <returnvalue><replaceable>time without time zone</replaceable></returnvalue>
- </para>
- <para>
- Time without time zone value converted from a string, with fractional
- seconds adjusted to the given precision.
- </para>
- <para>
- <literal>jsonb_path_query('"12:34:56.789"', '$.time(2)')</literal>
- <returnvalue>"12:34:56.79"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>time_tz()</literal>
- <returnvalue><replaceable>time with time zone</replaceable></returnvalue>
- </para>
- <para>
- Time with time zone value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('"12:34:56 +05:30"', '$.time_tz()')</literal>
- <returnvalue>"12:34:56+05:30"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>time_tz(<replaceable>precision</replaceable>)</literal>
- <returnvalue><replaceable>time with time zone</replaceable></returnvalue>
- </para>
- <para>
- Time with time zone value converted from a string, with fractional
- seconds adjusted to the given precision.
- </para>
- <para>
- <literal>jsonb_path_query('"12:34:56.789 +05:30"', '$.time_tz(2)')</literal>
- <returnvalue>"12:34:56.79+05:30"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp()</literal>
- <returnvalue><replaceable>timestamp without time zone</replaceable></returnvalue>
- </para>
- <para>
- Timestamp without time zone value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15 12:34:56"', '$.timestamp()')</literal>
- <returnvalue>"2023-08-15T12:34:56"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp(<replaceable>precision</replaceable>)</literal>
- <returnvalue><replaceable>timestamp without time zone</replaceable></returnvalue>
- </para>
- <para>
- Timestamp without time zone value converted from a string, with
- fractional seconds adjusted to the given precision.
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15 12:34:56.789"', '$.timestamp(2)')</literal>
- <returnvalue>"2023-08-15T12:34:56.79"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp_tz()</literal>
- <returnvalue><replaceable>timestamp with time zone</replaceable></returnvalue>
- </para>
- <para>
- Timestamp with time zone value converted from a string
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15 12:34:56 +05:30"', '$.timestamp_tz()')</literal>
- <returnvalue>"2023-08-15T12:34:56+05:30"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>.</literal> <literal>timestamp_tz(<replaceable>precision</replaceable>)</literal>
- <returnvalue><replaceable>timestamp with time zone</replaceable></returnvalue>
- </para>
- <para>
- Timestamp with time zone value converted from a string, with fractional
- seconds adjusted to the given precision.
- </para>
- <para>
- <literal>jsonb_path_query('"2023-08-15 12:34:56.789 +05:30"', '$.timestamp_tz(2)')</literal>
- <returnvalue>"2023-08-15T12:34:56.79+05:30"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>object</replaceable> <literal>.</literal> <literal>keyvalue()</literal>
- <returnvalue><replaceable>array</replaceable></returnvalue>
- </para>
- <para>
- The object's key-value pairs, represented as an array of objects
- containing three fields: <literal>"key"</literal>,
- <literal>"value"</literal>, and <literal>"id"</literal>;
- <literal>"id"</literal> is a unique identifier of the object the
- key-value pair belongs to
- </para>
- <para>
- <literal>jsonb_path_query_array('{"x": "20", "y": 32}', '$.keyvalue()')</literal>
- <returnvalue>[{"id": 0, "key": "x", "value": "20"}, {"id": 0, "key": "y", "value": 32}]</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <note>
- <para>
- The result type of the <literal>datetime()</literal> and
- <literal>datetime(<replaceable>template</replaceable>)</literal>
- methods can be <type>date</type>, <type>timetz</type>, <type>time</type>,
- <type>timestamptz</type>, or <type>timestamp</type>.
- Both methods determine their result type dynamically.
- </para>
- <para>
- The <literal>datetime()</literal> method sequentially tries to
- match its input string to the ISO formats
- for <type>date</type>, <type>timetz</type>, <type>time</type>,
- <type>timestamptz</type>, and <type>timestamp</type>. It stops on
- the first matching format and emits the corresponding data type.
- </para>
- <para>
- The <literal>datetime(<replaceable>template</replaceable>)</literal>
- method determines the result type according to the fields used in the
- provided template string.
- </para>
- <para>
- The <literal>datetime()</literal> and
- <literal>datetime(<replaceable>template</replaceable>)</literal> methods
- use the same parsing rules as the <literal>to_timestamp</literal> SQL
- function does (see <xref linkend="functions-formatting"/>), with three
- exceptions. First, these methods don't allow unmatched template
- patterns. Second, only the following separators are allowed in the
- template string: minus sign, period, solidus (slash), comma, apostrophe,
- semicolon, colon and space. Third, separators in the template string
- must exactly match the input string.
- </para>
- <para>
- If different date/time types need to be compared, an implicit cast is
- applied. A <type>date</type> value can be cast to <type>timestamp</type>
- or <type>timestamptz</type>, <type>timestamp</type> can be cast to
- <type>timestamptz</type>, and <type>time</type> to <type>timetz</type>.
- However, all but the first of these conversions depend on the current
- <xref linkend="guc-timezone"/> setting, and thus can only be performed
- within timezone-aware <type>jsonpath</type> functions. Similarly, other
- date/time-related methods that convert strings to date/time types
- also do this casting, which may involve the current
- <xref linkend="guc-timezone"/> setting. Therefore, these conversions can
- also only be performed within timezone-aware <type>jsonpath</type>
- functions.
- </para>
- </note>
-
- <para>
- <xref linkend="functions-sqljson-filter-ex-table"/> shows the available
- filter expression elements.
- </para>
-
- <table id="functions-sqljson-filter-ex-table">
- <title><type>jsonpath</type> Filter Expression Elements</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Predicate/Value
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>==</literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Equality comparison (this, and the other comparison operators, work on
- all JSON scalar values)
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, "a", 1, 3]', '$[*] ? (@ == 1)')</literal>
- <returnvalue>[1, 1]</returnvalue>
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, "a", 1, 3]', '$[*] ? (@ == "a")')</literal>
- <returnvalue>["a"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>!=</literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <replaceable>value</replaceable> <literal><></literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Non-equality comparison
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, 2, 1, 3]', '$[*] ? (@ != 1)')</literal>
- <returnvalue>[2, 3]</returnvalue>
- </para>
- <para>
- <literal>jsonb_path_query_array('["a", "b", "c"]', '$[*] ? (@ <> "b")')</literal>
- <returnvalue>["a", "c"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal><</literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Less-than comparison
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ < 2)')</literal>
- <returnvalue>[1]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal><=</literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Less-than-or-equal-to comparison
- </para>
- <para>
- <literal>jsonb_path_query_array('["a", "b", "c"]', '$[*] ? (@ <= "b")')</literal>
- <returnvalue>["a", "b"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>></literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Greater-than comparison
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ > 2)')</literal>
- <returnvalue>[3]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>value</replaceable> <literal>>=</literal> <replaceable>value</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Greater-than-or-equal-to comparison
- </para>
- <para>
- <literal>jsonb_path_query_array('[1, 2, 3]', '$[*] ? (@ >= 2)')</literal>
- <returnvalue>[2, 3]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>true</literal>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- JSON constant <literal>true</literal>
- </para>
- <para>
- <literal>jsonb_path_query('[{"name": "John", "parent": false}, {"name": "Chris", "parent": true}]', '$[*] ? (@.parent == true)')</literal>
- <returnvalue>{"name": "Chris", "parent": true}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>false</literal>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- JSON constant <literal>false</literal>
- </para>
- <para>
- <literal>jsonb_path_query('[{"name": "John", "parent": false}, {"name": "Chris", "parent": true}]', '$[*] ? (@.parent == false)')</literal>
- <returnvalue>{"name": "John", "parent": false}</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>null</literal>
- <returnvalue><replaceable>value</replaceable></returnvalue>
- </para>
- <para>
- JSON constant <literal>null</literal> (note that, unlike in SQL,
- comparison to <literal>null</literal> works normally)
- </para>
- <para>
- <literal>jsonb_path_query('[{"name": "Mary", "job": null}, {"name": "Michael", "job": "driver"}]', '$[*] ? (@.job == null) .name')</literal>
- <returnvalue>"Mary"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>boolean</replaceable> <literal>&&</literal> <replaceable>boolean</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Boolean AND
- </para>
- <para>
- <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (@ > 1 && @ < 5)')</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>boolean</replaceable> <literal>||</literal> <replaceable>boolean</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Boolean OR
- </para>
- <para>
- <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (@ < 1 || @ > 5)')</literal>
- <returnvalue>7</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>!</literal> <replaceable>boolean</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Boolean NOT
- </para>
- <para>
- <literal>jsonb_path_query('[1, 3, 7]', '$[*] ? (!(@ < 5))')</literal>
- <returnvalue>7</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>boolean</replaceable> <literal>is unknown</literal>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether a Boolean condition is <literal>unknown</literal>.
- </para>
- <para>
- <literal>jsonb_path_query('[-1, 2, 7, "foo"]', '$[*] ? ((@ > 0) is unknown)')</literal>
- <returnvalue>"foo"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>like_regex</literal> <replaceable>string</replaceable> <optional> <literal>flag</literal> <replaceable>string</replaceable> </optional>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether the first operand matches the regular expression
- given by the second operand, optionally with modifications
- described by a string of <literal>flag</literal> characters (see
- <xref linkend="jsonpath-regular-expressions"/>).
- </para>
- <para>
- <literal>jsonb_path_query_array('["abc", "abd", "aBdC", "abdacb", "babc"]', '$[*] ? (@ like_regex "^ab.*c")')</literal>
- <returnvalue>["abc", "abdacb"]</returnvalue>
- </para>
- <para>
- <literal>jsonb_path_query_array('["abc", "abd", "aBdC", "abdacb", "babc"]', '$[*] ? (@ like_regex "^ab.*c" flag "i")')</literal>
- <returnvalue>["abc", "aBdC", "abdacb"]</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <replaceable>string</replaceable> <literal>starts with</literal> <replaceable>string</replaceable>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether the second operand is an initial substring of the first
- operand.
- </para>
- <para>
- <literal>jsonb_path_query('["John Smith", "Mary Stone", "Bob Johnson"]', '$[*] ? (@ starts with "John")')</literal>
- <returnvalue>"John Smith"</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>exists</literal> <literal>(</literal> <replaceable>path_expression</replaceable> <literal>)</literal>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Tests whether a path expression matches at least one SQL/JSON item.
- Returns <literal>unknown</literal> if the path expression would result
- in an error; the second example uses this to avoid a no-such-key error
- in strict mode.
- </para>
- <para>
- <literal>jsonb_path_query('{"x": [1, 2], "y": [2, 4]}', 'strict $.* ? (exists (@ ? (@[*] > 2)))')</literal>
- <returnvalue>[2, 4]</returnvalue>
- </para>
- <para>
- <literal>jsonb_path_query_array('{"value": 41}', 'strict $ ? (exists (@.name)) .name')</literal>
- <returnvalue>[]</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect3>
-
- <sect3 id="jsonpath-regular-expressions">
- <title>SQL/JSON Regular Expressions</title>
-
- <indexterm zone="jsonpath-regular-expressions">
- <primary><literal>LIKE_REGEX</literal></primary>
- <secondary>in SQL/JSON</secondary>
- </indexterm>
-
- <para>
- SQL/JSON path expressions allow matching text to a regular expression
- with the <literal>like_regex</literal> filter. For example, the
- following SQL/JSON path query would case-insensitively match all
- strings in an array that start with an English vowel:
-<programlisting>
-$[*] ? (@ like_regex "^[aeiou]" flag "i")
-</programlisting>
- </para>
-
- <para>
- The optional <literal>flag</literal> string may include one or more of
- the characters
- <literal>i</literal> for case-insensitive match,
- <literal>m</literal> to allow <literal>^</literal>
- and <literal>$</literal> to match at newlines,
- <literal>s</literal> to allow <literal>.</literal> to match a newline,
- and <literal>q</literal> to quote the whole pattern (reducing the
- behavior to a simple substring match).
- </para>
-
- <para>
- The SQL/JSON standard borrows its definition for regular expressions
- from the <literal>LIKE_REGEX</literal> operator, which in turn uses the
- XQuery standard. PostgreSQL does not currently support the
- <literal>LIKE_REGEX</literal> operator. Therefore,
- the <literal>like_regex</literal> filter is implemented using the
- POSIX regular expression engine described in
- <xref linkend="functions-posix-regexp"/>. This leads to various minor
- discrepancies from standard SQL/JSON behavior, which are cataloged in
- <xref linkend="posix-vs-xquery"/>.
- Note, however, that the flag-letter incompatibilities described there
- do not apply to SQL/JSON, as it translates the XQuery flag letters to
- match what the POSIX engine expects.
- </para>
-
- <para>
- Keep in mind that the pattern argument of <literal>like_regex</literal>
- is a JSON path string literal, written according to the rules given in
- <xref linkend="datatype-jsonpath"/>. This means in particular that any
- backslashes you want to use in the regular expression must be doubled.
- For example, to match string values of the root document that contain
- only digits:
-<programlisting>
-$.* ? (@ like_regex "^\\d+$")
-</programlisting>
- </para>
- </sect3>
- </sect2>
-
- <sect2 id="sqljson-query-functions">
- <title>SQL/JSON Query Functions</title>
- <para>
- SQL/JSON functions <literal>JSON_EXISTS()</literal>,
- <literal>JSON_QUERY()</literal>, and <literal>JSON_VALUE()</literal>
- described in <xref linkend="functions-sqljson-querying"/> can be used
- to query JSON documents. Each of these functions apply a
- <replaceable>path_expression</replaceable> (the query) to a
- <replaceable>context_item</replaceable> (the document); see
- <xref linkend="functions-sqljson-path"/> for more details on what
- <replaceable>path_expression</replaceable> can contain.
- </para>
-
- <table id="functions-sqljson-querying">
- <title>SQL/JSON Query Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function signature
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_exists</primary></indexterm>
- <function>json_exists</function> (
- <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
- <optional> { <literal>TRUE</literal> | <literal>FALSE</literal> |<literal> UNKNOWN</literal> | <literal>ERROR</literal> } <literal>ON ERROR</literal> </optional>)
- </para>
- <para>
- Returns true if the SQL/JSON <replaceable>path_expression</replaceable>
- applied to the <replaceable>context_item</replaceable> using the
- <literal>PASSING</literal> <replaceable>value</replaceable>s yields any
- items.
- </para>
- <para>
- The <literal>ON ERROR</literal> clause specifies the behavior if
- an error occurs; the default is to return the <type>boolean</type>
- <literal>FALSE</literal> value. Note that if the
- <replaceable>path_expression</replaceable> is <literal>strict</literal>
- and <literal>ON ERROR</literal> behavior is <literal>ERROR</literal>,
- an error is generated if it yields no items.
- </para>
- <para>
- Examples:
- </para>
- <para>
- <literal>select json_exists(jsonb '{"key1": [1,2,3]}', 'strict $.key1[*] ? (@ > 2)')</literal>
- <returnvalue>t</returnvalue>
- </para>
- <para>
- <literal>select json_exists(jsonb '{"a": [1,2,3]}', 'lax $.a[5]' ERROR ON ERROR)</literal>
- <returnvalue>f</returnvalue>
- </para>
- <para>
- <literal>select json_exists(jsonb '{"a": [1,2,3]}', 'strict $.a[5]' ERROR ON ERROR)</literal>
- <returnvalue></returnvalue>
-<programlisting>
-ERROR: jsonpath array subscript is out of bounds
-</programlisting>
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_query</primary></indexterm>
- <function>json_query</function> (
- <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> <optional> <literal>FORMAT JSON</literal> <optional> <literal>ENCODING UTF8</literal> </optional> </optional> </optional>
- <optional> { <literal>WITHOUT</literal> | <literal>WITH</literal> { <literal>CONDITIONAL</literal> | <optional><literal>UNCONDITIONAL</literal></optional> } } <optional> <literal>ARRAY</literal> </optional> <literal>WRAPPER</literal> </optional>
- <optional> { <literal>KEEP</literal> | <literal>OMIT</literal> } <literal>QUOTES</literal> <optional> <literal>ON SCALAR STRING</literal> </optional> </optional>
- <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>EMPTY</literal> { <optional> <literal>ARRAY</literal> </optional> | <literal>OBJECT</literal> } | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON EMPTY</literal> </optional>
- <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>EMPTY</literal> { <optional> <literal>ARRAY</literal> </optional> | <literal>OBJECT</literal> } | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON ERROR</literal> </optional>)
- </para>
- <para>
- Returns the result of applying the SQL/JSON
- <replaceable>path_expression</replaceable> to the
- <replaceable>context_item</replaceable> using the
- <literal>PASSING</literal> <replaceable>value</replaceable>s.
- </para>
- <para>
- If the path expression returns multiple SQL/JSON items, it might be
- necessary to wrap the result using the <literal>WITH WRAPPER</literal>
- clause to make it a valid JSON string. If the wrapper is
- <literal>UNCONDITIONAL</literal>, an array wrapper will always be
- applied, even if the returned value is already a single JSON object
- or an array. If it is <literal>CONDITIONAL</literal>, it will not be
- applied to a single JSON object or an array.
- <literal>UNCONDITIONAL</literal> is the default.
- </para>
- <para>
- If the result is a scalar string, by default, the returned value will
- be surrounded by quotes, making it a valid JSON value. It can be made
- explicit by specifying <literal>KEEP QUOTES</literal>. Conversely,
- quotes can be omitted by specifying <literal>OMIT QUOTES</literal>.
- Note that <literal>OMIT QUOTES</literal> cannot be specified when
- <literal>WITH WRAPPER</literal> is also specified.
- </para>
- <para>
- The <literal>RETURNING</literal> clause can be used to specify the
- <replaceable>data_type</replaceable> of the result value. By default,
- the returned value will be of type <type>jsonb</type>.
- </para>
- <para>
- The <literal>ON EMPTY</literal> clause specifies the behavior if
- evaluating <replaceable>path_expression</replaceable> yields no value
- at all. The default when <literal>ON EMPTY</literal> is not specified
- is to return a null value.
- </para>
- <para>
- The <literal>ON ERROR</literal> clause specifies the
- behavior if an error occurs when evaluating
- <replaceable>path_expression</replaceable>, including the operation to
- coerce the result value to the output type, or during the execution of
- <literal>ON EMPTY</literal> behavior (that is caused by empty result
- of <replaceable>path_expression</replaceable> evaluation). The default
- when <literal>ON ERROR</literal> is not specified is to return a null
- value.
- </para>
- <para>
- Examples:
- </para>
- <para>
- <literal>select json_query(jsonb '[1,[2,3],null]', 'lax $[*][1]' WITH CONDITIONAL WRAPPER)</literal>
- <returnvalue>[3]</returnvalue>
- </para>
- <para>
- <literal>select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a' OMIT QUOTES);</literal>
- <returnvalue>[1, 2]</returnvalue>
- </para>
- <para>
- <literal>select json_query(jsonb '{"a": "[1, 2]"}', 'lax $.a' RETURNING int[] OMIT QUOTES ERROR ON ERROR);</literal>
- <returnvalue></returnvalue>
-<programlisting>
-ERROR: malformed array literal: "[1, 2]"
-DETAIL: Missing "]" after array dimensions.
-</programlisting>
- </para>
- </entry>
- </row>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm><primary>json_value</primary></indexterm>
- <function>json_value</function> (
- <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable>
- <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional>
- <optional> <literal>RETURNING</literal> <replaceable>data_type</replaceable> </optional>
- <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON EMPTY</literal> </optional>
- <optional> { <literal>ERROR</literal> | <literal>NULL</literal> | <literal>DEFAULT</literal> <replaceable>expression</replaceable> } <literal>ON ERROR</literal> </optional>)
- </para>
- <para>
- Returns the result of applying the SQL/JSON
- <replaceable>path_expression</replaceable> to the
- <replaceable>context_item</replaceable> using the
- <literal>PASSING</literal> <replaceable>value</replaceable>s.
- </para>
- <para>
- The extracted value must be a single <acronym>SQL/JSON</acronym>
- scalar item; an error is thrown if that's not the case. If you expect
- that extracted value might be an object or an array, use the
- <function>json_query</function> function instead.
- </para>
- <para>
- The <literal>RETURNING</literal> clause can be used to specify the
- <replaceable>data_type</replaceable> of the result value. By default,
- the returned value will be of type <type>text</type>.
- </para>
- <para>
- The <literal>ON ERROR</literal> and <literal>ON EMPTY</literal>
- clauses have similar semantics as mentioned in the description of
- <function>json_query</function>.
- </para>
- <para>
- Note that scalar strings returned by <function>json_value</function>
- always have their quotes removed, equivalent to specifying
- <literal>OMIT QUOTES</literal> in <function>json_query</function>.
- </para>
- <para>
- Examples:
- </para>
- <para>
- <literal>select json_value(jsonb '"123.45"', '$' RETURNING float)</literal>
- <returnvalue>123.45</returnvalue>
- </para>
- <para>
- <literal>select json_value(jsonb '"03:04 2015-02-01"', '$.datetime("HH24:MI YYYY-MM-DD")' RETURNING date)</literal>
- <returnvalue>2015-02-01</returnvalue>
- </para>
- <para>
- <literal>select json_value(jsonb '[1,2]', 'strict $[*]' DEFAULT 9 ON ERROR)</literal>
- <returnvalue>9</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
- </sect2>
-
- <sect2 id="functions-sqljson-table">
- <title>JSON_TABLE</title>
- <indexterm>
- <primary>json_table</primary>
- </indexterm>
-
- <para>
- <function>JSON_TABLE</function> is an SQL/JSON function which
- queries <acronym>JSON</acronym> data
- and presents the results as a relational view, which can be accessed as a
- regular SQL table. You can use <function>JSON_TABLE</function> inside
- the <literal>FROM</literal> clause of a <literal>SELECT</literal>,
- <literal>UPDATE</literal>, or <literal>DELETE</literal> and as data source
- in a <literal>MERGE</literal> statement.
- </para>
-
- <para>
- Taking JSON data as input, <function>JSON_TABLE</function> uses a JSON path
- expression to extract a part of the provided data to use as a
- <firstterm>row pattern</firstterm> for the constructed view. Each SQL/JSON
- value given by the row pattern serves as source for a separate row in the
- constructed view.
- </para>
-
- <para>
- To split the row pattern into columns, <function>JSON_TABLE</function>
- provides the <literal>COLUMNS</literal> clause that defines the
- schema of the created view. For each column, a separate JSON path expression
- can be specified to be evaluated against the row pattern to get an SQL/JSON
- value that will become the value for the specified column in a given output
- row.
- </para>
-
- <para>
- JSON data stored at a nested level of the row pattern can be extracted using
- the <literal>NESTED PATH</literal> clause. Each
- <literal>NESTED PATH</literal> clause can be used to generate one or more
- columns using the data from a nested level of the row pattern. Those
- columns can be specified using a <literal>COLUMNS</literal> clause that
- looks similar to the top-level COLUMNS clause. Rows constructed from
- NESTED COLUMNS are called <firstterm>child rows</firstterm> and are joined
- against the row constructed from the columns specified in the parent
- <literal>COLUMNS</literal> clause to get the row in the final view. Child
- columns themselves may contain a <literal>NESTED PATH</literal>
- specification thus allowing to extract data located at arbitrary nesting
- levels. Columns produced by multiple <literal>NESTED PATH</literal>s at the
- same level are considered to be <firstterm>siblings</firstterm> of each
- other and their rows after joining with the parent row are combined using
- UNION.
- </para>
-
- <para>
- The rows produced by <function>JSON_TABLE</function> are laterally
- joined to the row that generated them, so you do not have to explicitly join
- the constructed view with the original table holding <acronym>JSON</acronym>
- data.
- </para>
-
- <para>
- The syntax is:
- </para>
-
-<synopsis>
-JSON_TABLE (
- <replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> AS <replaceable>json_path_name</replaceable> </optional> <optional> PASSING { <replaceable>value</replaceable> AS <replaceable>varname</replaceable> } <optional>, ...</optional> </optional>
- COLUMNS ( <replaceable class="parameter">json_table_column</replaceable> <optional>, ...</optional> )
- <optional> { <literal>ERROR</literal> | <literal>EMPTY</literal> } <literal>ON ERROR</literal> </optional>
-)
-
-<phrase>
-where <replaceable class="parameter">json_table_column</replaceable> is:
-</phrase>
- <replaceable>name</replaceable> FOR ORDINALITY
- | <replaceable>name</replaceable> <replaceable>type</replaceable>
- <optional> FORMAT JSON <optional>ENCODING <literal>UTF8</literal></optional></optional>
- <optional> PATH <replaceable>path_expression</replaceable> </optional>
- <optional> { WITHOUT | WITH { CONDITIONAL | <optional>UNCONDITIONAL</optional> } } <optional> ARRAY </optional> WRAPPER </optional>
- <optional> { KEEP | OMIT } QUOTES <optional> ON SCALAR STRING </optional> </optional>
- <optional> { ERROR | NULL | EMPTY { ARRAY | OBJECT } | DEFAULT <replaceable>expression</replaceable> } ON EMPTY </optional>
- <optional> { ERROR | NULL | EMPTY { ARRAY | OBJECT } | DEFAULT <replaceable>expression</replaceable> } ON ERROR </optional>
- | <replaceable>name</replaceable> <replaceable>type</replaceable> EXISTS <optional> PATH <replaceable>path_expression</replaceable> </optional>
- <optional> { ERROR | TRUE | FALSE | UNKNOWN } ON ERROR </optional>
- | NESTED <optional> PATH </optional> <replaceable>path_expression</replaceable> <optional> AS <replaceable>json_path_name</replaceable> </optional> COLUMNS ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
-</synopsis>
-
- <para>
- Each syntax element is described below in more detail.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>
- <literal><replaceable>context_item</replaceable>, <replaceable>path_expression</replaceable> <optional> <literal>AS</literal> <replaceable>json_path_name</replaceable> </optional> <optional> <literal>PASSING</literal> { <replaceable>value</replaceable> <literal>AS</literal> <replaceable>varname</replaceable> } <optional>, ...</optional></optional></literal>
- </term>
- <listitem>
- <para>
- The input data to query (<replaceable>context_item</replaceable>),
- the JSON path expression defining the query (<replaceable>path_expression</replaceable>)
- with an optional name (<replaceable>json_path_name</replaceable>), and an
- optional <literal>PASSING</literal> clause, which can provide data values
- to the <replaceable>path_expression</replaceable>. The result of the input
- data evaluation using the aforementioned elements is called the
- <firstterm>row pattern</firstterm>, which is used as the source for row
- values in the constructed view.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <literal>COLUMNS</literal> ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
- </term>
- <listitem>
-
- <para>
- The <literal>COLUMNS</literal> clause defining the schema of the
- constructed view. In this clause, you can specify each column to be
- filled with an SQL/JSON value obtained by applying a JSON path expression
- against the row pattern. <replaceable>json_table_column</replaceable> has
- the following variants:
- </para>
-
- <variablelist>
- <varlistentry>
- <term>
- <replaceable>name</replaceable> <literal>FOR ORDINALITY</literal>
- </term>
- <listitem>
- <para>
- Adds an ordinality column that provides sequential row numbering starting
- from 1. Each <literal>NESTED PATH</literal> (see below) gets its own
- counter for any nested ordinality columns.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <literal><replaceable>name</replaceable> <replaceable>type</replaceable>
- <optional><literal>FORMAT JSON</literal> <optional>ENCODING <literal>UTF8</literal></optional></optional>
- <optional> <literal>PATH</literal> <replaceable>path_expression</replaceable> </optional></literal>
- </term>
- <listitem>
- <para>
- Inserts an SQL/JSON value obtained by applying
- <replaceable>path_expression</replaceable> against the row pattern into
- the view's output row after coercing it to specified
- <replaceable>type</replaceable>.
- </para>
- <para>
- Specifying <literal>FORMAT JSON</literal> makes it explicit that you
- expect the value to be a valid <type>json</type> object. It only
- makes sense to specify <literal>FORMAT JSON</literal> if
- <replaceable>type</replaceable> is one of <type>bpchar</type>,
- <type>bytea</type>, <type>character varying</type>, <type>name</type>,
- <type>json</type>, <type>jsonb</type>, <type>text</type>, or a domain over
- these types.
- </para>
- <para>
- Optionally, you can specify <literal>WRAPPER</literal> and
- <literal>QUOTES</literal> clauses to format the output. Note that
- specifying <literal>OMIT QUOTES</literal> overrides
- <literal>FORMAT JSON</literal> if also specified, because unquoted
- literals do not constitute valid <type>json</type> values.
- </para>
- <para>
- Optionally, you can use <literal>ON EMPTY</literal> and
- <literal>ON ERROR</literal> clauses to specify whether to throw the error
- or return the specified value when the result of JSON path evaluation is
- empty and when an error occurs during JSON path evaluation or when
- coercing the SQL/JSON value to the specified type, respectively. The
- default for both is to return a <literal>NULL</literal> value.
- </para>
- <note>
- <para>
- This clause is internally turned into and has the same semantics as
- <function>JSON_VALUE</function> or <function>JSON_QUERY</function>.
- The latter if the specified type is not a scalar type or if either of
- <literal>FORMAT JSON</literal>, <literal>WRAPPER</literal>, or
- <literal>QUOTES</literal> clause is present.
- </para>
- </note>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <replaceable>name</replaceable> <replaceable>type</replaceable>
- <literal>EXISTS</literal> <optional> <literal>PATH</literal> <replaceable>path_expression</replaceable> </optional>
- </term>
- <listitem>
- <para>
- Inserts a boolean value obtained by applying
- <replaceable>path_expression</replaceable> against the row pattern
- into the view's output row after coercing it to specified
- <replaceable>type</replaceable>.
- </para>
- <para>
- The value corresponds to whether applying the <literal>PATH</literal>
- expression to the row pattern yields any values.
- </para>
- <para>
- The specified <replaceable>type</replaceable> should have a cast from the
- <type>boolean</type> type.
- </para>
- <para>
- Optionally, you can use <literal>ON ERROR</literal> to specify whether to
- throw the error or return the specified value when an error occurs during
- JSON path evaluation or when coercing SQL/JSON value to the specified
- type. The default is to return a boolean value
- <literal>FALSE</literal>.
- </para>
- <note>
- <para>
- This clause is internally turned into and has the same semantics as
- <function>JSON_EXISTS</function>.
- </para>
- </note>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <literal>NESTED <optional> PATH </optional></literal> <replaceable>path_expression</replaceable> <optional> <literal>AS</literal> <replaceable>json_path_name</replaceable> </optional>
- <literal>COLUMNS</literal> ( <replaceable>json_table_column</replaceable> <optional>, ...</optional> )
- </term>
- <listitem>
-
- <para>
- Extracts SQL/JSON values from nested levels of the row pattern,
- generates one or more columns as defined by the <literal>COLUMNS</literal>
- subclause, and inserts the extracted SQL/JSON values into those
- columns. The <replaceable>json_table_column</replaceable>
- expression in the <literal>COLUMNS</literal> subclause uses the same
- syntax as in the parent <literal>COLUMNS</literal> clause.
- </para>
-
- <para>
- The <literal>NESTED PATH</literal> syntax is recursive,
- so you can go down multiple nested levels by specifying several
- <literal>NESTED PATH</literal> subclauses within each other.
- It allows to unnest the hierarchy of JSON objects and arrays
- in a single function invocation rather than chaining several
- <function>JSON_TABLE</function> expressions in an SQL statement.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <note>
- <para>
- In each variant of <replaceable>json_table_column</replaceable> described
- above, if the <literal>PATH</literal> clause is omitted, path expression
- <literal>$.<replaceable>name</replaceable></literal> is used, where
- <replaceable>name</replaceable> is the provided column name.
- </para>
- </note>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <literal>AS</literal> <replaceable>json_path_name</replaceable>
- </term>
- <listitem>
-
- <para>
- The optional <replaceable>json_path_name</replaceable> serves as an
- identifier of the provided <replaceable>path_expression</replaceable>.
- The name must be unique and distinct from the column names.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- { <literal>ERROR</literal> | <literal>EMPTY</literal> } <literal>ON ERROR</literal>
- </term>
- <listitem>
-
- <para>
- The optional <literal>ON ERROR</literal> can be used to specify how to
- handle errors when evaluating the top-level
- <replaceable>path_expression</replaceable>. Use <literal>ERROR</literal>
- if you want the errors to be thrown and <literal>EMPTY</literal> to
- return an empty table, that is, a table containing 0 rows. Note that
- this clause does not affect the errors that occur when evaluating
- columns, for which the behavior depends on whether the
- <literal>ON ERROR</literal> clause is specified against a given column.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>Examples</para>
-
- <para>
- In the examples that follow, the following table containing JSON data
- will be used:
-
-<programlisting>
-CREATE TABLE my_films ( js jsonb );
-
-INSERT INTO my_films VALUES (
-'{ "favorites" : [
- { "kind" : "comedy", "films" : [
- { "title" : "Bananas",
- "director" : "Woody Allen"},
- { "title" : "The Dinner Game",
- "director" : "Francis Veber" } ] },
- { "kind" : "horror", "films" : [
- { "title" : "Psycho",
- "director" : "Alfred Hitchcock" } ] },
- { "kind" : "thriller", "films" : [
- { "title" : "Vertigo",
- "director" : "Alfred Hitchcock" } ] },
- { "kind" : "drama", "films" : [
- { "title" : "Yojimbo",
- "director" : "Akira Kurosawa" } ] }
- ] }');
-</programlisting>
-
- </para>
- <para>
- The following query shows how to use <function>JSON_TABLE</function> to
- turn the JSON objects in the <structname>my_films</structname> table
- to a view containing columns for the keys <literal>kind</literal>,
- <literal>title</literal>, and <literal>director</literal> contained in
- the original JSON along with an ordinality column:
-
-<programlisting>
-SELECT jt.* FROM
- my_films,
- JSON_TABLE (js, '$.favorites[*]' COLUMNS (
- id FOR ORDINALITY,
- kind text PATH '$.kind',
- title text PATH '$.films[*].title' WITH WRAPPER,
- director text PATH '$.films[*].director' WITH WRAPPER)) AS jt;
-</programlisting>
-
-<screen>
- id | kind | title | director
-----+----------+--------------------------------+----------------------------------
- 1 | comedy | ["Bananas", "The Dinner Game"] | ["Woody Allen", "Francis Veber"]
- 2 | horror | ["Psycho"] | ["Alfred Hitchcock"]
- 3 | thriller | ["Vertigo"] | ["Alfred Hitchcock"]
- 4 | drama | ["Yojimbo"] | ["Akira Kurosawa"]
-(4 rows)
-</screen>
-
- </para>
- <para>
- The following is a modified version of the above query to show the
- usage of <literal>PASSING</literal> arguments in the filter specified in
- the top-level JSON path expression and the various options for the
- individual columns:
-
-<programlisting>
-SELECT jt.* FROM
- my_films,
- JSON_TABLE (js, '$.favorites[*] ? (@.films[*].director == $filter)'
- PASSING 'Alfred Hitchcock' AS filter, 'Vertigo' AS filter2
- COLUMNS (
- id FOR ORDINALITY,
- kind text PATH '$.kind',
- title text FORMAT JSON PATH '$.films[*].title' OMIT QUOTES,
- director text PATH '$.films[*].director' KEEP QUOTES)) AS jt;
-</programlisting>
-
-<screen>
- id | kind | title | director
-----+----------+---------+--------------------
- 1 | horror | Psycho | "Alfred Hitchcock"
- 2 | thriller | Vertigo | "Alfred Hitchcock"
-(2 rows)
-</screen>
-
- </para>
- <para>
- The following is a modified version of the above query to show the usage
- of <literal>NESTED PATH</literal> for populating title and director
- columns, illustrating how they are joined to the parent columns id and
- kind:
-
-<programlisting>
-SELECT jt.* FROM
- my_films,
- JSON_TABLE ( js, '$.favorites[*] ? (@.films[*].director == $filter)'
- PASSING 'Alfred Hitchcock' AS filter
- COLUMNS (
- id FOR ORDINALITY,
- kind text PATH '$.kind',
- NESTED PATH '$.films[*]' COLUMNS (
- title text FORMAT JSON PATH '$.title' OMIT QUOTES,
- director text PATH '$.director' KEEP QUOTES))) AS jt;
-</programlisting>
-
-<screen>
- id | kind | title | director
-----+----------+---------+--------------------
- 1 | horror | Psycho | "Alfred Hitchcock"
- 2 | thriller | Vertigo | "Alfred Hitchcock"
-(2 rows)
-</screen>
-
- </para>
-
- <para>
- The following is the same query but without the filter in the root
- path:
-
-<programlisting>
-SELECT jt.* FROM
- my_films,
- JSON_TABLE ( js, '$.favorites[*]'
- COLUMNS (
- id FOR ORDINALITY,
- kind text PATH '$.kind',
- NESTED PATH '$.films[*]' COLUMNS (
- title text FORMAT JSON PATH '$.title' OMIT QUOTES,
- director text PATH '$.director' KEEP QUOTES))) AS jt;
-</programlisting>
-
-<screen>
- id | kind | title | director
-----+----------+-----------------+--------------------
- 1 | comedy | Bananas | "Woody Allen"
- 1 | comedy | The Dinner Game | "Francis Veber"
- 2 | horror | Psycho | "Alfred Hitchcock"
- 3 | thriller | Vertigo | "Alfred Hitchcock"
- 4 | drama | Yojimbo | "Akira Kurosawa"
-(5 rows)
-</screen>
-
- </para>
-
- <para>
- The following shows another query using a different <type>JSON</type>
- object as input. It shows the UNION "sibling join" between
- <literal>NESTED</literal> paths <literal>$.movies[*]</literal> and
- <literal>$.books[*]</literal> and also the usage of
- <literal>FOR ORDINALITY</literal> column at <literal>NESTED</literal>
- levels (columns <literal>movie_id</literal>, <literal>book_id</literal>,
- and <literal>author_id</literal>):
-
-<programlisting>
-SELECT * FROM JSON_TABLE (
-'{"favorites":
- {"movies":
- [{"name": "One", "director": "John Doe"},
- {"name": "Two", "director": "Don Joe"}],
- "books":
- [{"name": "Mystery", "authors": [{"name": "Brown Dan"}]},
- {"name": "Wonder", "authors": [{"name": "Jun Murakami"}, {"name":"Craig Doe"}]}]
-}}'::json, '$.favorites[*]'
-COLUMNS (
- user_id FOR ORDINALITY,
- NESTED '$.movies[*]'
- COLUMNS (
- movie_id FOR ORDINALITY,
- mname text PATH '$.name',
- director text),
- NESTED '$.books[*]'
- COLUMNS (
- book_id FOR ORDINALITY,
- bname text PATH '$.name',
- NESTED '$.authors[*]'
- COLUMNS (
- author_id FOR ORDINALITY,
- author_name text PATH '$.name'))));
-</programlisting>
-
-<screen>
- user_id | movie_id | mname | director | book_id | bname | author_id | author_name
----------+----------+-------+----------+---------+---------+-----------+--------------
- 1 | 1 | One | John Doe | | | |
- 1 | 2 | Two | Don Joe | | | |
- 1 | | | | 1 | Mystery | 1 | Brown Dan
- 1 | | | | 2 | Wonder | 1 | Jun Murakami
- 1 | | | | 2 | Wonder | 2 | Craig Doe
-(5 rows)
-</screen>
-
- </para>
- </sect2>
- </sect1>
+&func-json;
<sect1 id="functions-sequence">
<title>Sequence Manipulation Functions</title>
--
2.34.1
v1-0007-split-sect1-functions-admin-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0007-split-sect1-functions-admin-from-func.sgml.patchDownload
From a11221ca95bbd765d6842c7cd132ed860f858c1c Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 15:19:09 +0800
Subject: [PATCH v1 7/7] split sect1: "functions-admin" from func.sgml
"functions-admin" lives in a new file: doc/src/sgml/func-admin.sgml,
it will hold doc/src/sgml/html/functions-admin.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-admin.sgml | 2686 +++++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 2688 +---------------------------------
3 files changed, 2688 insertions(+), 2687 deletions(-)
create mode 100644 doc/src/sgml/func-admin.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 4e80d2b4..741c8b82 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -24,6 +24,7 @@
<!ENTITY func-json SYSTEM "func-json.sgml">
<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-admin.sgml b/doc/src/sgml/func-admin.sgml
new file mode 100644
index 00000000..79f0e59d
--- /dev/null
+++ b/doc/src/sgml/func-admin.sgml
@@ -0,0 +1,2686 @@
+ <sect1 id="functions-admin">
+ <title>System Administration Functions</title>
+
+ <para>
+ The functions described in this section are used to control and
+ monitor a <productname>PostgreSQL</productname> installation.
+ </para>
+
+ <sect2 id="functions-admin-set">
+ <title>Configuration Settings Functions</title>
+
+ <indexterm>
+ <primary>SET</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>SHOW</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>configuration</primary>
+ <secondary sortas="server">of the server</secondary>
+ <tertiary>functions</tertiary>
+ </indexterm>
+
+ <para>
+ <xref linkend="functions-admin-set-table"/> shows the functions
+ available to query and alter run-time configuration parameters.
+ </para>
+
+ <table id="functions-admin-set-table">
+ <title>Configuration Settings Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_setting</primary>
+ </indexterm>
+ <function>current_setting</function> ( <parameter>setting_name</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the current value of the
+ setting <parameter>setting_name</parameter>. If there is no such
+ setting, <function>current_setting</function> throws an error
+ unless <parameter>missing_ok</parameter> is supplied and
+ is <literal>true</literal> (in which case NULL is returned).
+ This function corresponds to
+ the <acronym>SQL</acronym> command <xref linkend="sql-show"/>.
+ </para>
+ <para>
+ <literal>current_setting('datestyle')</literal>
+ <returnvalue>ISO, MDY</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>set_config</primary>
+ </indexterm>
+ <function>set_config</function> (
+ <parameter>setting_name</parameter> <type>text</type>,
+ <parameter>new_value</parameter> <type>text</type>,
+ <parameter>is_local</parameter> <type>boolean</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Sets the parameter <parameter>setting_name</parameter>
+ to <parameter>new_value</parameter>, and returns that value.
+ If <parameter>is_local</parameter> is <literal>true</literal>, the new
+ value will only apply during the current transaction. If you want the
+ new value to apply for the rest of the current session,
+ use <literal>false</literal> instead. This function corresponds to
+ the SQL command <xref linkend="sql-set"/>.
+ </para>
+ <para>
+ <literal>set_config('log_statement_stats', 'off', false)</literal>
+ <returnvalue>off</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-admin-signal">
+ <title>Server Signaling Functions</title>
+
+ <indexterm>
+ <primary>signal</primary>
+ <secondary sortas="backend">backend processes</secondary>
+ </indexterm>
+
+ <para>
+ The functions shown in <xref
+ linkend="functions-admin-signal-table"/> send control signals to
+ other server processes. Use of these functions is restricted to
+ superusers by default but access may be granted to others using
+ <command>GRANT</command>, with noted exceptions.
+ </para>
+
+ <para>
+ Each of these functions returns <literal>true</literal> if
+ the signal was successfully sent and <literal>false</literal>
+ if sending the signal failed.
+ </para>
+
+ <table id="functions-admin-signal-table">
+ <title>Server Signaling Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_cancel_backend</primary>
+ </indexterm>
+ <function>pg_cancel_backend</function> ( <parameter>pid</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Cancels the current query of the session whose backend process has the
+ specified process ID. This is also allowed if the
+ calling role is a member of the role whose backend is being canceled or
+ the calling role has privileges of <literal>pg_signal_backend</literal>,
+ however only superusers can cancel superuser backends.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_log_backend_memory_contexts</primary>
+ </indexterm>
+ <function>pg_log_backend_memory_contexts</function> ( <parameter>pid</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Requests to log the memory contexts of the backend with the
+ specified process ID. This function can send the request to
+ backends and auxiliary processes except logger. These memory contexts
+ will be logged at
+ <literal>LOG</literal> message level. They will appear in
+ the server log based on the log configuration set
+ (see <xref linkend="runtime-config-logging"/> for more information),
+ but will not be sent to the client regardless of
+ <xref linkend="guc-client-min-messages"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_reload_conf</primary>
+ </indexterm>
+ <function>pg_reload_conf</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Causes all processes of the <productname>PostgreSQL</productname>
+ server to reload their configuration files. (This is initiated by
+ sending a <systemitem>SIGHUP</systemitem> signal to the postmaster
+ process, which in turn sends <systemitem>SIGHUP</systemitem> to each
+ of its children.) You can use the
+ <link linkend="view-pg-file-settings"><structname>pg_file_settings</structname></link>,
+ <link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link> and
+ <link linkend="view-pg-ident-file-mappings"><structname>pg_ident_file_mappings</structname></link> views
+ to check the configuration files for possible errors, before reloading.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_rotate_logfile</primary>
+ </indexterm>
+ <function>pg_rotate_logfile</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Signals the log-file manager to switch to a new output file
+ immediately. This works only when the built-in log collector is
+ running, since otherwise there is no log-file manager subprocess.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_terminate_backend</primary>
+ </indexterm>
+ <function>pg_terminate_backend</function> ( <parameter>pid</parameter> <type>integer</type>, <parameter>timeout</parameter> <type>bigint</type> <literal>DEFAULT</literal> <literal>0</literal> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Terminates the session whose backend process has the
+ specified process ID. This is also allowed if the calling role
+ is a member of the role whose backend is being terminated or the
+ calling role has privileges of <literal>pg_signal_backend</literal>,
+ however only superusers can terminate superuser backends.
+ </para>
+ <para>
+ If <parameter>timeout</parameter> is not specified or zero, this
+ function returns <literal>true</literal> whether the process actually
+ terminates or not, indicating only that the sending of the signal was
+ successful. If the <parameter>timeout</parameter> is specified (in
+ milliseconds) and greater than zero, the function waits until the
+ process is actually terminated or until the given time has passed. If
+ the process is terminated, the function
+ returns <literal>true</literal>. On timeout, a warning is emitted and
+ <literal>false</literal> is returned.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <function>pg_cancel_backend</function> and <function>pg_terminate_backend</function>
+ send signals (<systemitem>SIGINT</systemitem> or <systemitem>SIGTERM</systemitem>
+ respectively) to backend processes identified by process ID.
+ The process ID of an active backend can be found from
+ the <structfield>pid</structfield> column of the
+ <structname>pg_stat_activity</structname> view, or by listing the
+ <command>postgres</command> processes on the server (using
+ <application>ps</application> on Unix or the <application>Task
+ Manager</application> on <productname>Windows</productname>).
+ The role of an active backend can be found from the
+ <structfield>usename</structfield> column of the
+ <structname>pg_stat_activity</structname> view.
+ </para>
+
+ <para>
+ <function>pg_log_backend_memory_contexts</function> can be used
+ to log the memory contexts of a backend process. For example:
+<programlisting>
+postgres=# SELECT pg_log_backend_memory_contexts(pg_backend_pid());
+ pg_log_backend_memory_contexts
+--------------------------------
+ t
+(1 row)
+</programlisting>
+One message for each memory context will be logged. For example:
+<screen>
+LOG: logging memory contexts of PID 10377
+STATEMENT: SELECT pg_log_backend_memory_contexts(pg_backend_pid());
+LOG: level: 0; TopMemoryContext: 80800 total in 6 blocks; 14432 free (5 chunks); 66368 used
+LOG: level: 1; pgstat TabStatusArray lookup hash table: 8192 total in 1 blocks; 1408 free (0 chunks); 6784 used
+LOG: level: 1; TopTransactionContext: 8192 total in 1 blocks; 7720 free (1 chunks); 472 used
+LOG: level: 1; RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used
+LOG: level: 1; MessageContext: 16384 total in 2 blocks; 5152 free (0 chunks); 11232 used
+LOG: level: 1; Operator class cache: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used
+LOG: level: 1; smgr relation table: 16384 total in 2 blocks; 4544 free (3 chunks); 11840 used
+LOG: level: 1; TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used
+...
+LOG: level: 1; ErrorContext: 8192 total in 1 blocks; 7928 free (3 chunks); 264 used
+LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 used
+</screen>
+ If there are more than 100 child contexts under the same parent, the first
+ 100 child contexts are logged, along with a summary of the remaining contexts.
+ Note that frequent calls to this function could incur significant overhead,
+ because it may generate a large number of log messages.
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-admin-backup">
+ <title>Backup Control Functions</title>
+
+ <indexterm>
+ <primary>backup</primary>
+ </indexterm>
+
+ <para>
+ The functions shown in <xref
+ linkend="functions-admin-backup-table"/> assist in making on-line backups.
+ These functions cannot be executed during recovery (except
+ <function>pg_backup_start</function>,
+ <function>pg_backup_stop</function>,
+ and <function>pg_wal_lsn_diff</function>).
+ </para>
+
+ <para>
+ For details about proper usage of these functions, see
+ <xref linkend="continuous-archiving"/>.
+ </para>
+
+ <table id="functions-admin-backup-table">
+ <title>Backup Control Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_create_restore_point</primary>
+ </indexterm>
+ <function>pg_create_restore_point</function> ( <parameter>name</parameter> <type>text</type> )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Creates a named marker record in the write-ahead log that can later be
+ used as a recovery target, and returns the corresponding write-ahead
+ log location. The given name can then be used with
+ <xref linkend="guc-recovery-target-name"/> to specify the point up to
+ which recovery will proceed. Avoid creating multiple restore points
+ with the same name, since recovery will stop at the first one whose
+ name matches the recovery target.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_wal_flush_lsn</primary>
+ </indexterm>
+ <function>pg_current_wal_flush_lsn</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the current write-ahead log flush location (see notes below).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_wal_insert_lsn</primary>
+ </indexterm>
+ <function>pg_current_wal_insert_lsn</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the current write-ahead log insert location (see notes below).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_current_wal_lsn</primary>
+ </indexterm>
+ <function>pg_current_wal_lsn</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the current write-ahead log write location (see notes below).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_backup_start</primary>
+ </indexterm>
+ <function>pg_backup_start</function> (
+ <parameter>label</parameter> <type>text</type>
+ <optional>, <parameter>fast</parameter> <type>boolean</type>
+ </optional> )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Prepares the server to begin an on-line backup. The only required
+ parameter is an arbitrary user-defined label for the backup.
+ (Typically this would be the name under which the backup dump file
+ will be stored.)
+ If the optional second parameter is given as <literal>true</literal>,
+ it specifies executing <function>pg_backup_start</function> as quickly
+ as possible. This forces an immediate checkpoint which will cause a
+ spike in I/O operations, slowing any concurrently executing queries.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_backup_stop</primary>
+ </indexterm>
+ <function>pg_backup_stop</function> (
+ <optional><parameter>wait_for_archive</parameter> <type>boolean</type>
+ </optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>lsn</parameter> <type>pg_lsn</type>,
+ <parameter>labelfile</parameter> <type>text</type>,
+ <parameter>spcmapfile</parameter> <type>text</type> )
+ </para>
+ <para>
+ Finishes performing an on-line backup. The desired contents of the
+ backup label file and the tablespace map file are returned as part of
+ the result of the function and must be written to files in the
+ backup area. These files must not be written to the live data directory
+ (doing so will cause PostgreSQL to fail to restart in the event of a
+ crash).
+ </para>
+ <para>
+ There is an optional parameter of type <type>boolean</type>.
+ If false, the function will return immediately after the backup is
+ completed, without waiting for WAL to be archived. This behavior is
+ only useful with backup software that independently monitors WAL
+ archiving. Otherwise, WAL required to make the backup consistent might
+ be missing and make the backup useless. By default or when this
+ parameter is true, <function>pg_backup_stop</function> will wait for
+ WAL to be archived when archiving is enabled. (On a standby, this
+ means that it will wait only when <varname>archive_mode</varname> =
+ <literal>always</literal>. If write activity on the primary is low,
+ it may be useful to run <function>pg_switch_wal</function> on the
+ primary in order to trigger an immediate segment switch.)
+ </para>
+ <para>
+ When executed on a primary, this function also creates a backup
+ history file in the write-ahead log archive area. The history file
+ includes the label given to <function>pg_backup_start</function>, the
+ starting and ending write-ahead log locations for the backup, and the
+ starting and ending times of the backup. After recording the ending
+ location, the current write-ahead log insertion point is automatically
+ advanced to the next write-ahead log file, so that the ending
+ write-ahead log file can be archived immediately to complete the
+ backup.
+ </para>
+ <para>
+ The result of the function is a single record.
+ The <parameter>lsn</parameter> column holds the backup's ending
+ write-ahead log location (which again can be ignored). The second
+ column returns the contents of the backup label file, and the third
+ column returns the contents of the tablespace map file. These must be
+ stored as part of the backup and are required as part of the restore
+ process.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_switch_wal</primary>
+ </indexterm>
+ <function>pg_switch_wal</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Forces the server to switch to a new write-ahead log file, which
+ allows the current file to be archived (assuming you are using
+ continuous archiving). The result is the ending write-ahead log
+ location plus 1 within the just-completed write-ahead log file. If
+ there has been no write-ahead log activity since the last write-ahead
+ log switch, <function>pg_switch_wal</function> does nothing and
+ returns the start location of the write-ahead log file currently in
+ use.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_walfile_name</primary>
+ </indexterm>
+ <function>pg_walfile_name</function> ( <parameter>lsn</parameter> <type>pg_lsn</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts a write-ahead log location to the name of the WAL file
+ holding that location.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_walfile_name_offset</primary>
+ </indexterm>
+ <function>pg_walfile_name_offset</function> ( <parameter>lsn</parameter> <type>pg_lsn</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>file_name</parameter> <type>text</type>,
+ <parameter>file_offset</parameter> <type>integer</type> )
+ </para>
+ <para>
+ Converts a write-ahead log location to a WAL file name and byte offset
+ within that file.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_split_walfile_name</primary>
+ </indexterm>
+ <function>pg_split_walfile_name</function> ( <parameter>file_name</parameter> <type>text</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>segment_number</parameter> <type>numeric</type>,
+ <parameter>timeline_id</parameter> <type>bigint</type> )
+ </para>
+ <para>
+ Extracts the sequence number and timeline ID from a WAL file
+ name.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_wal_lsn_diff</primary>
+ </indexterm>
+ <function>pg_wal_lsn_diff</function> ( <parameter>lsn1</parameter> <type>pg_lsn</type>, <parameter>lsn2</parameter> <type>pg_lsn</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para>
+ Calculates the difference in bytes (<parameter>lsn1</parameter> - <parameter>lsn2</parameter>) between two write-ahead log
+ locations. This can be used
+ with <structname>pg_stat_replication</structname> or some of the
+ functions shown in <xref linkend="functions-admin-backup-table"/> to
+ get the replication lag.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <function>pg_current_wal_lsn</function> displays the current write-ahead
+ log write location in the same format used by the above functions.
+ Similarly, <function>pg_current_wal_insert_lsn</function> displays the
+ current write-ahead log insertion location
+ and <function>pg_current_wal_flush_lsn</function> displays the current
+ write-ahead log flush location. The insertion location is
+ the <quote>logical</quote> end of the write-ahead log at any instant,
+ while the write location is the end of what has actually been written out
+ from the server's internal buffers, and the flush location is the last
+ location known to be written to durable storage. The write location is the
+ end of what can be examined from outside the server, and is usually what
+ you want if you are interested in archiving partially-complete write-ahead
+ log files. The insertion and flush locations are made available primarily
+ for server debugging purposes. These are all read-only operations and do
+ not require superuser permissions.
+ </para>
+
+ <para>
+ You can use <function>pg_walfile_name_offset</function> to extract the
+ corresponding write-ahead log file name and byte offset from
+ a <type>pg_lsn</type> value. For example:
+<programlisting>
+postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
+ file_name | file_offset
+--------------------------+-------------
+ 00000001000000000000000D | 4039624
+(1 row)
+</programlisting>
+ Similarly, <function>pg_walfile_name</function> extracts just the write-ahead log file name.
+ </para>
+
+ <para>
+ <function>pg_split_walfile_name</function> is useful to compute a
+ <acronym>LSN</acronym> from a file offset and WAL file name, for example:
+<programlisting>
+postgres=# \set file_name '000000010000000100C000AB'
+postgres=# \set offset 256
+postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset AS lsn
+ FROM pg_split_walfile_name(:'file_name') pd,
+ pg_show_all_settings() ps
+ WHERE ps.name = 'wal_segment_size';
+ lsn
+---------------
+ C001/AB000100
+(1 row)
+</programlisting>
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-recovery-control">
+ <title>Recovery Control Functions</title>
+
+ <para>
+ The functions shown in <xref
+ linkend="functions-recovery-info-table"/> provide information
+ about the current status of a standby server.
+ These functions may be executed both during recovery and in normal running.
+ </para>
+
+ <table id="functions-recovery-info-table">
+ <title>Recovery Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_is_in_recovery</primary>
+ </indexterm>
+ <function>pg_is_in_recovery</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if recovery is still in progress.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_last_wal_receive_lsn</primary>
+ </indexterm>
+ <function>pg_last_wal_receive_lsn</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the last write-ahead log location that has been received and
+ synced to disk by streaming replication. While streaming replication
+ is in progress this will increase monotonically. If recovery has
+ completed then this will remain static at the location of the last WAL
+ record received and synced to disk during recovery. If streaming
+ replication is disabled, or if it has not yet started, the function
+ returns <literal>NULL</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_last_wal_replay_lsn</primary>
+ </indexterm>
+ <function>pg_last_wal_replay_lsn</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the last write-ahead log location that has been replayed
+ during recovery. If recovery is still in progress this will increase
+ monotonically. If recovery has completed then this will remain
+ static at the location of the last WAL record applied during recovery.
+ When the server has been started normally without recovery, the
+ function returns <literal>NULL</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_last_xact_replay_timestamp</primary>
+ </indexterm>
+ <function>pg_last_xact_replay_timestamp</function> ()
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Returns the time stamp of the last transaction replayed during
+ recovery. This is the time at which the commit or abort WAL record
+ for that transaction was generated on the primary. If no transactions
+ have been replayed during recovery, the function
+ returns <literal>NULL</literal>. Otherwise, if recovery is still in
+ progress this will increase monotonically. If recovery has completed
+ then this will remain static at the time of the last transaction
+ applied during recovery. When the server has been started normally
+ without recovery, the function returns <literal>NULL</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_wal_resource_managers</primary>
+ </indexterm>
+ <function>pg_get_wal_resource_managers</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>rm_id</parameter> <type>integer</type>,
+ <parameter>rm_name</parameter> <type>text</type>,
+ <parameter>rm_builtin</parameter> <type>boolean</type> )
+ </para>
+ <para>
+ Returns the currently-loaded WAL resource managers in the system. The
+ column <parameter>rm_builtin</parameter> indicates whether it's a
+ built-in resource manager, or a custom resource manager loaded by an
+ extension.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The functions shown in <xref
+ linkend="functions-recovery-control-table"/> control the progress of recovery.
+ These functions may be executed only during recovery.
+ </para>
+
+ <table id="functions-recovery-control-table">
+ <title>Recovery Control Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_is_wal_replay_paused</primary>
+ </indexterm>
+ <function>pg_is_wal_replay_paused</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if recovery pause is requested.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_get_wal_replay_pause_state</primary>
+ </indexterm>
+ <function>pg_get_wal_replay_pause_state</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns recovery pause state. The return values are <literal>
+ not paused</literal> if pause is not requested, <literal>
+ pause requested</literal> if pause is requested but recovery is
+ not yet paused, and <literal>paused</literal> if the recovery is
+ actually paused.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_promote</primary>
+ </indexterm>
+ <function>pg_promote</function> ( <parameter>wait</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal>, <parameter>wait_seconds</parameter> <type>integer</type> <literal>DEFAULT</literal> <literal>60</literal> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Promotes a standby server to primary status.
+ With <parameter>wait</parameter> set to <literal>true</literal> (the
+ default), the function waits until promotion is completed
+ or <parameter>wait_seconds</parameter> seconds have passed, and
+ returns <literal>true</literal> if promotion is successful
+ and <literal>false</literal> otherwise.
+ If <parameter>wait</parameter> is set to <literal>false</literal>, the
+ function returns <literal>true</literal> immediately after sending a
+ <literal>SIGUSR1</literal> signal to the postmaster to trigger
+ promotion.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_wal_replay_pause</primary>
+ </indexterm>
+ <function>pg_wal_replay_pause</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Request to pause recovery. A request doesn't mean that recovery stops
+ right away. If you want a guarantee that recovery is actually paused,
+ you need to check for the recovery pause state returned by
+ <function>pg_get_wal_replay_pause_state()</function>. Note that
+ <function>pg_is_wal_replay_paused()</function> returns whether a request
+ is made. While recovery is paused, no further database changes are applied.
+ If hot standby is active, all new queries will see the same consistent
+ snapshot of the database, and no further query conflicts will be generated
+ until recovery is resumed.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_wal_replay_resume</primary>
+ </indexterm>
+ <function>pg_wal_replay_resume</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Restarts recovery if it was paused.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <function>pg_wal_replay_pause</function> and
+ <function>pg_wal_replay_resume</function> cannot be executed while
+ a promotion is ongoing. If a promotion is triggered while recovery
+ is paused, the paused state ends and promotion continues.
+ </para>
+
+ <para>
+ If streaming replication is disabled, the paused state may continue
+ indefinitely without a problem. If streaming replication is in
+ progress then WAL records will continue to be received, which will
+ eventually fill available disk space, depending upon the duration of
+ the pause, the rate of WAL generation and available disk space.
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-snapshot-synchronization">
+ <title>Snapshot Synchronization Functions</title>
+
+ <para>
+ <productname>PostgreSQL</productname> allows database sessions to synchronize their
+ snapshots. A <firstterm>snapshot</firstterm> determines which data is visible to the
+ transaction that is using the snapshot. Synchronized snapshots are
+ necessary when two or more sessions need to see identical content in the
+ database. If two sessions just start their transactions independently,
+ there is always a possibility that some third transaction commits
+ between the executions of the two <command>START TRANSACTION</command> commands,
+ so that one session sees the effects of that transaction and the other
+ does not.
+ </para>
+
+ <para>
+ To solve this problem, <productname>PostgreSQL</productname> allows a transaction to
+ <firstterm>export</firstterm> the snapshot it is using. As long as the exporting
+ transaction remains open, other transactions can <firstterm>import</firstterm> its
+ snapshot, and thereby be guaranteed that they see exactly the same view
+ of the database that the first transaction sees. But note that any
+ database changes made by any one of these transactions remain invisible
+ to the other transactions, as is usual for changes made by uncommitted
+ transactions. So the transactions are synchronized with respect to
+ pre-existing data, but act normally for changes they make themselves.
+ </para>
+
+ <para>
+ Snapshots are exported with the <function>pg_export_snapshot</function> function,
+ shown in <xref linkend="functions-snapshot-synchronization-table"/>, and
+ imported with the <xref linkend="sql-set-transaction"/> command.
+ </para>
+
+ <table id="functions-snapshot-synchronization-table">
+ <title>Snapshot Synchronization Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_export_snapshot</primary>
+ </indexterm>
+ <function>pg_export_snapshot</function> ()
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Saves the transaction's current snapshot and returns
+ a <type>text</type> string identifying the snapshot. This string must
+ be passed (outside the database) to clients that want to import the
+ snapshot. The snapshot is available for import only until the end of
+ the transaction that exported it.
+ </para>
+ <para>
+ A transaction can export more than one snapshot, if needed. Note that
+ doing so is only useful in <literal>READ COMMITTED</literal>
+ transactions, since in <literal>REPEATABLE READ</literal> and higher
+ isolation levels, transactions use the same snapshot throughout their
+ lifetime. Once a transaction has exported any snapshots, it cannot be
+ prepared with <xref linkend="sql-prepare-transaction"/>.
+ </para></entry>
+ </row>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_log_standby_snapshot</primary>
+ </indexterm>
+ <function>pg_log_standby_snapshot</function> ()
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Take a snapshot of running transactions and write it to WAL, without
+ having to wait for bgwriter or checkpointer to log one. This is useful
+ for logical decoding on standby, as logical slot creation has to wait
+ until such a record is replayed on the standby.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-replication">
+ <title>Replication Management Functions</title>
+
+ <para>
+ The functions shown
+ in <xref linkend="functions-replication-table"/> are for
+ controlling and interacting with replication features.
+ See <xref linkend="streaming-replication"/>,
+ <xref linkend="streaming-replication-slots"/>, and
+ <xref linkend="replication-origins"/>
+ for information about the underlying features.
+ Use of functions for replication origin is only allowed to the
+ superuser by default, but may be allowed to other users by using the
+ <literal>GRANT</literal> command.
+ Use of functions for replication slots is restricted to superusers
+ and users having <literal>REPLICATION</literal> privilege.
+ </para>
+
+ <para>
+ Many of these functions have equivalent commands in the replication
+ protocol; see <xref linkend="protocol-replication"/>.
+ </para>
+
+ <para>
+ The functions described in
+ <xref linkend="functions-admin-backup"/>,
+ <xref linkend="functions-recovery-control"/>, and
+ <xref linkend="functions-snapshot-synchronization"/>
+ are also relevant for replication.
+ </para>
+
+ <table id="functions-replication-table">
+ <title>Replication Management Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_create_physical_replication_slot</primary>
+ </indexterm>
+ <function>pg_create_physical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> <optional>, <parameter>immediately_reserve</parameter> <type>boolean</type>, <parameter>temporary</parameter> <type>boolean</type> </optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>slot_name</parameter> <type>name</type>,
+ <parameter>lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Creates a new physical replication slot named
+ <parameter>slot_name</parameter>. The optional second parameter,
+ when <literal>true</literal>, specifies that the <acronym>LSN</acronym> for this
+ replication slot be reserved immediately; otherwise
+ the <acronym>LSN</acronym> is reserved on first connection from a streaming
+ replication client. Streaming changes from a physical slot is only
+ possible with the streaming-replication protocol —
+ see <xref linkend="protocol-replication"/>. The optional third
+ parameter, <parameter>temporary</parameter>, when set to true, specifies that
+ the slot should not be permanently stored to disk and is only meant
+ for use by the current session. Temporary slots are also
+ released upon any error. This function corresponds
+ to the replication protocol command <literal>CREATE_REPLICATION_SLOT
+ ... PHYSICAL</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_drop_replication_slot</primary>
+ </indexterm>
+ <function>pg_drop_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Drops the physical or logical replication slot
+ named <parameter>slot_name</parameter>. Same as replication protocol
+ command <literal>DROP_REPLICATION_SLOT</literal>. For logical slots, this must
+ be called while connected to the same database the slot was created on.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-create-logical-replication-slot" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_create_logical_replication_slot</primary>
+ </indexterm>
+ <function>pg_create_logical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type>, <parameter>twophase</parameter> <type>boolean</type>, <parameter>failover</parameter> <type>boolean</type> </optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>slot_name</parameter> <type>name</type>,
+ <parameter>lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Creates a new logical (decoding) replication slot named
+ <parameter>slot_name</parameter> using the output plugin
+ <parameter>plugin</parameter>. The optional third
+ parameter, <parameter>temporary</parameter>, when set to true, specifies that
+ the slot should not be permanently stored to disk and is only meant
+ for use by the current session. Temporary slots are also
+ released upon any error. The optional fourth parameter,
+ <parameter>twophase</parameter>, when set to true, specifies
+ that the decoding of prepared transactions is enabled for this
+ slot. The optional fifth parameter,
+ <parameter>failover</parameter>, when set to true,
+ specifies that this slot is enabled to be synced to the
+ standbys so that logical replication can be resumed after
+ failover. A call to this function has the same effect as
+ the replication protocol command
+ <literal>CREATE_REPLICATION_SLOT ... LOGICAL</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_copy_physical_replication_slot</primary>
+ </indexterm>
+ <function>pg_copy_physical_replication_slot</function> ( <parameter>src_slot_name</parameter> <type>name</type>, <parameter>dst_slot_name</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type> </optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>slot_name</parameter> <type>name</type>,
+ <parameter>lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Copies an existing physical replication slot named <parameter>src_slot_name</parameter>
+ to a physical replication slot named <parameter>dst_slot_name</parameter>.
+ The copied physical slot starts to reserve WAL from the same <acronym>LSN</acronym> as the
+ source slot.
+ <parameter>temporary</parameter> is optional. If <parameter>temporary</parameter>
+ is omitted, the same value as the source slot is used.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_copy_logical_replication_slot</primary>
+ </indexterm>
+ <function>pg_copy_logical_replication_slot</function> ( <parameter>src_slot_name</parameter> <type>name</type>, <parameter>dst_slot_name</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type> <optional>, <parameter>plugin</parameter> <type>name</type> </optional></optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>slot_name</parameter> <type>name</type>,
+ <parameter>lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Copies an existing logical replication slot
+ named <parameter>src_slot_name</parameter> to a logical replication
+ slot named <parameter>dst_slot_name</parameter>, optionally changing
+ the output plugin and persistence. The copied logical slot starts
+ from the same <acronym>LSN</acronym> as the source logical slot. Both
+ <parameter>temporary</parameter> and <parameter>plugin</parameter> are
+ optional; if they are omitted, the values of the source slot are used.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-logical-slot-get-changes" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_logical_slot_get_changes</primary>
+ </indexterm>
+ <function>pg_logical_slot_get_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>lsn</parameter> <type>pg_lsn</type>,
+ <parameter>xid</parameter> <type>xid</type>,
+ <parameter>data</parameter> <type>text</type> )
+ </para>
+ <para>
+ Returns changes in the slot <parameter>slot_name</parameter>, starting
+ from the point from which changes have been consumed last. If
+ <parameter>upto_lsn</parameter>
+ and <parameter>upto_nchanges</parameter> are NULL,
+ logical decoding will continue until end of WAL. If
+ <parameter>upto_lsn</parameter> is non-NULL, decoding will include only
+ those transactions which commit prior to the specified LSN. If
+ <parameter>upto_nchanges</parameter> is non-NULL, decoding will
+ stop when the number of rows produced by decoding exceeds
+ the specified value. Note, however, that the actual number of
+ rows returned may be larger, since this limit is only checked after
+ adding the rows produced when decoding each new transaction commit.
+ If the specified slot is a logical failover slot then the function will
+ not return until all physical slots specified in
+ <link linkend="guc-standby-slot-names"><varname>standby_slot_names</varname></link>
+ have confirmed WAL receipt.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-logical-slot-peek-changes" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_logical_slot_peek_changes</primary>
+ </indexterm>
+ <function>pg_logical_slot_peek_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>lsn</parameter> <type>pg_lsn</type>,
+ <parameter>xid</parameter> <type>xid</type>,
+ <parameter>data</parameter> <type>text</type> )
+ </para>
+ <para>
+ Behaves just like
+ the <function>pg_logical_slot_get_changes()</function> function,
+ except that changes are not consumed; that is, they will be returned
+ again on future calls.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_logical_slot_get_binary_changes</primary>
+ </indexterm>
+ <function>pg_logical_slot_get_binary_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>lsn</parameter> <type>pg_lsn</type>,
+ <parameter>xid</parameter> <type>xid</type>,
+ <parameter>data</parameter> <type>bytea</type> )
+ </para>
+ <para>
+ Behaves just like
+ the <function>pg_logical_slot_get_changes()</function> function,
+ except that changes are returned as <type>bytea</type>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_logical_slot_peek_binary_changes</primary>
+ </indexterm>
+ <function>pg_logical_slot_peek_binary_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>lsn</parameter> <type>pg_lsn</type>,
+ <parameter>xid</parameter> <type>xid</type>,
+ <parameter>data</parameter> <type>bytea</type> )
+ </para>
+ <para>
+ Behaves just like
+ the <function>pg_logical_slot_peek_changes()</function> function,
+ except that changes are returned as <type>bytea</type>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-slot-advance" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_slot_advance</primary>
+ </indexterm>
+ <function>pg_replication_slot_advance</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>slot_name</parameter> <type>name</type>,
+ <parameter>end_lsn</parameter> <type>pg_lsn</type> )
+ </para>
+ <para>
+ Advances the current confirmed position of a replication slot named
+ <parameter>slot_name</parameter>. The slot will not be moved backwards,
+ and it will not be moved beyond the current insert location. Returns
+ the name of the slot and the actual position that it was advanced to.
+ The updated slot position information is written out at the next
+ checkpoint if any advancing is done. So in the event of a crash, the
+ slot may return to an earlier position. If the specified slot is a
+ logical failover slot then the function will not return until all
+ physical slots specified in
+ <link linkend="guc-standby-slot-names"><varname>standby_slot_names</varname></link>
+ have confirmed WAL receipt.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-create" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_create</primary>
+ </indexterm>
+ <function>pg_replication_origin_create</function> ( <parameter>node_name</parameter> <type>text</type> )
+ <returnvalue>oid</returnvalue>
+ </para>
+ <para>
+ Creates a replication origin with the given external
+ name, and returns the internal ID assigned to it.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-drop" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_drop</primary>
+ </indexterm>
+ <function>pg_replication_origin_drop</function> ( <parameter>node_name</parameter> <type>text</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Deletes a previously-created replication origin, including any
+ associated replay progress.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_oid</primary>
+ </indexterm>
+ <function>pg_replication_origin_oid</function> ( <parameter>node_name</parameter> <type>text</type> )
+ <returnvalue>oid</returnvalue>
+ </para>
+ <para>
+ Looks up a replication origin by name and returns the internal ID. If
+ no such replication origin is found, <literal>NULL</literal> is
+ returned.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-session-setup" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_session_setup</primary>
+ </indexterm>
+ <function>pg_replication_origin_session_setup</function> ( <parameter>node_name</parameter> <type>text</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Marks the current session as replaying from the given
+ origin, allowing replay progress to be tracked.
+ Can only be used if no origin is currently selected.
+ Use <function>pg_replication_origin_session_reset</function> to undo.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_session_reset</primary>
+ </indexterm>
+ <function>pg_replication_origin_session_reset</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Cancels the effects
+ of <function>pg_replication_origin_session_setup()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_session_is_setup</primary>
+ </indexterm>
+ <function>pg_replication_origin_session_is_setup</function> ()
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Returns true if a replication origin has been selected in the
+ current session.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-session-progress" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_session_progress</primary>
+ </indexterm>
+ <function>pg_replication_origin_session_progress</function> ( <parameter>flush</parameter> <type>boolean</type> )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the replay location for the replication origin selected in
+ the current session. The parameter <parameter>flush</parameter>
+ determines whether the corresponding local transaction will be
+ guaranteed to have been flushed to disk or not.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-xact-setup" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_xact_setup</primary>
+ </indexterm>
+ <function>pg_replication_origin_xact_setup</function> ( <parameter>origin_lsn</parameter> <type>pg_lsn</type>, <parameter>origin_timestamp</parameter> <type>timestamp with time zone</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Marks the current transaction as replaying a transaction that has
+ committed at the given <acronym>LSN</acronym> and timestamp. Can
+ only be called when a replication origin has been selected
+ using <function>pg_replication_origin_session_setup</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-xact-reset" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_xact_reset</primary>
+ </indexterm>
+ <function>pg_replication_origin_xact_reset</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Cancels the effects of
+ <function>pg_replication_origin_xact_setup()</function>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-advance" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_advance</primary>
+ </indexterm>
+ <function>pg_replication_origin_advance</function> ( <parameter>node_name</parameter> <type>text</type>, <parameter>lsn</parameter> <type>pg_lsn</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Sets replication progress for the given node to the given
+ location. This is primarily useful for setting up the initial
+ location, or setting a new location after configuration changes and
+ similar. Be aware that careless use of this function can lead to
+ inconsistently replicated data.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-replication-origin-progress" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_replication_origin_progress</primary>
+ </indexterm>
+ <function>pg_replication_origin_progress</function> ( <parameter>node_name</parameter> <type>text</type>, <parameter>flush</parameter> <type>boolean</type> )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Returns the replay location for the given replication origin. The
+ parameter <parameter>flush</parameter> determines whether the
+ corresponding local transaction will be guaranteed to have been
+ flushed to disk or not.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-logical-emit-message" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_logical_emit_message</primary>
+ </indexterm>
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <returnvalue>pg_lsn</returnvalue>
+ </para>
+ <para>
+ Emits a logical decoding message. This can be used to pass generic
+ messages to logical decoding plugins through
+ WAL. The <parameter>transactional</parameter> parameter specifies if
+ the message should be part of the current transaction, or if it should
+ be written immediately and decoded as soon as the logical decoder
+ reads the record. The <parameter>prefix</parameter> parameter is a
+ textual prefix that can be used by logical decoding plugins to easily
+ recognize messages that are interesting for them.
+ The <parameter>content</parameter> parameter is the content of the
+ message, given either in text or binary form.
+ The <parameter>flush</parameter> parameter (default set to
+ <literal>false</literal>) controls if the message is immediately
+ flushed to WAL or not. <parameter>flush</parameter> has no effect
+ with <parameter>transactional</parameter>, as the message's WAL
+ record is flushed along with its transaction.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry id="pg-sync-replication-slots" role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_sync_replication_slots</primary>
+ </indexterm>
+ <function>pg_sync_replication_slots</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Synchronize the logical failover replication slots from the primary
+ server to the standby server. This function can only be executed on the
+ standby server. Temporary synced slots, if any, cannot be used for
+ logical decoding and must be dropped after promotion. See
+ <xref linkend="logicaldecoding-replication-slots-synchronization"/> for details.
+ Note that this function cannot be executed if
+ <link linkend="guc-sync-replication-slots"><varname>
+ sync_replication_slots</varname></link> is enabled and the slotsync
+ worker is already running to perform the synchronization of slots.
+ </para>
+
+ <caution>
+ <para>
+ If, after executing the function,
+ <link linkend="guc-hot-standby-feedback">
+ <varname>hot_standby_feedback</varname></link> is disabled on
+ the standby or the physical slot configured in
+ <link linkend="guc-primary-slot-name">
+ <varname>primary_slot_name</varname></link> is
+ removed, then it is possible that the necessary rows of the
+ synchronized slot will be removed by the VACUUM process on the primary
+ server, resulting in the synchronized slot becoming invalidated.
+ </para>
+ </caution>
+ </entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-admin-dbobject">
+ <title>Database Object Management Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-admin-dbsize"/> calculate
+ the disk space usage of database objects, or assist in presentation
+ or understanding of usage results. <literal>bigint</literal> results
+ are measured in bytes. If an OID that does
+ not represent an existing object is passed to one of these
+ functions, <literal>NULL</literal> is returned.
+ </para>
+
+ <table id="functions-admin-dbsize">
+ <title>Database Object Size Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_column_size</primary>
+ </indexterm>
+ <function>pg_column_size</function> ( <type>"any"</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Shows the number of bytes used to store any individual data value. If
+ applied directly to a table column value, this reflects any
+ compression that was done.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_column_compression</primary>
+ </indexterm>
+ <function>pg_column_compression</function> ( <type>"any"</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Shows the compression algorithm that was used to compress
+ an individual variable-length value. Returns <literal>NULL</literal>
+ if the value is not compressed.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_column_toast_chunk_id</primary>
+ </indexterm>
+ <function>pg_column_toast_chunk_id</function> ( <type>"any"</type> )
+ <returnvalue>oid</returnvalue>
+ </para>
+ <para>
+ Shows the <structfield>chunk_id</structfield> of an on-disk
+ <acronym>TOAST</acronym>ed value. Returns <literal>NULL</literal>
+ if the value is un-<acronym>TOAST</acronym>ed or not on-disk. See
+ <xref linkend="storage-toast"/> for more information about
+ <acronym>TOAST</acronym>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_database_size</primary>
+ </indexterm>
+ <function>pg_database_size</function> ( <type>name</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_database_size</function> ( <type>oid</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the total disk space used by the database with the specified
+ name or OID. To use this function, you must
+ have <literal>CONNECT</literal> privilege on the specified database
+ (which is granted by default) or have privileges of
+ the <literal>pg_read_all_stats</literal> role.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_indexes_size</primary>
+ </indexterm>
+ <function>pg_indexes_size</function> ( <type>regclass</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the total disk space used by indexes attached to the
+ specified table.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_relation_size</primary>
+ </indexterm>
+ <function>pg_relation_size</function> ( <parameter>relation</parameter> <type>regclass</type> <optional>, <parameter>fork</parameter> <type>text</type> </optional> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the disk space used by one <quote>fork</quote> of the
+ specified relation. (Note that for most purposes it is more
+ convenient to use the higher-level
+ functions <function>pg_total_relation_size</function>
+ or <function>pg_table_size</function>, which sum the sizes of all
+ forks.) With one argument, this returns the size of the main data
+ fork of the relation. The second argument can be provided to specify
+ which fork to examine:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>main</literal> returns the size of the main
+ data fork of the relation.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>fsm</literal> returns the size of the Free Space Map
+ (see <xref linkend="storage-fsm"/>) associated with the relation.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>vm</literal> returns the size of the Visibility Map
+ (see <xref linkend="storage-vm"/>) associated with the relation.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>init</literal> returns the size of the initialization
+ fork, if any, associated with the relation.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_size_bytes</primary>
+ </indexterm>
+ <function>pg_size_bytes</function> ( <type>text</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Converts a size in human-readable format (as returned
+ by <function>pg_size_pretty</function>) into bytes. Valid units are
+ <literal>bytes</literal>, <literal>B</literal>, <literal>kB</literal>,
+ <literal>MB</literal>, <literal>GB</literal>, <literal>TB</literal>,
+ and <literal>PB</literal>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_size_pretty</primary>
+ </indexterm>
+ <function>pg_size_pretty</function> ( <type>bigint</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_size_pretty</function> ( <type>numeric</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Converts a size in bytes into a more easily human-readable format with
+ size units (bytes, kB, MB, GB, TB, or PB as appropriate). Note that the
+ units are powers of 2 rather than powers of 10, so 1kB is 1024 bytes,
+ 1MB is 1024<superscript>2</superscript> = 1048576 bytes, and so on.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_table_size</primary>
+ </indexterm>
+ <function>pg_table_size</function> ( <type>regclass</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the disk space used by the specified table, excluding indexes
+ (but including its TOAST table if any, free space map, and visibility
+ map).
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_tablespace_size</primary>
+ </indexterm>
+ <function>pg_tablespace_size</function> ( <type>name</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_tablespace_size</function> ( <type>oid</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the total disk space used in the tablespace with the
+ specified name or OID. To use this function, you must
+ have <literal>CREATE</literal> privilege on the specified tablespace
+ or have privileges of the <literal>pg_read_all_stats</literal> role,
+ unless it is the default tablespace for the current database.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_total_relation_size</primary>
+ </indexterm>
+ <function>pg_total_relation_size</function> ( <type>regclass</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Computes the total disk space used by the specified table, including
+ all indexes and <acronym>TOAST</acronym> data. The result is
+ equivalent to <function>pg_table_size</function>
+ <literal>+</literal> <function>pg_indexes_size</function>.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The functions above that operate on tables or indexes accept a
+ <type>regclass</type> argument, which is simply the OID of the table or index
+ in the <structname>pg_class</structname> system catalog. You do not have to look up
+ the OID by hand, however, since the <type>regclass</type> data type's input
+ converter will do the work for you. See <xref linkend="datatype-oid"/>
+ for details.
+ </para>
+
+ <para>
+ The functions shown in <xref linkend="functions-admin-dblocation"/> assist
+ in identifying the specific disk files associated with database objects.
+ </para>
+
+ <table id="functions-admin-dblocation">
+ <title>Database Object Location Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_relation_filenode</primary>
+ </indexterm>
+ <function>pg_relation_filenode</function> ( <parameter>relation</parameter> <type>regclass</type> )
+ <returnvalue>oid</returnvalue>
+ </para>
+ <para>
+ Returns the <quote>filenode</quote> number currently assigned to the
+ specified relation. The filenode is the base component of the file
+ name(s) used for the relation (see
+ <xref linkend="storage-file-layout"/> for more information).
+ For most relations the result is the same as
+ <structname>pg_class</structname>.<structfield>relfilenode</structfield>,
+ but for certain system catalogs <structfield>relfilenode</structfield>
+ is zero and this function must be used to get the correct value. The
+ function returns NULL if passed a relation that does not have storage,
+ such as a view.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_relation_filepath</primary>
+ </indexterm>
+ <function>pg_relation_filepath</function> ( <parameter>relation</parameter> <type>regclass</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the entire file path name (relative to the database cluster's
+ data directory, <varname>PGDATA</varname>) of the relation.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_filenode_relation</primary>
+ </indexterm>
+ <function>pg_filenode_relation</function> ( <parameter>tablespace</parameter> <type>oid</type>, <parameter>filenode</parameter> <type>oid</type> )
+ <returnvalue>regclass</returnvalue>
+ </para>
+ <para>
+ Returns a relation's OID given the tablespace OID and filenode it is
+ stored under. This is essentially the inverse mapping of
+ <function>pg_relation_filepath</function>. For a relation in the
+ database's default tablespace, the tablespace can be specified as zero.
+ Returns <literal>NULL</literal> if no relation in the current database
+ is associated with the given values.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-admin-collation"/> lists functions used to manage
+ collations.
+ </para>
+
+ <table id="functions-admin-collation">
+ <title>Collation Management Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_collation_actual_version</primary>
+ </indexterm>
+ <function>pg_collation_actual_version</function> ( <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the actual version of the collation object as it is currently
+ installed in the operating system. If this is different from the
+ value in
+ <structname>pg_collation</structname>.<structfield>collversion</structfield>,
+ then objects depending on the collation might need to be rebuilt. See
+ also <xref linkend="sql-altercollation"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_database_collation_actual_version</primary>
+ </indexterm>
+ <function>pg_database_collation_actual_version</function> ( <type>oid</type> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns the actual version of the database's collation as it is currently
+ installed in the operating system. If this is different from the
+ value in
+ <structname>pg_database</structname>.<structfield>datcollversion</structfield>,
+ then objects depending on the collation might need to be rebuilt. See
+ also <xref linkend="sql-alterdatabase"/>.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_import_system_collations</primary>
+ </indexterm>
+ <function>pg_import_system_collations</function> ( <parameter>schema</parameter> <type>regnamespace</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Adds collations to the system
+ catalog <structname>pg_collation</structname> based on all the locales
+ it finds in the operating system. This is
+ what <command>initdb</command> uses; see
+ <xref linkend="collation-managing"/> for more details. If additional
+ locales are installed into the operating system later on, this
+ function can be run again to add collations for the new locales.
+ Locales that match existing entries
+ in <structname>pg_collation</structname> will be skipped. (But
+ collation objects based on locales that are no longer present in the
+ operating system are not removed by this function.)
+ The <parameter>schema</parameter> parameter would typically
+ be <literal>pg_catalog</literal>, but that is not a requirement; the
+ collations could be installed into some other schema as well. The
+ function returns the number of new collation objects it created.
+ Use of this function is restricted to superusers.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <xref linkend="functions-info-partition"/> lists functions that provide
+ information about the structure of partitioned tables.
+ </para>
+
+ <table id="functions-info-partition">
+ <title>Partitioning Information Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_partition_tree</primary>
+ </indexterm>
+ <function>pg_partition_tree</function> ( <type>regclass</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>relid</parameter> <type>regclass</type>,
+ <parameter>parentrelid</parameter> <type>regclass</type>,
+ <parameter>isleaf</parameter> <type>boolean</type>,
+ <parameter>level</parameter> <type>integer</type> )
+ </para>
+ <para>
+ Lists the tables or indexes in the partition tree of the
+ given partitioned table or partitioned index, with one row for each
+ partition. Information provided includes the OID of the partition,
+ the OID of its immediate parent, a boolean value telling if the
+ partition is a leaf, and an integer telling its level in the hierarchy.
+ The level value is 0 for the input table or index, 1 for its
+ immediate child partitions, 2 for their partitions, and so on.
+ Returns no rows if the relation does not exist or is not a partition
+ or partitioned table.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_partition_ancestors</primary>
+ </indexterm>
+ <function>pg_partition_ancestors</function> ( <type>regclass</type> )
+ <returnvalue>setof regclass</returnvalue>
+ </para>
+ <para>
+ Lists the ancestor relations of the given partition,
+ including the relation itself. Returns no rows if the relation
+ does not exist or is not a partition or partitioned table.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_partition_root</primary>
+ </indexterm>
+ <function>pg_partition_root</function> ( <type>regclass</type> )
+ <returnvalue>regclass</returnvalue>
+ </para>
+ <para>
+ Returns the top-most parent of the partition tree to which the given
+ relation belongs. Returns <literal>NULL</literal> if the relation
+ does not exist or is not a partition or partitioned table.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ For example, to check the total size of the data contained in a
+ partitioned table <structname>measurement</structname>, one could use the
+ following query:
+<programlisting>
+SELECT pg_size_pretty(sum(pg_relation_size(relid))) AS total_size
+ FROM pg_partition_tree('measurement');
+</programlisting>
+ </para>
+
+ </sect2>
+
+ <sect2 id="functions-admin-index">
+ <title>Index Maintenance Functions</title>
+
+ <para>
+ <xref linkend="functions-admin-index-table"/> shows the functions
+ available for index maintenance tasks. (Note that these maintenance
+ tasks are normally done automatically by autovacuum; use of these
+ functions is only required in special cases.)
+ These functions cannot be executed during recovery.
+ Use of these functions is restricted to superusers and the owner
+ of the given index.
+ </para>
+
+ <table id="functions-admin-index-table">
+ <title>Index Maintenance Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>brin_summarize_new_values</primary>
+ </indexterm>
+ <function>brin_summarize_new_values</function> ( <parameter>index</parameter> <type>regclass</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Scans the specified BRIN index to find page ranges in the base table
+ that are not currently summarized by the index; for any such range it
+ creates a new summary index tuple by scanning those table pages.
+ Returns the number of new page range summaries that were inserted
+ into the index.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>brin_summarize_range</primary>
+ </indexterm>
+ <function>brin_summarize_range</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>blockNumber</parameter> <type>bigint</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Summarizes the page range covering the given block, if not already
+ summarized. This is
+ like <function>brin_summarize_new_values</function> except that it
+ only processes the page range that covers the given table block number.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>brin_desummarize_range</primary>
+ </indexterm>
+ <function>brin_desummarize_range</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>blockNumber</parameter> <type>bigint</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Removes the BRIN index tuple that summarizes the page range covering
+ the given table block, if there is one.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>gin_clean_pending_list</primary>
+ </indexterm>
+ <function>gin_clean_pending_list</function> ( <parameter>index</parameter> <type>regclass</type> )
+ <returnvalue>bigint</returnvalue>
+ </para>
+ <para>
+ Cleans up the <quote>pending</quote> list of the specified GIN index
+ by moving entries in it, in bulk, to the main GIN data structure.
+ Returns the number of pages removed from the pending list.
+ If the argument is a GIN index built with
+ the <literal>fastupdate</literal> option disabled, no cleanup happens
+ and the result is zero, because the index doesn't have a pending list.
+ See <xref linkend="gin-fast-update"/> and <xref linkend="gin-tips"/>
+ for details about the pending list and <literal>fastupdate</literal>
+ option.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-admin-genfile">
+ <title>Generic File Access Functions</title>
+
+ <para>
+ The functions shown in <xref
+ linkend="functions-admin-genfile-table"/> provide native access to
+ files on the machine hosting the server. Only files within the
+ database cluster directory and the <varname>log_directory</varname> can be
+ accessed, unless the user is a superuser or is granted the role
+ <literal>pg_read_server_files</literal>. Use a relative path for files in
+ the cluster directory, and a path matching the <varname>log_directory</varname>
+ configuration setting for log files.
+ </para>
+
+ <para>
+ Note that granting users the EXECUTE privilege on
+ <function>pg_read_file()</function>, or related functions, allows them the
+ ability to read any file on the server that the database server process can
+ read; these functions bypass all in-database privilege checks. This means
+ that, for example, a user with such access is able to read the contents of
+ the <structname>pg_authid</structname> table where authentication
+ information is stored, as well as read any table data in the database.
+ Therefore, granting access to these functions should be carefully
+ considered.
+ </para>
+
+ <para>
+ When granting privilege on these functions, note that the table entries
+ showing optional parameters are mostly implemented as several physical
+ functions with different parameter lists. Privilege must be granted
+ separately on each such function, if it is to be
+ used. <application>psql</application>'s <command>\df</command> command
+ can be useful to check what the actual function signatures are.
+ </para>
+
+ <para>
+ Some of these functions take an optional <parameter>missing_ok</parameter>
+ parameter, which specifies the behavior when the file or directory does
+ not exist. If <literal>true</literal>, the function
+ returns <literal>NULL</literal> or an empty result set, as appropriate.
+ If <literal>false</literal>, an error is raised. (Failure conditions
+ other than <quote>file not found</quote> are reported as errors in any
+ case.) The default is <literal>false</literal>.
+ </para>
+
+ <table id="functions-admin-genfile-table">
+ <title>Generic File Access Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_dir</primary>
+ </indexterm>
+ <function>pg_ls_dir</function> ( <parameter>dirname</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type>, <parameter>include_dot_dirs</parameter> <type>boolean</type> </optional> )
+ <returnvalue>setof text</returnvalue>
+ </para>
+ <para>
+ Returns the names of all files (and directories and other special
+ files) in the specified
+ directory. The <parameter>include_dot_dirs</parameter> parameter
+ indicates whether <quote>.</quote> and <quote>..</quote> are to be
+ included in the result set; the default is to exclude them. Including
+ them can be useful when <parameter>missing_ok</parameter>
+ is <literal>true</literal>, to distinguish an empty directory from a
+ non-existent directory.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_logdir</primary>
+ </indexterm>
+ <function>pg_ls_logdir</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's log directory. Filenames beginning with
+ a dot, directories, and other special files are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and roles with privileges of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_waldir</primary>
+ </indexterm>
+ <function>pg_ls_waldir</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's write-ahead log (WAL) directory.
+ Filenames beginning with a dot, directories, and other special files
+ are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and roles with privileges of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_logicalmapdir</primary>
+ </indexterm>
+ <function>pg_ls_logicalmapdir</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's <filename>pg_logical/mappings</filename>
+ directory. Filenames beginning with a dot, directories, and other
+ special files are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and members of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_logicalsnapdir</primary>
+ </indexterm>
+ <function>pg_ls_logicalsnapdir</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's <filename>pg_logical/snapshots</filename>
+ directory. Filenames beginning with a dot, directories, and other
+ special files are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and members of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_replslotdir</primary>
+ </indexterm>
+ <function>pg_ls_replslotdir</function> ( <parameter>slot_name</parameter> <type>text</type> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's <filename>pg_replslot/slot_name</filename>
+ directory, where <parameter>slot_name</parameter> is the name of the
+ replication slot provided as input of the function. Filenames beginning
+ with a dot, directories, and other special files are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and members of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_ls_archive_statusdir</primary>
+ </indexterm>
+ <function>pg_ls_archive_statusdir</function> ()
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the server's WAL archive status directory
+ (<filename>pg_wal/archive_status</filename>). Filenames beginning
+ with a dot, directories, and other special files are excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and members of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+
+ <indexterm>
+ <primary>pg_ls_tmpdir</primary>
+ </indexterm>
+ <function>pg_ls_tmpdir</function> ( <optional> <parameter>tablespace</parameter> <type>oid</type> </optional> )
+ <returnvalue>setof record</returnvalue>
+ ( <parameter>name</parameter> <type>text</type>,
+ <parameter>size</parameter> <type>bigint</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type> )
+ </para>
+ <para>
+ Returns the name, size, and last modification time (mtime) of each
+ ordinary file in the temporary file directory for the
+ specified <parameter>tablespace</parameter>.
+ If <parameter>tablespace</parameter> is not provided,
+ the <literal>pg_default</literal> tablespace is examined. Filenames
+ beginning with a dot, directories, and other special files are
+ excluded.
+ </para>
+ <para>
+ This function is restricted to superusers and members of
+ the <literal>pg_monitor</literal> role by default, but other users can
+ be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_read_file</primary>
+ </indexterm>
+ <function>pg_read_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>offset</parameter> <type>bigint</type>, <parameter>length</parameter> <type>bigint</type> </optional> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Returns all or part of a text file, starting at the
+ given byte <parameter>offset</parameter>, returning at
+ most <parameter>length</parameter> bytes (less if the end of file is
+ reached first). If <parameter>offset</parameter> is negative, it is
+ relative to the end of the file. If <parameter>offset</parameter>
+ and <parameter>length</parameter> are omitted, the entire file is
+ returned. The bytes read from the file are interpreted as a string in
+ the database's encoding; an error is thrown if they are not valid in
+ that encoding.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_read_binary_file</primary>
+ </indexterm>
+ <function>pg_read_binary_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>offset</parameter> <type>bigint</type>, <parameter>length</parameter> <type>bigint</type> </optional> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
+ <returnvalue>bytea</returnvalue>
+ </para>
+ <para>
+ Returns all or part of a file. This function is identical to
+ <function>pg_read_file</function> except that it can read arbitrary
+ binary data, returning the result as <type>bytea</type>
+ not <type>text</type>; accordingly, no encoding checks are performed.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para>
+ <para>
+ In combination with the <function>convert_from</function> function,
+ this function can be used to read a text file in a specified encoding
+ and convert to the database's encoding:
+<programlisting>
+SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
+</programlisting>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_stat_file</primary>
+ </indexterm>
+ <function>pg_stat_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
+ <returnvalue>record</returnvalue>
+ ( <parameter>size</parameter> <type>bigint</type>,
+ <parameter>access</parameter> <type>timestamp with time zone</type>,
+ <parameter>modification</parameter> <type>timestamp with time zone</type>,
+ <parameter>change</parameter> <type>timestamp with time zone</type>,
+ <parameter>creation</parameter> <type>timestamp with time zone</type>,
+ <parameter>isdir</parameter> <type>boolean</type> )
+ </para>
+ <para>
+ Returns a record containing the file's size, last access time stamp,
+ last modification time stamp, last file status change time stamp (Unix
+ platforms only), file creation time stamp (Windows only), and a flag
+ indicating if it is a directory.
+ </para>
+ <para>
+ This function is restricted to superusers by default, but other users
+ can be granted EXECUTE to run the function.
+ </para></entry>
+ </row>
+
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ <sect2 id="functions-advisory-locks">
+ <title>Advisory Lock Functions</title>
+
+ <para>
+ The functions shown in <xref linkend="functions-advisory-locks-table"/>
+ manage advisory locks. For details about proper use of these functions,
+ see <xref linkend="advisory-locks"/>.
+ </para>
+
+ <para>
+ All these functions are intended to be used to lock application-defined
+ resources, which can be identified either by a single 64-bit key value or
+ two 32-bit key values (note that these two key spaces do not overlap).
+ If another session already holds a conflicting lock on the same resource
+ identifier, the functions will either wait until the resource becomes
+ available, or return a <literal>false</literal> result, as appropriate for
+ the function.
+ Locks can be either shared or exclusive: a shared lock does not conflict
+ with other shared locks on the same resource, only with exclusive locks.
+ Locks can be taken at session level (so that they are held until released
+ or the session ends) or at transaction level (so that they are held until
+ the current transaction ends; there is no provision for manual release).
+ Multiple session-level lock requests stack, so that if the same resource
+ identifier is locked three times there must then be three unlock requests
+ to release the resource in advance of session end.
+ </para>
+
+ <table id="functions-advisory-locks-table">
+ <title>Advisory Lock Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_lock</primary>
+ </indexterm>
+ <function>pg_advisory_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Obtains an exclusive session-level advisory lock, waiting if necessary.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_lock_shared</primary>
+ </indexterm>
+ <function>pg_advisory_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Obtains a shared session-level advisory lock, waiting if necessary.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_unlock</primary>
+ </indexterm>
+ <function>pg_advisory_unlock</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_unlock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Releases a previously-acquired exclusive session-level advisory lock.
+ Returns <literal>true</literal> if the lock is successfully released.
+ If the lock was not held, <literal>false</literal> is returned, and in
+ addition, an SQL warning will be reported by the server.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_unlock_all</primary>
+ </indexterm>
+ <function>pg_advisory_unlock_all</function> ()
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Releases all session-level advisory locks held by the current session.
+ (This function is implicitly invoked at session end, even if the
+ client disconnects ungracefully.)
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_unlock_shared</primary>
+ </indexterm>
+ <function>pg_advisory_unlock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_unlock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Releases a previously-acquired shared session-level advisory lock.
+ Returns <literal>true</literal> if the lock is successfully released.
+ If the lock was not held, <literal>false</literal> is returned, and in
+ addition, an SQL warning will be reported by the server.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_xact_lock</primary>
+ </indexterm>
+ <function>pg_advisory_xact_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_xact_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Obtains an exclusive transaction-level advisory lock, waiting if
+ necessary.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_advisory_xact_lock_shared</primary>
+ </indexterm>
+ <function>pg_advisory_xact_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_advisory_xact_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>void</returnvalue>
+ </para>
+ <para>
+ Obtains a shared transaction-level advisory lock, waiting if
+ necessary.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_try_advisory_lock</primary>
+ </indexterm>
+ <function>pg_try_advisory_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_try_advisory_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Obtains an exclusive session-level advisory lock if available.
+ This will either obtain the lock immediately and
+ return <literal>true</literal>, or return <literal>false</literal>
+ without waiting if the lock cannot be acquired immediately.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_try_advisory_lock_shared</primary>
+ </indexterm>
+ <function>pg_try_advisory_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_try_advisory_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Obtains a shared session-level advisory lock if available.
+ This will either obtain the lock immediately and
+ return <literal>true</literal>, or return <literal>false</literal>
+ without waiting if the lock cannot be acquired immediately.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_try_advisory_xact_lock</primary>
+ </indexterm>
+ <function>pg_try_advisory_xact_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_try_advisory_xact_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Obtains an exclusive transaction-level advisory lock if available.
+ This will either obtain the lock immediately and
+ return <literal>true</literal>, or return <literal>false</literal>
+ without waiting if the lock cannot be acquired immediately.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>pg_try_advisory_xact_lock_shared</primary>
+ </indexterm>
+ <function>pg_try_advisory_xact_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para role="func_signature">
+ <function>pg_try_advisory_xact_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Obtains a shared transaction-level advisory lock if available.
+ This will either obtain the lock immediately and
+ return <literal>true</literal>, or return <literal>false</literal>
+ without waiting if the lock cannot be acquired immediately.
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </sect2>
+
+ </sect1>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 35a2d25b..c8cb94a9 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -12603,2693 +12603,7 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
</sect1>
&func-info;
-
- <sect1 id="functions-admin">
- <title>System Administration Functions</title>
-
- <para>
- The functions described in this section are used to control and
- monitor a <productname>PostgreSQL</productname> installation.
- </para>
-
- <sect2 id="functions-admin-set">
- <title>Configuration Settings Functions</title>
-
- <indexterm>
- <primary>SET</primary>
- </indexterm>
-
- <indexterm>
- <primary>SHOW</primary>
- </indexterm>
-
- <indexterm>
- <primary>configuration</primary>
- <secondary sortas="server">of the server</secondary>
- <tertiary>functions</tertiary>
- </indexterm>
-
- <para>
- <xref linkend="functions-admin-set-table"/> shows the functions
- available to query and alter run-time configuration parameters.
- </para>
-
- <table id="functions-admin-set-table">
- <title>Configuration Settings Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_setting</primary>
- </indexterm>
- <function>current_setting</function> ( <parameter>setting_name</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the current value of the
- setting <parameter>setting_name</parameter>. If there is no such
- setting, <function>current_setting</function> throws an error
- unless <parameter>missing_ok</parameter> is supplied and
- is <literal>true</literal> (in which case NULL is returned).
- This function corresponds to
- the <acronym>SQL</acronym> command <xref linkend="sql-show"/>.
- </para>
- <para>
- <literal>current_setting('datestyle')</literal>
- <returnvalue>ISO, MDY</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>set_config</primary>
- </indexterm>
- <function>set_config</function> (
- <parameter>setting_name</parameter> <type>text</type>,
- <parameter>new_value</parameter> <type>text</type>,
- <parameter>is_local</parameter> <type>boolean</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Sets the parameter <parameter>setting_name</parameter>
- to <parameter>new_value</parameter>, and returns that value.
- If <parameter>is_local</parameter> is <literal>true</literal>, the new
- value will only apply during the current transaction. If you want the
- new value to apply for the rest of the current session,
- use <literal>false</literal> instead. This function corresponds to
- the SQL command <xref linkend="sql-set"/>.
- </para>
- <para>
- <literal>set_config('log_statement_stats', 'off', false)</literal>
- <returnvalue>off</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-admin-signal">
- <title>Server Signaling Functions</title>
-
- <indexterm>
- <primary>signal</primary>
- <secondary sortas="backend">backend processes</secondary>
- </indexterm>
-
- <para>
- The functions shown in <xref
- linkend="functions-admin-signal-table"/> send control signals to
- other server processes. Use of these functions is restricted to
- superusers by default but access may be granted to others using
- <command>GRANT</command>, with noted exceptions.
- </para>
-
- <para>
- Each of these functions returns <literal>true</literal> if
- the signal was successfully sent and <literal>false</literal>
- if sending the signal failed.
- </para>
-
- <table id="functions-admin-signal-table">
- <title>Server Signaling Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_cancel_backend</primary>
- </indexterm>
- <function>pg_cancel_backend</function> ( <parameter>pid</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Cancels the current query of the session whose backend process has the
- specified process ID. This is also allowed if the
- calling role is a member of the role whose backend is being canceled or
- the calling role has privileges of <literal>pg_signal_backend</literal>,
- however only superusers can cancel superuser backends.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_log_backend_memory_contexts</primary>
- </indexterm>
- <function>pg_log_backend_memory_contexts</function> ( <parameter>pid</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Requests to log the memory contexts of the backend with the
- specified process ID. This function can send the request to
- backends and auxiliary processes except logger. These memory contexts
- will be logged at
- <literal>LOG</literal> message level. They will appear in
- the server log based on the log configuration set
- (see <xref linkend="runtime-config-logging"/> for more information),
- but will not be sent to the client regardless of
- <xref linkend="guc-client-min-messages"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_reload_conf</primary>
- </indexterm>
- <function>pg_reload_conf</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Causes all processes of the <productname>PostgreSQL</productname>
- server to reload their configuration files. (This is initiated by
- sending a <systemitem>SIGHUP</systemitem> signal to the postmaster
- process, which in turn sends <systemitem>SIGHUP</systemitem> to each
- of its children.) You can use the
- <link linkend="view-pg-file-settings"><structname>pg_file_settings</structname></link>,
- <link linkend="view-pg-hba-file-rules"><structname>pg_hba_file_rules</structname></link> and
- <link linkend="view-pg-ident-file-mappings"><structname>pg_ident_file_mappings</structname></link> views
- to check the configuration files for possible errors, before reloading.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_rotate_logfile</primary>
- </indexterm>
- <function>pg_rotate_logfile</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Signals the log-file manager to switch to a new output file
- immediately. This works only when the built-in log collector is
- running, since otherwise there is no log-file manager subprocess.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_terminate_backend</primary>
- </indexterm>
- <function>pg_terminate_backend</function> ( <parameter>pid</parameter> <type>integer</type>, <parameter>timeout</parameter> <type>bigint</type> <literal>DEFAULT</literal> <literal>0</literal> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Terminates the session whose backend process has the
- specified process ID. This is also allowed if the calling role
- is a member of the role whose backend is being terminated or the
- calling role has privileges of <literal>pg_signal_backend</literal>,
- however only superusers can terminate superuser backends.
- </para>
- <para>
- If <parameter>timeout</parameter> is not specified or zero, this
- function returns <literal>true</literal> whether the process actually
- terminates or not, indicating only that the sending of the signal was
- successful. If the <parameter>timeout</parameter> is specified (in
- milliseconds) and greater than zero, the function waits until the
- process is actually terminated or until the given time has passed. If
- the process is terminated, the function
- returns <literal>true</literal>. On timeout, a warning is emitted and
- <literal>false</literal> is returned.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <function>pg_cancel_backend</function> and <function>pg_terminate_backend</function>
- send signals (<systemitem>SIGINT</systemitem> or <systemitem>SIGTERM</systemitem>
- respectively) to backend processes identified by process ID.
- The process ID of an active backend can be found from
- the <structfield>pid</structfield> column of the
- <structname>pg_stat_activity</structname> view, or by listing the
- <command>postgres</command> processes on the server (using
- <application>ps</application> on Unix or the <application>Task
- Manager</application> on <productname>Windows</productname>).
- The role of an active backend can be found from the
- <structfield>usename</structfield> column of the
- <structname>pg_stat_activity</structname> view.
- </para>
-
- <para>
- <function>pg_log_backend_memory_contexts</function> can be used
- to log the memory contexts of a backend process. For example:
-<programlisting>
-postgres=# SELECT pg_log_backend_memory_contexts(pg_backend_pid());
- pg_log_backend_memory_contexts
---------------------------------
- t
-(1 row)
-</programlisting>
-One message for each memory context will be logged. For example:
-<screen>
-LOG: logging memory contexts of PID 10377
-STATEMENT: SELECT pg_log_backend_memory_contexts(pg_backend_pid());
-LOG: level: 0; TopMemoryContext: 80800 total in 6 blocks; 14432 free (5 chunks); 66368 used
-LOG: level: 1; pgstat TabStatusArray lookup hash table: 8192 total in 1 blocks; 1408 free (0 chunks); 6784 used
-LOG: level: 1; TopTransactionContext: 8192 total in 1 blocks; 7720 free (1 chunks); 472 used
-LOG: level: 1; RowDescriptionContext: 8192 total in 1 blocks; 6880 free (0 chunks); 1312 used
-LOG: level: 1; MessageContext: 16384 total in 2 blocks; 5152 free (0 chunks); 11232 used
-LOG: level: 1; Operator class cache: 8192 total in 1 blocks; 512 free (0 chunks); 7680 used
-LOG: level: 1; smgr relation table: 16384 total in 2 blocks; 4544 free (3 chunks); 11840 used
-LOG: level: 1; TransactionAbortContext: 32768 total in 1 blocks; 32504 free (0 chunks); 264 used
-...
-LOG: level: 1; ErrorContext: 8192 total in 1 blocks; 7928 free (3 chunks); 264 used
-LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560 used
-</screen>
- If there are more than 100 child contexts under the same parent, the first
- 100 child contexts are logged, along with a summary of the remaining contexts.
- Note that frequent calls to this function could incur significant overhead,
- because it may generate a large number of log messages.
- </para>
-
- </sect2>
-
- <sect2 id="functions-admin-backup">
- <title>Backup Control Functions</title>
-
- <indexterm>
- <primary>backup</primary>
- </indexterm>
-
- <para>
- The functions shown in <xref
- linkend="functions-admin-backup-table"/> assist in making on-line backups.
- These functions cannot be executed during recovery (except
- <function>pg_backup_start</function>,
- <function>pg_backup_stop</function>,
- and <function>pg_wal_lsn_diff</function>).
- </para>
-
- <para>
- For details about proper usage of these functions, see
- <xref linkend="continuous-archiving"/>.
- </para>
-
- <table id="functions-admin-backup-table">
- <title>Backup Control Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_create_restore_point</primary>
- </indexterm>
- <function>pg_create_restore_point</function> ( <parameter>name</parameter> <type>text</type> )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Creates a named marker record in the write-ahead log that can later be
- used as a recovery target, and returns the corresponding write-ahead
- log location. The given name can then be used with
- <xref linkend="guc-recovery-target-name"/> to specify the point up to
- which recovery will proceed. Avoid creating multiple restore points
- with the same name, since recovery will stop at the first one whose
- name matches the recovery target.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_wal_flush_lsn</primary>
- </indexterm>
- <function>pg_current_wal_flush_lsn</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the current write-ahead log flush location (see notes below).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_wal_insert_lsn</primary>
- </indexterm>
- <function>pg_current_wal_insert_lsn</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the current write-ahead log insert location (see notes below).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_current_wal_lsn</primary>
- </indexterm>
- <function>pg_current_wal_lsn</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the current write-ahead log write location (see notes below).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_backup_start</primary>
- </indexterm>
- <function>pg_backup_start</function> (
- <parameter>label</parameter> <type>text</type>
- <optional>, <parameter>fast</parameter> <type>boolean</type>
- </optional> )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Prepares the server to begin an on-line backup. The only required
- parameter is an arbitrary user-defined label for the backup.
- (Typically this would be the name under which the backup dump file
- will be stored.)
- If the optional second parameter is given as <literal>true</literal>,
- it specifies executing <function>pg_backup_start</function> as quickly
- as possible. This forces an immediate checkpoint which will cause a
- spike in I/O operations, slowing any concurrently executing queries.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_backup_stop</primary>
- </indexterm>
- <function>pg_backup_stop</function> (
- <optional><parameter>wait_for_archive</parameter> <type>boolean</type>
- </optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>labelfile</parameter> <type>text</type>,
- <parameter>spcmapfile</parameter> <type>text</type> )
- </para>
- <para>
- Finishes performing an on-line backup. The desired contents of the
- backup label file and the tablespace map file are returned as part of
- the result of the function and must be written to files in the
- backup area. These files must not be written to the live data directory
- (doing so will cause PostgreSQL to fail to restart in the event of a
- crash).
- </para>
- <para>
- There is an optional parameter of type <type>boolean</type>.
- If false, the function will return immediately after the backup is
- completed, without waiting for WAL to be archived. This behavior is
- only useful with backup software that independently monitors WAL
- archiving. Otherwise, WAL required to make the backup consistent might
- be missing and make the backup useless. By default or when this
- parameter is true, <function>pg_backup_stop</function> will wait for
- WAL to be archived when archiving is enabled. (On a standby, this
- means that it will wait only when <varname>archive_mode</varname> =
- <literal>always</literal>. If write activity on the primary is low,
- it may be useful to run <function>pg_switch_wal</function> on the
- primary in order to trigger an immediate segment switch.)
- </para>
- <para>
- When executed on a primary, this function also creates a backup
- history file in the write-ahead log archive area. The history file
- includes the label given to <function>pg_backup_start</function>, the
- starting and ending write-ahead log locations for the backup, and the
- starting and ending times of the backup. After recording the ending
- location, the current write-ahead log insertion point is automatically
- advanced to the next write-ahead log file, so that the ending
- write-ahead log file can be archived immediately to complete the
- backup.
- </para>
- <para>
- The result of the function is a single record.
- The <parameter>lsn</parameter> column holds the backup's ending
- write-ahead log location (which again can be ignored). The second
- column returns the contents of the backup label file, and the third
- column returns the contents of the tablespace map file. These must be
- stored as part of the backup and are required as part of the restore
- process.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_switch_wal</primary>
- </indexterm>
- <function>pg_switch_wal</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Forces the server to switch to a new write-ahead log file, which
- allows the current file to be archived (assuming you are using
- continuous archiving). The result is the ending write-ahead log
- location plus 1 within the just-completed write-ahead log file. If
- there has been no write-ahead log activity since the last write-ahead
- log switch, <function>pg_switch_wal</function> does nothing and
- returns the start location of the write-ahead log file currently in
- use.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_walfile_name</primary>
- </indexterm>
- <function>pg_walfile_name</function> ( <parameter>lsn</parameter> <type>pg_lsn</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts a write-ahead log location to the name of the WAL file
- holding that location.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_walfile_name_offset</primary>
- </indexterm>
- <function>pg_walfile_name_offset</function> ( <parameter>lsn</parameter> <type>pg_lsn</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>file_name</parameter> <type>text</type>,
- <parameter>file_offset</parameter> <type>integer</type> )
- </para>
- <para>
- Converts a write-ahead log location to a WAL file name and byte offset
- within that file.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_split_walfile_name</primary>
- </indexterm>
- <function>pg_split_walfile_name</function> ( <parameter>file_name</parameter> <type>text</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>segment_number</parameter> <type>numeric</type>,
- <parameter>timeline_id</parameter> <type>bigint</type> )
- </para>
- <para>
- Extracts the sequence number and timeline ID from a WAL file
- name.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_wal_lsn_diff</primary>
- </indexterm>
- <function>pg_wal_lsn_diff</function> ( <parameter>lsn1</parameter> <type>pg_lsn</type>, <parameter>lsn2</parameter> <type>pg_lsn</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para>
- Calculates the difference in bytes (<parameter>lsn1</parameter> - <parameter>lsn2</parameter>) between two write-ahead log
- locations. This can be used
- with <structname>pg_stat_replication</structname> or some of the
- functions shown in <xref linkend="functions-admin-backup-table"/> to
- get the replication lag.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <function>pg_current_wal_lsn</function> displays the current write-ahead
- log write location in the same format used by the above functions.
- Similarly, <function>pg_current_wal_insert_lsn</function> displays the
- current write-ahead log insertion location
- and <function>pg_current_wal_flush_lsn</function> displays the current
- write-ahead log flush location. The insertion location is
- the <quote>logical</quote> end of the write-ahead log at any instant,
- while the write location is the end of what has actually been written out
- from the server's internal buffers, and the flush location is the last
- location known to be written to durable storage. The write location is the
- end of what can be examined from outside the server, and is usually what
- you want if you are interested in archiving partially-complete write-ahead
- log files. The insertion and flush locations are made available primarily
- for server debugging purposes. These are all read-only operations and do
- not require superuser permissions.
- </para>
-
- <para>
- You can use <function>pg_walfile_name_offset</function> to extract the
- corresponding write-ahead log file name and byte offset from
- a <type>pg_lsn</type> value. For example:
-<programlisting>
-postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
- file_name | file_offset
---------------------------+-------------
- 00000001000000000000000D | 4039624
-(1 row)
-</programlisting>
- Similarly, <function>pg_walfile_name</function> extracts just the write-ahead log file name.
- </para>
-
- <para>
- <function>pg_split_walfile_name</function> is useful to compute a
- <acronym>LSN</acronym> from a file offset and WAL file name, for example:
-<programlisting>
-postgres=# \set file_name '000000010000000100C000AB'
-postgres=# \set offset 256
-postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset AS lsn
- FROM pg_split_walfile_name(:'file_name') pd,
- pg_show_all_settings() ps
- WHERE ps.name = 'wal_segment_size';
- lsn
----------------
- C001/AB000100
-(1 row)
-</programlisting>
- </para>
-
- </sect2>
-
- <sect2 id="functions-recovery-control">
- <title>Recovery Control Functions</title>
-
- <para>
- The functions shown in <xref
- linkend="functions-recovery-info-table"/> provide information
- about the current status of a standby server.
- These functions may be executed both during recovery and in normal running.
- </para>
-
- <table id="functions-recovery-info-table">
- <title>Recovery Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_is_in_recovery</primary>
- </indexterm>
- <function>pg_is_in_recovery</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if recovery is still in progress.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_last_wal_receive_lsn</primary>
- </indexterm>
- <function>pg_last_wal_receive_lsn</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the last write-ahead log location that has been received and
- synced to disk by streaming replication. While streaming replication
- is in progress this will increase monotonically. If recovery has
- completed then this will remain static at the location of the last WAL
- record received and synced to disk during recovery. If streaming
- replication is disabled, or if it has not yet started, the function
- returns <literal>NULL</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_last_wal_replay_lsn</primary>
- </indexterm>
- <function>pg_last_wal_replay_lsn</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the last write-ahead log location that has been replayed
- during recovery. If recovery is still in progress this will increase
- monotonically. If recovery has completed then this will remain
- static at the location of the last WAL record applied during recovery.
- When the server has been started normally without recovery, the
- function returns <literal>NULL</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_last_xact_replay_timestamp</primary>
- </indexterm>
- <function>pg_last_xact_replay_timestamp</function> ()
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Returns the time stamp of the last transaction replayed during
- recovery. This is the time at which the commit or abort WAL record
- for that transaction was generated on the primary. If no transactions
- have been replayed during recovery, the function
- returns <literal>NULL</literal>. Otherwise, if recovery is still in
- progress this will increase monotonically. If recovery has completed
- then this will remain static at the time of the last transaction
- applied during recovery. When the server has been started normally
- without recovery, the function returns <literal>NULL</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_wal_resource_managers</primary>
- </indexterm>
- <function>pg_get_wal_resource_managers</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>rm_id</parameter> <type>integer</type>,
- <parameter>rm_name</parameter> <type>text</type>,
- <parameter>rm_builtin</parameter> <type>boolean</type> )
- </para>
- <para>
- Returns the currently-loaded WAL resource managers in the system. The
- column <parameter>rm_builtin</parameter> indicates whether it's a
- built-in resource manager, or a custom resource manager loaded by an
- extension.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The functions shown in <xref
- linkend="functions-recovery-control-table"/> control the progress of recovery.
- These functions may be executed only during recovery.
- </para>
-
- <table id="functions-recovery-control-table">
- <title>Recovery Control Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_is_wal_replay_paused</primary>
- </indexterm>
- <function>pg_is_wal_replay_paused</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if recovery pause is requested.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_get_wal_replay_pause_state</primary>
- </indexterm>
- <function>pg_get_wal_replay_pause_state</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns recovery pause state. The return values are <literal>
- not paused</literal> if pause is not requested, <literal>
- pause requested</literal> if pause is requested but recovery is
- not yet paused, and <literal>paused</literal> if the recovery is
- actually paused.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_promote</primary>
- </indexterm>
- <function>pg_promote</function> ( <parameter>wait</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal>, <parameter>wait_seconds</parameter> <type>integer</type> <literal>DEFAULT</literal> <literal>60</literal> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Promotes a standby server to primary status.
- With <parameter>wait</parameter> set to <literal>true</literal> (the
- default), the function waits until promotion is completed
- or <parameter>wait_seconds</parameter> seconds have passed, and
- returns <literal>true</literal> if promotion is successful
- and <literal>false</literal> otherwise.
- If <parameter>wait</parameter> is set to <literal>false</literal>, the
- function returns <literal>true</literal> immediately after sending a
- <literal>SIGUSR1</literal> signal to the postmaster to trigger
- promotion.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_wal_replay_pause</primary>
- </indexterm>
- <function>pg_wal_replay_pause</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Request to pause recovery. A request doesn't mean that recovery stops
- right away. If you want a guarantee that recovery is actually paused,
- you need to check for the recovery pause state returned by
- <function>pg_get_wal_replay_pause_state()</function>. Note that
- <function>pg_is_wal_replay_paused()</function> returns whether a request
- is made. While recovery is paused, no further database changes are applied.
- If hot standby is active, all new queries will see the same consistent
- snapshot of the database, and no further query conflicts will be generated
- until recovery is resumed.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_wal_replay_resume</primary>
- </indexterm>
- <function>pg_wal_replay_resume</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Restarts recovery if it was paused.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <function>pg_wal_replay_pause</function> and
- <function>pg_wal_replay_resume</function> cannot be executed while
- a promotion is ongoing. If a promotion is triggered while recovery
- is paused, the paused state ends and promotion continues.
- </para>
-
- <para>
- If streaming replication is disabled, the paused state may continue
- indefinitely without a problem. If streaming replication is in
- progress then WAL records will continue to be received, which will
- eventually fill available disk space, depending upon the duration of
- the pause, the rate of WAL generation and available disk space.
- </para>
-
- </sect2>
-
- <sect2 id="functions-snapshot-synchronization">
- <title>Snapshot Synchronization Functions</title>
-
- <para>
- <productname>PostgreSQL</productname> allows database sessions to synchronize their
- snapshots. A <firstterm>snapshot</firstterm> determines which data is visible to the
- transaction that is using the snapshot. Synchronized snapshots are
- necessary when two or more sessions need to see identical content in the
- database. If two sessions just start their transactions independently,
- there is always a possibility that some third transaction commits
- between the executions of the two <command>START TRANSACTION</command> commands,
- so that one session sees the effects of that transaction and the other
- does not.
- </para>
-
- <para>
- To solve this problem, <productname>PostgreSQL</productname> allows a transaction to
- <firstterm>export</firstterm> the snapshot it is using. As long as the exporting
- transaction remains open, other transactions can <firstterm>import</firstterm> its
- snapshot, and thereby be guaranteed that they see exactly the same view
- of the database that the first transaction sees. But note that any
- database changes made by any one of these transactions remain invisible
- to the other transactions, as is usual for changes made by uncommitted
- transactions. So the transactions are synchronized with respect to
- pre-existing data, but act normally for changes they make themselves.
- </para>
-
- <para>
- Snapshots are exported with the <function>pg_export_snapshot</function> function,
- shown in <xref linkend="functions-snapshot-synchronization-table"/>, and
- imported with the <xref linkend="sql-set-transaction"/> command.
- </para>
-
- <table id="functions-snapshot-synchronization-table">
- <title>Snapshot Synchronization Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_export_snapshot</primary>
- </indexterm>
- <function>pg_export_snapshot</function> ()
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Saves the transaction's current snapshot and returns
- a <type>text</type> string identifying the snapshot. This string must
- be passed (outside the database) to clients that want to import the
- snapshot. The snapshot is available for import only until the end of
- the transaction that exported it.
- </para>
- <para>
- A transaction can export more than one snapshot, if needed. Note that
- doing so is only useful in <literal>READ COMMITTED</literal>
- transactions, since in <literal>REPEATABLE READ</literal> and higher
- isolation levels, transactions use the same snapshot throughout their
- lifetime. Once a transaction has exported any snapshots, it cannot be
- prepared with <xref linkend="sql-prepare-transaction"/>.
- </para></entry>
- </row>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_log_standby_snapshot</primary>
- </indexterm>
- <function>pg_log_standby_snapshot</function> ()
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Take a snapshot of running transactions and write it to WAL, without
- having to wait for bgwriter or checkpointer to log one. This is useful
- for logical decoding on standby, as logical slot creation has to wait
- until such a record is replayed on the standby.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-replication">
- <title>Replication Management Functions</title>
-
- <para>
- The functions shown
- in <xref linkend="functions-replication-table"/> are for
- controlling and interacting with replication features.
- See <xref linkend="streaming-replication"/>,
- <xref linkend="streaming-replication-slots"/>, and
- <xref linkend="replication-origins"/>
- for information about the underlying features.
- Use of functions for replication origin is only allowed to the
- superuser by default, but may be allowed to other users by using the
- <literal>GRANT</literal> command.
- Use of functions for replication slots is restricted to superusers
- and users having <literal>REPLICATION</literal> privilege.
- </para>
-
- <para>
- Many of these functions have equivalent commands in the replication
- protocol; see <xref linkend="protocol-replication"/>.
- </para>
-
- <para>
- The functions described in
- <xref linkend="functions-admin-backup"/>,
- <xref linkend="functions-recovery-control"/>, and
- <xref linkend="functions-snapshot-synchronization"/>
- are also relevant for replication.
- </para>
-
- <table id="functions-replication-table">
- <title>Replication Management Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_create_physical_replication_slot</primary>
- </indexterm>
- <function>pg_create_physical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> <optional>, <parameter>immediately_reserve</parameter> <type>boolean</type>, <parameter>temporary</parameter> <type>boolean</type> </optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>slot_name</parameter> <type>name</type>,
- <parameter>lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Creates a new physical replication slot named
- <parameter>slot_name</parameter>. The optional second parameter,
- when <literal>true</literal>, specifies that the <acronym>LSN</acronym> for this
- replication slot be reserved immediately; otherwise
- the <acronym>LSN</acronym> is reserved on first connection from a streaming
- replication client. Streaming changes from a physical slot is only
- possible with the streaming-replication protocol —
- see <xref linkend="protocol-replication"/>. The optional third
- parameter, <parameter>temporary</parameter>, when set to true, specifies that
- the slot should not be permanently stored to disk and is only meant
- for use by the current session. Temporary slots are also
- released upon any error. This function corresponds
- to the replication protocol command <literal>CREATE_REPLICATION_SLOT
- ... PHYSICAL</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_drop_replication_slot</primary>
- </indexterm>
- <function>pg_drop_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Drops the physical or logical replication slot
- named <parameter>slot_name</parameter>. Same as replication protocol
- command <literal>DROP_REPLICATION_SLOT</literal>. For logical slots, this must
- be called while connected to the same database the slot was created on.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-create-logical-replication-slot" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_create_logical_replication_slot</primary>
- </indexterm>
- <function>pg_create_logical_replication_slot</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type>, <parameter>twophase</parameter> <type>boolean</type>, <parameter>failover</parameter> <type>boolean</type> </optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>slot_name</parameter> <type>name</type>,
- <parameter>lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Creates a new logical (decoding) replication slot named
- <parameter>slot_name</parameter> using the output plugin
- <parameter>plugin</parameter>. The optional third
- parameter, <parameter>temporary</parameter>, when set to true, specifies that
- the slot should not be permanently stored to disk and is only meant
- for use by the current session. Temporary slots are also
- released upon any error. The optional fourth parameter,
- <parameter>twophase</parameter>, when set to true, specifies
- that the decoding of prepared transactions is enabled for this
- slot. The optional fifth parameter,
- <parameter>failover</parameter>, when set to true,
- specifies that this slot is enabled to be synced to the
- standbys so that logical replication can be resumed after
- failover. A call to this function has the same effect as
- the replication protocol command
- <literal>CREATE_REPLICATION_SLOT ... LOGICAL</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_copy_physical_replication_slot</primary>
- </indexterm>
- <function>pg_copy_physical_replication_slot</function> ( <parameter>src_slot_name</parameter> <type>name</type>, <parameter>dst_slot_name</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type> </optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>slot_name</parameter> <type>name</type>,
- <parameter>lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Copies an existing physical replication slot named <parameter>src_slot_name</parameter>
- to a physical replication slot named <parameter>dst_slot_name</parameter>.
- The copied physical slot starts to reserve WAL from the same <acronym>LSN</acronym> as the
- source slot.
- <parameter>temporary</parameter> is optional. If <parameter>temporary</parameter>
- is omitted, the same value as the source slot is used.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_copy_logical_replication_slot</primary>
- </indexterm>
- <function>pg_copy_logical_replication_slot</function> ( <parameter>src_slot_name</parameter> <type>name</type>, <parameter>dst_slot_name</parameter> <type>name</type> <optional>, <parameter>temporary</parameter> <type>boolean</type> <optional>, <parameter>plugin</parameter> <type>name</type> </optional></optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>slot_name</parameter> <type>name</type>,
- <parameter>lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Copies an existing logical replication slot
- named <parameter>src_slot_name</parameter> to a logical replication
- slot named <parameter>dst_slot_name</parameter>, optionally changing
- the output plugin and persistence. The copied logical slot starts
- from the same <acronym>LSN</acronym> as the source logical slot. Both
- <parameter>temporary</parameter> and <parameter>plugin</parameter> are
- optional; if they are omitted, the values of the source slot are used.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-logical-slot-get-changes" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_logical_slot_get_changes</primary>
- </indexterm>
- <function>pg_logical_slot_get_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>xid</parameter> <type>xid</type>,
- <parameter>data</parameter> <type>text</type> )
- </para>
- <para>
- Returns changes in the slot <parameter>slot_name</parameter>, starting
- from the point from which changes have been consumed last. If
- <parameter>upto_lsn</parameter>
- and <parameter>upto_nchanges</parameter> are NULL,
- logical decoding will continue until end of WAL. If
- <parameter>upto_lsn</parameter> is non-NULL, decoding will include only
- those transactions which commit prior to the specified LSN. If
- <parameter>upto_nchanges</parameter> is non-NULL, decoding will
- stop when the number of rows produced by decoding exceeds
- the specified value. Note, however, that the actual number of
- rows returned may be larger, since this limit is only checked after
- adding the rows produced when decoding each new transaction commit.
- If the specified slot is a logical failover slot then the function will
- not return until all physical slots specified in
- <link linkend="guc-standby-slot-names"><varname>standby_slot_names</varname></link>
- have confirmed WAL receipt.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-logical-slot-peek-changes" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_logical_slot_peek_changes</primary>
- </indexterm>
- <function>pg_logical_slot_peek_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>xid</parameter> <type>xid</type>,
- <parameter>data</parameter> <type>text</type> )
- </para>
- <para>
- Behaves just like
- the <function>pg_logical_slot_get_changes()</function> function,
- except that changes are not consumed; that is, they will be returned
- again on future calls.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_logical_slot_get_binary_changes</primary>
- </indexterm>
- <function>pg_logical_slot_get_binary_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>xid</parameter> <type>xid</type>,
- <parameter>data</parameter> <type>bytea</type> )
- </para>
- <para>
- Behaves just like
- the <function>pg_logical_slot_get_changes()</function> function,
- except that changes are returned as <type>bytea</type>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_logical_slot_peek_binary_changes</primary>
- </indexterm>
- <function>pg_logical_slot_peek_binary_changes</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>integer</type>, <literal>VARIADIC</literal> <parameter>options</parameter> <type>text[]</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>lsn</parameter> <type>pg_lsn</type>,
- <parameter>xid</parameter> <type>xid</type>,
- <parameter>data</parameter> <type>bytea</type> )
- </para>
- <para>
- Behaves just like
- the <function>pg_logical_slot_peek_changes()</function> function,
- except that changes are returned as <type>bytea</type>.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-slot-advance" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_slot_advance</primary>
- </indexterm>
- <function>pg_replication_slot_advance</function> ( <parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type> )
- <returnvalue>record</returnvalue>
- ( <parameter>slot_name</parameter> <type>name</type>,
- <parameter>end_lsn</parameter> <type>pg_lsn</type> )
- </para>
- <para>
- Advances the current confirmed position of a replication slot named
- <parameter>slot_name</parameter>. The slot will not be moved backwards,
- and it will not be moved beyond the current insert location. Returns
- the name of the slot and the actual position that it was advanced to.
- The updated slot position information is written out at the next
- checkpoint if any advancing is done. So in the event of a crash, the
- slot may return to an earlier position. If the specified slot is a
- logical failover slot then the function will not return until all
- physical slots specified in
- <link linkend="guc-standby-slot-names"><varname>standby_slot_names</varname></link>
- have confirmed WAL receipt.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-create" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_create</primary>
- </indexterm>
- <function>pg_replication_origin_create</function> ( <parameter>node_name</parameter> <type>text</type> )
- <returnvalue>oid</returnvalue>
- </para>
- <para>
- Creates a replication origin with the given external
- name, and returns the internal ID assigned to it.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-drop" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_drop</primary>
- </indexterm>
- <function>pg_replication_origin_drop</function> ( <parameter>node_name</parameter> <type>text</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Deletes a previously-created replication origin, including any
- associated replay progress.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_oid</primary>
- </indexterm>
- <function>pg_replication_origin_oid</function> ( <parameter>node_name</parameter> <type>text</type> )
- <returnvalue>oid</returnvalue>
- </para>
- <para>
- Looks up a replication origin by name and returns the internal ID. If
- no such replication origin is found, <literal>NULL</literal> is
- returned.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-session-setup" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_session_setup</primary>
- </indexterm>
- <function>pg_replication_origin_session_setup</function> ( <parameter>node_name</parameter> <type>text</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Marks the current session as replaying from the given
- origin, allowing replay progress to be tracked.
- Can only be used if no origin is currently selected.
- Use <function>pg_replication_origin_session_reset</function> to undo.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_session_reset</primary>
- </indexterm>
- <function>pg_replication_origin_session_reset</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Cancels the effects
- of <function>pg_replication_origin_session_setup()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_session_is_setup</primary>
- </indexterm>
- <function>pg_replication_origin_session_is_setup</function> ()
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Returns true if a replication origin has been selected in the
- current session.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-session-progress" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_session_progress</primary>
- </indexterm>
- <function>pg_replication_origin_session_progress</function> ( <parameter>flush</parameter> <type>boolean</type> )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the replay location for the replication origin selected in
- the current session. The parameter <parameter>flush</parameter>
- determines whether the corresponding local transaction will be
- guaranteed to have been flushed to disk or not.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-xact-setup" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_xact_setup</primary>
- </indexterm>
- <function>pg_replication_origin_xact_setup</function> ( <parameter>origin_lsn</parameter> <type>pg_lsn</type>, <parameter>origin_timestamp</parameter> <type>timestamp with time zone</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Marks the current transaction as replaying a transaction that has
- committed at the given <acronym>LSN</acronym> and timestamp. Can
- only be called when a replication origin has been selected
- using <function>pg_replication_origin_session_setup</function>.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-xact-reset" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_xact_reset</primary>
- </indexterm>
- <function>pg_replication_origin_xact_reset</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Cancels the effects of
- <function>pg_replication_origin_xact_setup()</function>.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-advance" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_advance</primary>
- </indexterm>
- <function>pg_replication_origin_advance</function> ( <parameter>node_name</parameter> <type>text</type>, <parameter>lsn</parameter> <type>pg_lsn</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Sets replication progress for the given node to the given
- location. This is primarily useful for setting up the initial
- location, or setting a new location after configuration changes and
- similar. Be aware that careless use of this function can lead to
- inconsistently replicated data.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-replication-origin-progress" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_replication_origin_progress</primary>
- </indexterm>
- <function>pg_replication_origin_progress</function> ( <parameter>node_name</parameter> <type>text</type>, <parameter>flush</parameter> <type>boolean</type> )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Returns the replay location for the given replication origin. The
- parameter <parameter>flush</parameter> determines whether the
- corresponding local transaction will be guaranteed to have been
- flushed to disk or not.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-logical-emit-message" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_logical_emit_message</primary>
- </indexterm>
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
- <returnvalue>pg_lsn</returnvalue>
- </para>
- <para>
- Emits a logical decoding message. This can be used to pass generic
- messages to logical decoding plugins through
- WAL. The <parameter>transactional</parameter> parameter specifies if
- the message should be part of the current transaction, or if it should
- be written immediately and decoded as soon as the logical decoder
- reads the record. The <parameter>prefix</parameter> parameter is a
- textual prefix that can be used by logical decoding plugins to easily
- recognize messages that are interesting for them.
- The <parameter>content</parameter> parameter is the content of the
- message, given either in text or binary form.
- The <parameter>flush</parameter> parameter (default set to
- <literal>false</literal>) controls if the message is immediately
- flushed to WAL or not. <parameter>flush</parameter> has no effect
- with <parameter>transactional</parameter>, as the message's WAL
- record is flushed along with its transaction.
- </para></entry>
- </row>
-
- <row>
- <entry id="pg-sync-replication-slots" role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_sync_replication_slots</primary>
- </indexterm>
- <function>pg_sync_replication_slots</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Synchronize the logical failover replication slots from the primary
- server to the standby server. This function can only be executed on the
- standby server. Temporary synced slots, if any, cannot be used for
- logical decoding and must be dropped after promotion. See
- <xref linkend="logicaldecoding-replication-slots-synchronization"/> for details.
- Note that this function cannot be executed if
- <link linkend="guc-sync-replication-slots"><varname>
- sync_replication_slots</varname></link> is enabled and the slotsync
- worker is already running to perform the synchronization of slots.
- </para>
-
- <caution>
- <para>
- If, after executing the function,
- <link linkend="guc-hot-standby-feedback">
- <varname>hot_standby_feedback</varname></link> is disabled on
- the standby or the physical slot configured in
- <link linkend="guc-primary-slot-name">
- <varname>primary_slot_name</varname></link> is
- removed, then it is possible that the necessary rows of the
- synchronized slot will be removed by the VACUUM process on the primary
- server, resulting in the synchronized slot becoming invalidated.
- </para>
- </caution>
- </entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-admin-dbobject">
- <title>Database Object Management Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-admin-dbsize"/> calculate
- the disk space usage of database objects, or assist in presentation
- or understanding of usage results. <literal>bigint</literal> results
- are measured in bytes. If an OID that does
- not represent an existing object is passed to one of these
- functions, <literal>NULL</literal> is returned.
- </para>
-
- <table id="functions-admin-dbsize">
- <title>Database Object Size Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_column_size</primary>
- </indexterm>
- <function>pg_column_size</function> ( <type>"any"</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Shows the number of bytes used to store any individual data value. If
- applied directly to a table column value, this reflects any
- compression that was done.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_column_compression</primary>
- </indexterm>
- <function>pg_column_compression</function> ( <type>"any"</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Shows the compression algorithm that was used to compress
- an individual variable-length value. Returns <literal>NULL</literal>
- if the value is not compressed.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_column_toast_chunk_id</primary>
- </indexterm>
- <function>pg_column_toast_chunk_id</function> ( <type>"any"</type> )
- <returnvalue>oid</returnvalue>
- </para>
- <para>
- Shows the <structfield>chunk_id</structfield> of an on-disk
- <acronym>TOAST</acronym>ed value. Returns <literal>NULL</literal>
- if the value is un-<acronym>TOAST</acronym>ed or not on-disk. See
- <xref linkend="storage-toast"/> for more information about
- <acronym>TOAST</acronym>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_database_size</primary>
- </indexterm>
- <function>pg_database_size</function> ( <type>name</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_database_size</function> ( <type>oid</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the total disk space used by the database with the specified
- name or OID. To use this function, you must
- have <literal>CONNECT</literal> privilege on the specified database
- (which is granted by default) or have privileges of
- the <literal>pg_read_all_stats</literal> role.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_indexes_size</primary>
- </indexterm>
- <function>pg_indexes_size</function> ( <type>regclass</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the total disk space used by indexes attached to the
- specified table.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_relation_size</primary>
- </indexterm>
- <function>pg_relation_size</function> ( <parameter>relation</parameter> <type>regclass</type> <optional>, <parameter>fork</parameter> <type>text</type> </optional> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the disk space used by one <quote>fork</quote> of the
- specified relation. (Note that for most purposes it is more
- convenient to use the higher-level
- functions <function>pg_total_relation_size</function>
- or <function>pg_table_size</function>, which sum the sizes of all
- forks.) With one argument, this returns the size of the main data
- fork of the relation. The second argument can be provided to specify
- which fork to examine:
- <itemizedlist spacing="compact">
- <listitem>
- <para>
- <literal>main</literal> returns the size of the main
- data fork of the relation.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>fsm</literal> returns the size of the Free Space Map
- (see <xref linkend="storage-fsm"/>) associated with the relation.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>vm</literal> returns the size of the Visibility Map
- (see <xref linkend="storage-vm"/>) associated with the relation.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>init</literal> returns the size of the initialization
- fork, if any, associated with the relation.
- </para>
- </listitem>
- </itemizedlist>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_size_bytes</primary>
- </indexterm>
- <function>pg_size_bytes</function> ( <type>text</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Converts a size in human-readable format (as returned
- by <function>pg_size_pretty</function>) into bytes. Valid units are
- <literal>bytes</literal>, <literal>B</literal>, <literal>kB</literal>,
- <literal>MB</literal>, <literal>GB</literal>, <literal>TB</literal>,
- and <literal>PB</literal>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_size_pretty</primary>
- </indexterm>
- <function>pg_size_pretty</function> ( <type>bigint</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_size_pretty</function> ( <type>numeric</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Converts a size in bytes into a more easily human-readable format with
- size units (bytes, kB, MB, GB, TB, or PB as appropriate). Note that the
- units are powers of 2 rather than powers of 10, so 1kB is 1024 bytes,
- 1MB is 1024<superscript>2</superscript> = 1048576 bytes, and so on.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_table_size</primary>
- </indexterm>
- <function>pg_table_size</function> ( <type>regclass</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the disk space used by the specified table, excluding indexes
- (but including its TOAST table if any, free space map, and visibility
- map).
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_tablespace_size</primary>
- </indexterm>
- <function>pg_tablespace_size</function> ( <type>name</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_tablespace_size</function> ( <type>oid</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the total disk space used in the tablespace with the
- specified name or OID. To use this function, you must
- have <literal>CREATE</literal> privilege on the specified tablespace
- or have privileges of the <literal>pg_read_all_stats</literal> role,
- unless it is the default tablespace for the current database.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_total_relation_size</primary>
- </indexterm>
- <function>pg_total_relation_size</function> ( <type>regclass</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Computes the total disk space used by the specified table, including
- all indexes and <acronym>TOAST</acronym> data. The result is
- equivalent to <function>pg_table_size</function>
- <literal>+</literal> <function>pg_indexes_size</function>.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The functions above that operate on tables or indexes accept a
- <type>regclass</type> argument, which is simply the OID of the table or index
- in the <structname>pg_class</structname> system catalog. You do not have to look up
- the OID by hand, however, since the <type>regclass</type> data type's input
- converter will do the work for you. See <xref linkend="datatype-oid"/>
- for details.
- </para>
-
- <para>
- The functions shown in <xref linkend="functions-admin-dblocation"/> assist
- in identifying the specific disk files associated with database objects.
- </para>
-
- <table id="functions-admin-dblocation">
- <title>Database Object Location Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_relation_filenode</primary>
- </indexterm>
- <function>pg_relation_filenode</function> ( <parameter>relation</parameter> <type>regclass</type> )
- <returnvalue>oid</returnvalue>
- </para>
- <para>
- Returns the <quote>filenode</quote> number currently assigned to the
- specified relation. The filenode is the base component of the file
- name(s) used for the relation (see
- <xref linkend="storage-file-layout"/> for more information).
- For most relations the result is the same as
- <structname>pg_class</structname>.<structfield>relfilenode</structfield>,
- but for certain system catalogs <structfield>relfilenode</structfield>
- is zero and this function must be used to get the correct value. The
- function returns NULL if passed a relation that does not have storage,
- such as a view.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_relation_filepath</primary>
- </indexterm>
- <function>pg_relation_filepath</function> ( <parameter>relation</parameter> <type>regclass</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the entire file path name (relative to the database cluster's
- data directory, <varname>PGDATA</varname>) of the relation.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_filenode_relation</primary>
- </indexterm>
- <function>pg_filenode_relation</function> ( <parameter>tablespace</parameter> <type>oid</type>, <parameter>filenode</parameter> <type>oid</type> )
- <returnvalue>regclass</returnvalue>
- </para>
- <para>
- Returns a relation's OID given the tablespace OID and filenode it is
- stored under. This is essentially the inverse mapping of
- <function>pg_relation_filepath</function>. For a relation in the
- database's default tablespace, the tablespace can be specified as zero.
- Returns <literal>NULL</literal> if no relation in the current database
- is associated with the given values.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-admin-collation"/> lists functions used to manage
- collations.
- </para>
-
- <table id="functions-admin-collation">
- <title>Collation Management Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_collation_actual_version</primary>
- </indexterm>
- <function>pg_collation_actual_version</function> ( <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the actual version of the collation object as it is currently
- installed in the operating system. If this is different from the
- value in
- <structname>pg_collation</structname>.<structfield>collversion</structfield>,
- then objects depending on the collation might need to be rebuilt. See
- also <xref linkend="sql-altercollation"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_database_collation_actual_version</primary>
- </indexterm>
- <function>pg_database_collation_actual_version</function> ( <type>oid</type> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns the actual version of the database's collation as it is currently
- installed in the operating system. If this is different from the
- value in
- <structname>pg_database</structname>.<structfield>datcollversion</structfield>,
- then objects depending on the collation might need to be rebuilt. See
- also <xref linkend="sql-alterdatabase"/>.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_import_system_collations</primary>
- </indexterm>
- <function>pg_import_system_collations</function> ( <parameter>schema</parameter> <type>regnamespace</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Adds collations to the system
- catalog <structname>pg_collation</structname> based on all the locales
- it finds in the operating system. This is
- what <command>initdb</command> uses; see
- <xref linkend="collation-managing"/> for more details. If additional
- locales are installed into the operating system later on, this
- function can be run again to add collations for the new locales.
- Locales that match existing entries
- in <structname>pg_collation</structname> will be skipped. (But
- collation objects based on locales that are no longer present in the
- operating system are not removed by this function.)
- The <parameter>schema</parameter> parameter would typically
- be <literal>pg_catalog</literal>, but that is not a requirement; the
- collations could be installed into some other schema as well. The
- function returns the number of new collation objects it created.
- Use of this function is restricted to superusers.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <xref linkend="functions-info-partition"/> lists functions that provide
- information about the structure of partitioned tables.
- </para>
-
- <table id="functions-info-partition">
- <title>Partitioning Information Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_partition_tree</primary>
- </indexterm>
- <function>pg_partition_tree</function> ( <type>regclass</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>relid</parameter> <type>regclass</type>,
- <parameter>parentrelid</parameter> <type>regclass</type>,
- <parameter>isleaf</parameter> <type>boolean</type>,
- <parameter>level</parameter> <type>integer</type> )
- </para>
- <para>
- Lists the tables or indexes in the partition tree of the
- given partitioned table or partitioned index, with one row for each
- partition. Information provided includes the OID of the partition,
- the OID of its immediate parent, a boolean value telling if the
- partition is a leaf, and an integer telling its level in the hierarchy.
- The level value is 0 for the input table or index, 1 for its
- immediate child partitions, 2 for their partitions, and so on.
- Returns no rows if the relation does not exist or is not a partition
- or partitioned table.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_partition_ancestors</primary>
- </indexterm>
- <function>pg_partition_ancestors</function> ( <type>regclass</type> )
- <returnvalue>setof regclass</returnvalue>
- </para>
- <para>
- Lists the ancestor relations of the given partition,
- including the relation itself. Returns no rows if the relation
- does not exist or is not a partition or partitioned table.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_partition_root</primary>
- </indexterm>
- <function>pg_partition_root</function> ( <type>regclass</type> )
- <returnvalue>regclass</returnvalue>
- </para>
- <para>
- Returns the top-most parent of the partition tree to which the given
- relation belongs. Returns <literal>NULL</literal> if the relation
- does not exist or is not a partition or partitioned table.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- For example, to check the total size of the data contained in a
- partitioned table <structname>measurement</structname>, one could use the
- following query:
-<programlisting>
-SELECT pg_size_pretty(sum(pg_relation_size(relid))) AS total_size
- FROM pg_partition_tree('measurement');
-</programlisting>
- </para>
-
- </sect2>
-
- <sect2 id="functions-admin-index">
- <title>Index Maintenance Functions</title>
-
- <para>
- <xref linkend="functions-admin-index-table"/> shows the functions
- available for index maintenance tasks. (Note that these maintenance
- tasks are normally done automatically by autovacuum; use of these
- functions is only required in special cases.)
- These functions cannot be executed during recovery.
- Use of these functions is restricted to superusers and the owner
- of the given index.
- </para>
-
- <table id="functions-admin-index-table">
- <title>Index Maintenance Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>brin_summarize_new_values</primary>
- </indexterm>
- <function>brin_summarize_new_values</function> ( <parameter>index</parameter> <type>regclass</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Scans the specified BRIN index to find page ranges in the base table
- that are not currently summarized by the index; for any such range it
- creates a new summary index tuple by scanning those table pages.
- Returns the number of new page range summaries that were inserted
- into the index.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>brin_summarize_range</primary>
- </indexterm>
- <function>brin_summarize_range</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>blockNumber</parameter> <type>bigint</type> )
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Summarizes the page range covering the given block, if not already
- summarized. This is
- like <function>brin_summarize_new_values</function> except that it
- only processes the page range that covers the given table block number.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>brin_desummarize_range</primary>
- </indexterm>
- <function>brin_desummarize_range</function> ( <parameter>index</parameter> <type>regclass</type>, <parameter>blockNumber</parameter> <type>bigint</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Removes the BRIN index tuple that summarizes the page range covering
- the given table block, if there is one.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>gin_clean_pending_list</primary>
- </indexterm>
- <function>gin_clean_pending_list</function> ( <parameter>index</parameter> <type>regclass</type> )
- <returnvalue>bigint</returnvalue>
- </para>
- <para>
- Cleans up the <quote>pending</quote> list of the specified GIN index
- by moving entries in it, in bulk, to the main GIN data structure.
- Returns the number of pages removed from the pending list.
- If the argument is a GIN index built with
- the <literal>fastupdate</literal> option disabled, no cleanup happens
- and the result is zero, because the index doesn't have a pending list.
- See <xref linkend="gin-fast-update"/> and <xref linkend="gin-tips"/>
- for details about the pending list and <literal>fastupdate</literal>
- option.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-admin-genfile">
- <title>Generic File Access Functions</title>
-
- <para>
- The functions shown in <xref
- linkend="functions-admin-genfile-table"/> provide native access to
- files on the machine hosting the server. Only files within the
- database cluster directory and the <varname>log_directory</varname> can be
- accessed, unless the user is a superuser or is granted the role
- <literal>pg_read_server_files</literal>. Use a relative path for files in
- the cluster directory, and a path matching the <varname>log_directory</varname>
- configuration setting for log files.
- </para>
-
- <para>
- Note that granting users the EXECUTE privilege on
- <function>pg_read_file()</function>, or related functions, allows them the
- ability to read any file on the server that the database server process can
- read; these functions bypass all in-database privilege checks. This means
- that, for example, a user with such access is able to read the contents of
- the <structname>pg_authid</structname> table where authentication
- information is stored, as well as read any table data in the database.
- Therefore, granting access to these functions should be carefully
- considered.
- </para>
-
- <para>
- When granting privilege on these functions, note that the table entries
- showing optional parameters are mostly implemented as several physical
- functions with different parameter lists. Privilege must be granted
- separately on each such function, if it is to be
- used. <application>psql</application>'s <command>\df</command> command
- can be useful to check what the actual function signatures are.
- </para>
-
- <para>
- Some of these functions take an optional <parameter>missing_ok</parameter>
- parameter, which specifies the behavior when the file or directory does
- not exist. If <literal>true</literal>, the function
- returns <literal>NULL</literal> or an empty result set, as appropriate.
- If <literal>false</literal>, an error is raised. (Failure conditions
- other than <quote>file not found</quote> are reported as errors in any
- case.) The default is <literal>false</literal>.
- </para>
-
- <table id="functions-admin-genfile-table">
- <title>Generic File Access Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_dir</primary>
- </indexterm>
- <function>pg_ls_dir</function> ( <parameter>dirname</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type>, <parameter>include_dot_dirs</parameter> <type>boolean</type> </optional> )
- <returnvalue>setof text</returnvalue>
- </para>
- <para>
- Returns the names of all files (and directories and other special
- files) in the specified
- directory. The <parameter>include_dot_dirs</parameter> parameter
- indicates whether <quote>.</quote> and <quote>..</quote> are to be
- included in the result set; the default is to exclude them. Including
- them can be useful when <parameter>missing_ok</parameter>
- is <literal>true</literal>, to distinguish an empty directory from a
- non-existent directory.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_logdir</primary>
- </indexterm>
- <function>pg_ls_logdir</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's log directory. Filenames beginning with
- a dot, directories, and other special files are excluded.
- </para>
- <para>
- This function is restricted to superusers and roles with privileges of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_waldir</primary>
- </indexterm>
- <function>pg_ls_waldir</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's write-ahead log (WAL) directory.
- Filenames beginning with a dot, directories, and other special files
- are excluded.
- </para>
- <para>
- This function is restricted to superusers and roles with privileges of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_logicalmapdir</primary>
- </indexterm>
- <function>pg_ls_logicalmapdir</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's <filename>pg_logical/mappings</filename>
- directory. Filenames beginning with a dot, directories, and other
- special files are excluded.
- </para>
- <para>
- This function is restricted to superusers and members of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_logicalsnapdir</primary>
- </indexterm>
- <function>pg_ls_logicalsnapdir</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's <filename>pg_logical/snapshots</filename>
- directory. Filenames beginning with a dot, directories, and other
- special files are excluded.
- </para>
- <para>
- This function is restricted to superusers and members of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_replslotdir</primary>
- </indexterm>
- <function>pg_ls_replslotdir</function> ( <parameter>slot_name</parameter> <type>text</type> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's <filename>pg_replslot/slot_name</filename>
- directory, where <parameter>slot_name</parameter> is the name of the
- replication slot provided as input of the function. Filenames beginning
- with a dot, directories, and other special files are excluded.
- </para>
- <para>
- This function is restricted to superusers and members of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_ls_archive_statusdir</primary>
- </indexterm>
- <function>pg_ls_archive_statusdir</function> ()
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the server's WAL archive status directory
- (<filename>pg_wal/archive_status</filename>). Filenames beginning
- with a dot, directories, and other special files are excluded.
- </para>
- <para>
- This function is restricted to superusers and members of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
-
- <indexterm>
- <primary>pg_ls_tmpdir</primary>
- </indexterm>
- <function>pg_ls_tmpdir</function> ( <optional> <parameter>tablespace</parameter> <type>oid</type> </optional> )
- <returnvalue>setof record</returnvalue>
- ( <parameter>name</parameter> <type>text</type>,
- <parameter>size</parameter> <type>bigint</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type> )
- </para>
- <para>
- Returns the name, size, and last modification time (mtime) of each
- ordinary file in the temporary file directory for the
- specified <parameter>tablespace</parameter>.
- If <parameter>tablespace</parameter> is not provided,
- the <literal>pg_default</literal> tablespace is examined. Filenames
- beginning with a dot, directories, and other special files are
- excluded.
- </para>
- <para>
- This function is restricted to superusers and members of
- the <literal>pg_monitor</literal> role by default, but other users can
- be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_read_file</primary>
- </indexterm>
- <function>pg_read_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>offset</parameter> <type>bigint</type>, <parameter>length</parameter> <type>bigint</type> </optional> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Returns all or part of a text file, starting at the
- given byte <parameter>offset</parameter>, returning at
- most <parameter>length</parameter> bytes (less if the end of file is
- reached first). If <parameter>offset</parameter> is negative, it is
- relative to the end of the file. If <parameter>offset</parameter>
- and <parameter>length</parameter> are omitted, the entire file is
- returned. The bytes read from the file are interpreted as a string in
- the database's encoding; an error is thrown if they are not valid in
- that encoding.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_read_binary_file</primary>
- </indexterm>
- <function>pg_read_binary_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>offset</parameter> <type>bigint</type>, <parameter>length</parameter> <type>bigint</type> </optional> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
- <returnvalue>bytea</returnvalue>
- </para>
- <para>
- Returns all or part of a file. This function is identical to
- <function>pg_read_file</function> except that it can read arbitrary
- binary data, returning the result as <type>bytea</type>
- not <type>text</type>; accordingly, no encoding checks are performed.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para>
- <para>
- In combination with the <function>convert_from</function> function,
- this function can be used to read a text file in a specified encoding
- and convert to the database's encoding:
-<programlisting>
-SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
-</programlisting>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_stat_file</primary>
- </indexterm>
- <function>pg_stat_file</function> ( <parameter>filename</parameter> <type>text</type> <optional>, <parameter>missing_ok</parameter> <type>boolean</type> </optional> )
- <returnvalue>record</returnvalue>
- ( <parameter>size</parameter> <type>bigint</type>,
- <parameter>access</parameter> <type>timestamp with time zone</type>,
- <parameter>modification</parameter> <type>timestamp with time zone</type>,
- <parameter>change</parameter> <type>timestamp with time zone</type>,
- <parameter>creation</parameter> <type>timestamp with time zone</type>,
- <parameter>isdir</parameter> <type>boolean</type> )
- </para>
- <para>
- Returns a record containing the file's size, last access time stamp,
- last modification time stamp, last file status change time stamp (Unix
- platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
- </para>
- <para>
- This function is restricted to superusers by default, but other users
- can be granted EXECUTE to run the function.
- </para></entry>
- </row>
-
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- <sect2 id="functions-advisory-locks">
- <title>Advisory Lock Functions</title>
-
- <para>
- The functions shown in <xref linkend="functions-advisory-locks-table"/>
- manage advisory locks. For details about proper use of these functions,
- see <xref linkend="advisory-locks"/>.
- </para>
-
- <para>
- All these functions are intended to be used to lock application-defined
- resources, which can be identified either by a single 64-bit key value or
- two 32-bit key values (note that these two key spaces do not overlap).
- If another session already holds a conflicting lock on the same resource
- identifier, the functions will either wait until the resource becomes
- available, or return a <literal>false</literal> result, as appropriate for
- the function.
- Locks can be either shared or exclusive: a shared lock does not conflict
- with other shared locks on the same resource, only with exclusive locks.
- Locks can be taken at session level (so that they are held until released
- or the session ends) or at transaction level (so that they are held until
- the current transaction ends; there is no provision for manual release).
- Multiple session-level lock requests stack, so that if the same resource
- identifier is locked three times there must then be three unlock requests
- to release the resource in advance of session end.
- </para>
-
- <table id="functions-advisory-locks-table">
- <title>Advisory Lock Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_lock</primary>
- </indexterm>
- <function>pg_advisory_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Obtains an exclusive session-level advisory lock, waiting if necessary.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_lock_shared</primary>
- </indexterm>
- <function>pg_advisory_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Obtains a shared session-level advisory lock, waiting if necessary.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_unlock</primary>
- </indexterm>
- <function>pg_advisory_unlock</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_unlock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Releases a previously-acquired exclusive session-level advisory lock.
- Returns <literal>true</literal> if the lock is successfully released.
- If the lock was not held, <literal>false</literal> is returned, and in
- addition, an SQL warning will be reported by the server.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_unlock_all</primary>
- </indexterm>
- <function>pg_advisory_unlock_all</function> ()
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Releases all session-level advisory locks held by the current session.
- (This function is implicitly invoked at session end, even if the
- client disconnects ungracefully.)
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_unlock_shared</primary>
- </indexterm>
- <function>pg_advisory_unlock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_unlock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Releases a previously-acquired shared session-level advisory lock.
- Returns <literal>true</literal> if the lock is successfully released.
- If the lock was not held, <literal>false</literal> is returned, and in
- addition, an SQL warning will be reported by the server.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_xact_lock</primary>
- </indexterm>
- <function>pg_advisory_xact_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_xact_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Obtains an exclusive transaction-level advisory lock, waiting if
- necessary.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_advisory_xact_lock_shared</primary>
- </indexterm>
- <function>pg_advisory_xact_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_advisory_xact_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>void</returnvalue>
- </para>
- <para>
- Obtains a shared transaction-level advisory lock, waiting if
- necessary.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_try_advisory_lock</primary>
- </indexterm>
- <function>pg_try_advisory_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_try_advisory_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Obtains an exclusive session-level advisory lock if available.
- This will either obtain the lock immediately and
- return <literal>true</literal>, or return <literal>false</literal>
- without waiting if the lock cannot be acquired immediately.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_try_advisory_lock_shared</primary>
- </indexterm>
- <function>pg_try_advisory_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_try_advisory_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Obtains a shared session-level advisory lock if available.
- This will either obtain the lock immediately and
- return <literal>true</literal>, or return <literal>false</literal>
- without waiting if the lock cannot be acquired immediately.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_try_advisory_xact_lock</primary>
- </indexterm>
- <function>pg_try_advisory_xact_lock</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_try_advisory_xact_lock</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Obtains an exclusive transaction-level advisory lock if available.
- This will either obtain the lock immediately and
- return <literal>true</literal>, or return <literal>false</literal>
- without waiting if the lock cannot be acquired immediately.
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>pg_try_advisory_xact_lock_shared</primary>
- </indexterm>
- <function>pg_try_advisory_xact_lock_shared</function> ( <parameter>key</parameter> <type>bigint</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para role="func_signature">
- <function>pg_try_advisory_xact_lock_shared</function> ( <parameter>key1</parameter> <type>integer</type>, <parameter>key2</parameter> <type>integer</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Obtains a shared transaction-level advisory lock if available.
- This will either obtain the lock immediately and
- return <literal>true</literal>, or return <literal>false</literal>
- without waiting if the lock cannot be acquired immediately.
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- </sect2>
-
- </sect1>
+&func-admin;
<sect1 id="functions-trigger">
<title>Trigger Functions</title>
--
2.34.1
v1-0003-split-functions-datetime-sect1-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0003-split-functions-datetime-sect1-from-func.sgml.patchDownload
From a0239d2b4a117319cbbe9b3551ac6db632300837 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 14:47:57 +0800
Subject: [PATCH v1 3/7] split "functions-datetime" sect1 from func.sgml
"functions-datetime" live in new file: doc/src/sgml/func-datetime.sgml,
it will hold doc/src/sgml/html/functions-datetime.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-datetime.sgml | 2184 ++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 2187 +------------------------------
3 files changed, 2186 insertions(+), 2186 deletions(-)
create mode 100644 doc/src/sgml/func-datetime.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 13bc4be5..1b6dc08e 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -20,6 +20,7 @@
<!ENTITY func SYSTEM "func.sgml">
<!ENTITY func-string SYSTEM "func-string.sgml">
<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-datetime.sgml b/doc/src/sgml/func-datetime.sgml
new file mode 100644
index 00000000..0410d854
--- /dev/null
+++ b/doc/src/sgml/func-datetime.sgml
@@ -0,0 +1,2184 @@
+ <sect1 id="functions-datetime">
+ <title>Date/Time Functions and Operators</title>
+
+ <para>
+ <xref linkend="functions-datetime-table"/> shows the available
+ functions for date/time value processing, with details appearing in
+ the following subsections. <xref
+ linkend="operators-datetime-table"/> illustrates the behaviors of
+ the basic arithmetic operators (<literal>+</literal>,
+ <literal>*</literal>, etc.). For formatting functions, refer to
+ <xref linkend="functions-formatting"/>. You should be familiar with
+ the background information on date/time data types from <xref
+ linkend="datatype-datetime"/>.
+ </para>
+
+ <para>
+ In addition, the usual comparison operators shown in
+ <xref linkend="functions-comparison-op-table"/> are available for the
+ date/time types. Dates and timestamps (with or without time zone) are
+ all comparable, while times (with or without time zone) and intervals
+ can only be compared to other values of the same data type. When
+ comparing a timestamp without time zone to a timestamp with time zone,
+ the former value is assumed to be given in the time zone specified by
+ the <xref linkend="guc-timezone"/> configuration parameter, and is
+ rotated to UTC for comparison to the latter value (which is already
+ in UTC internally). Similarly, a date value is assumed to represent
+ midnight in the <varname>TimeZone</varname> zone when comparing it
+ to a timestamp.
+ </para>
+
+ <para>
+ All the functions and operators described below that take <type>time</type> or <type>timestamp</type>
+ inputs actually come in two variants: one that takes <type>time with time zone</type> or <type>timestamp
+ with time zone</type>, and one that takes <type>time without time zone</type> or <type>timestamp without time zone</type>.
+ For brevity, these variants are not shown separately. Also, the
+ <literal>+</literal> and <literal>*</literal> operators come in commutative pairs (for
+ example both <type>date</type> <literal>+</literal> <type>integer</type>
+ and <type>integer</type> <literal>+</literal> <type>date</type>); we show
+ only one of each such pair.
+ </para>
+
+ <table id="operators-datetime-table">
+ <title>Date/Time Operators</title>
+
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>+</literal> <type>integer</type>
+ <returnvalue>date</returnvalue>
+ </para>
+ <para>
+ Add a number of days to a date
+ </para>
+ <para>
+ <literal>date '2001-09-28' + 7</literal>
+ <returnvalue>2001-10-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>+</literal> <type>interval</type>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Add an interval to a date
+ </para>
+ <para>
+ <literal>date '2001-09-28' + interval '1 hour'</literal>
+ <returnvalue>2001-09-28 01:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>+</literal> <type>time</type>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Add a time-of-day to a date
+ </para>
+ <para>
+ <literal>date '2001-09-28' + time '03:00'</literal>
+ <returnvalue>2001-09-28 03:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>interval</type> <literal>+</literal> <type>interval</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Add intervals
+ </para>
+ <para>
+ <literal>interval '1 day' + interval '1 hour'</literal>
+ <returnvalue>1 day 01:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp</type> <literal>+</literal> <type>interval</type>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Add an interval to a timestamp
+ </para>
+ <para>
+ <literal>timestamp '2001-09-28 01:00' + interval '23 hours'</literal>
+ <returnvalue>2001-09-29 00:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>time</type> <literal>+</literal> <type>interval</type>
+ <returnvalue>time</returnvalue>
+ </para>
+ <para>
+ Add an interval to a time
+ </para>
+ <para>
+ <literal>time '01:00' + interval '3 hours'</literal>
+ <returnvalue>04:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <literal>-</literal> <type>interval</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Negate an interval
+ </para>
+ <para>
+ <literal>- interval '23 hours'</literal>
+ <returnvalue>-23:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>-</literal> <type>date</type>
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Subtract dates, producing the number of days elapsed
+ </para>
+ <para>
+ <literal>date '2001-10-01' - date '2001-09-28'</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>-</literal> <type>integer</type>
+ <returnvalue>date</returnvalue>
+ </para>
+ <para>
+ Subtract a number of days from a date
+ </para>
+ <para>
+ <literal>date '2001-10-01' - 7</literal>
+ <returnvalue>2001-09-24</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>date</type> <literal>-</literal> <type>interval</type>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Subtract an interval from a date
+ </para>
+ <para>
+ <literal>date '2001-09-28' - interval '1 hour'</literal>
+ <returnvalue>2001-09-27 23:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>time</type> <literal>-</literal> <type>time</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Subtract times
+ </para>
+ <para>
+ <literal>time '05:00' - time '03:00'</literal>
+ <returnvalue>02:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>time</type> <literal>-</literal> <type>interval</type>
+ <returnvalue>time</returnvalue>
+ </para>
+ <para>
+ Subtract an interval from a time
+ </para>
+ <para>
+ <literal>time '05:00' - interval '2 hours'</literal>
+ <returnvalue>03:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp</type> <literal>-</literal> <type>interval</type>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Subtract an interval from a timestamp
+ </para>
+ <para>
+ <literal>timestamp '2001-09-28 23:00' - interval '23 hours'</literal>
+ <returnvalue>2001-09-28 00:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>interval</type> <literal>-</literal> <type>interval</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Subtract intervals
+ </para>
+ <para>
+ <literal>interval '1 day' - interval '1 hour'</literal>
+ <returnvalue>1 day -01:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp</type> <literal>-</literal> <type>timestamp</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Subtract timestamps (converting 24-hour intervals into days,
+ similarly to <link
+ linkend="function-justify-hours"><function>justify_hours()</function></link>)
+ </para>
+ <para>
+ <literal>timestamp '2001-09-29 03:00' - timestamp '2001-07-27 12:00'</literal>
+ <returnvalue>63 days 15:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>interval</type> <literal>*</literal> <type>double precision</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Multiply an interval by a scalar
+ </para>
+ <para>
+ <literal>interval '1 second' * 900</literal>
+ <returnvalue>00:15:00</returnvalue>
+ </para>
+ <para>
+ <literal>interval '1 day' * 21</literal>
+ <returnvalue>21 days</returnvalue>
+ </para>
+ <para>
+ <literal>interval '1 hour' * 3.5</literal>
+ <returnvalue>03:30:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>interval</type> <literal>/</literal> <type>double precision</type>
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Divide an interval by a scalar
+ </para>
+ <para>
+ <literal>interval '1 hour' / 1.5</literal>
+ <returnvalue>00:40:00</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="functions-datetime-table">
+ <title>Date/Time Functions</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Function
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>age</primary>
+ </indexterm>
+ <function>age</function> ( <type>timestamp</type>, <type>timestamp</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Subtract arguments, producing a <quote>symbolic</quote> result that
+ uses years and months, rather than just days
+ </para>
+ <para>
+ <literal>age(timestamp '2001-04-10', timestamp '1957-06-13')</literal>
+ <returnvalue>43 years 9 mons 27 days</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>age</function> ( <type>timestamp</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Subtract argument from <function>current_date</function> (at midnight)
+ </para>
+ <para>
+ <literal>age(timestamp '1957-06-13')</literal>
+ <returnvalue>62 years 6 mons 10 days</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>clock_timestamp</primary>
+ </indexterm>
+ <function>clock_timestamp</function> ( )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (changes during statement execution);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>clock_timestamp()</literal>
+ <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_date</primary>
+ </indexterm>
+ <function>current_date</function>
+ <returnvalue>date</returnvalue>
+ </para>
+ <para>
+ Current date; see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>current_date</literal>
+ <returnvalue>2019-12-23</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_time</primary>
+ </indexterm>
+ <function>current_time</function>
+ <returnvalue>time with time zone</returnvalue>
+ </para>
+ <para>
+ Current time of day; see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>current_time</literal>
+ <returnvalue>14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>current_time</function> ( <type>integer</type> )
+ <returnvalue>time with time zone</returnvalue>
+ </para>
+ <para>
+ Current time of day, with limited precision;
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>current_time(2)</literal>
+ <returnvalue>14:39:53.66-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>current_timestamp</primary>
+ </indexterm>
+ <function>current_timestamp</function>
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current transaction);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>current_timestamp</literal>
+ <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>current_timestamp</function> ( <type>integer</type> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current transaction), with limited precision;
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>current_timestamp(0)</literal>
+ <returnvalue>2019-12-23 14:39:53-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>date_add</primary>
+ </indexterm>
+ <function>date_add</function> ( <type>timestamp with time zone</type>, <type>interval</type> <optional>, <type>text</type> </optional> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Add an <type>interval</type> to a <type>timestamp with time
+ zone</type>, computing times of day and daylight-savings adjustments
+ according to the time zone named by the third argument, or the
+ current <xref linkend="guc-timezone"/> setting if that is omitted.
+ The form with two arguments is equivalent to the <type>timestamp with
+ time zone</type> <literal>+</literal> <type>interval</type> operator.
+ </para>
+ <para>
+ <literal>date_add('2021-10-31 00:00:00+02'::timestamptz, '1 day'::interval, 'Europe/Warsaw')</literal>
+ <returnvalue>2021-10-31 23:00:00+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>date_bin</function> ( <type>interval</type>, <type>timestamp</type>, <type>timestamp</type> )
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Bin input into specified interval aligned with specified origin; see <xref linkend="functions-datetime-bin"/>
+ </para>
+ <para>
+ <literal>date_bin('15 minutes', timestamp '2001-02-16 20:38:40', timestamp '2001-02-16 20:05:00')</literal>
+ <returnvalue>2001-02-16 20:35:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>date_part</primary>
+ </indexterm>
+ <function>date_part</function> ( <type>text</type>, <type>timestamp</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Get timestamp subfield (equivalent to <function>extract</function>);
+ see <xref linkend="functions-datetime-extract"/>
+ </para>
+ <para>
+ <literal>date_part('hour', timestamp '2001-02-16 20:38:40')</literal>
+ <returnvalue>20</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>date_part</function> ( <type>text</type>, <type>interval</type> )
+ <returnvalue>double precision</returnvalue>
+ </para>
+ <para>
+ Get interval subfield (equivalent to <function>extract</function>);
+ see <xref linkend="functions-datetime-extract"/>
+ </para>
+ <para>
+ <literal>date_part('month', interval '2 years 3 months')</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>date_subtract</primary>
+ </indexterm>
+ <function>date_subtract</function> ( <type>timestamp with time zone</type>, <type>interval</type> <optional>, <type>text</type> </optional> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Subtract an <type>interval</type> from a <type>timestamp with time
+ zone</type>, computing times of day and daylight-savings adjustments
+ according to the time zone named by the third argument, or the
+ current <xref linkend="guc-timezone"/> setting if that is omitted.
+ The form with two arguments is equivalent to the <type>timestamp with
+ time zone</type> <literal>-</literal> <type>interval</type> operator.
+ </para>
+ <para>
+ <literal>date_subtract('2021-11-01 00:00:00+01'::timestamptz, '1 day'::interval, 'Europe/Warsaw')</literal>
+ <returnvalue>2021-10-30 22:00:00+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>date_trunc</primary>
+ </indexterm>
+ <function>date_trunc</function> ( <type>text</type>, <type>timestamp</type> )
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Truncate to specified precision; see <xref linkend="functions-datetime-trunc"/>
+ </para>
+ <para>
+ <literal>date_trunc('hour', timestamp '2001-02-16 20:38:40')</literal>
+ <returnvalue>2001-02-16 20:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>date_trunc</function> ( <type>text</type>, <type>timestamp with time zone</type>, <type>text</type> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Truncate to specified precision in the specified time zone; see
+ <xref linkend="functions-datetime-trunc"/>
+ </para>
+ <para>
+ <literal>date_trunc('day', timestamptz '2001-02-16 20:38:40+00', 'Australia/Sydney')</literal>
+ <returnvalue>2001-02-16 13:00:00+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>date_trunc</function> ( <type>text</type>, <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Truncate to specified precision; see
+ <xref linkend="functions-datetime-trunc"/>
+ </para>
+ <para>
+ <literal>date_trunc('hour', interval '2 days 3 hours 40 minutes')</literal>
+ <returnvalue>2 days 03:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>extract</primary>
+ </indexterm>
+ <function>extract</function> ( <parameter>field</parameter> <literal>from</literal> <type>timestamp</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para>
+ Get timestamp subfield; see <xref linkend="functions-datetime-extract"/>
+ </para>
+ <para>
+ <literal>extract(hour from timestamp '2001-02-16 20:38:40')</literal>
+ <returnvalue>20</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>extract</function> ( <parameter>field</parameter> <literal>from</literal> <type>interval</type> )
+ <returnvalue>numeric</returnvalue>
+ </para>
+ <para>
+ Get interval subfield; see <xref linkend="functions-datetime-extract"/>
+ </para>
+ <para>
+ <literal>extract(month from interval '2 years 3 months')</literal>
+ <returnvalue>3</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>isfinite</primary>
+ </indexterm>
+ <function>isfinite</function> ( <type>date</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Test for finite date (not +/-infinity)
+ </para>
+ <para>
+ <literal>isfinite(date '2001-02-16')</literal>
+ <returnvalue>true</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>isfinite</function> ( <type>timestamp</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Test for finite timestamp (not +/-infinity)
+ </para>
+ <para>
+ <literal>isfinite(timestamp 'infinity')</literal>
+ <returnvalue>false</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>isfinite</function> ( <type>interval</type> )
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ Test for finite interval (not +/-infinity)
+ </para>
+ <para>
+ <literal>isfinite(interval '4 hours')</literal>
+ <returnvalue>true</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm id="function-justify-days">
+ <primary>justify_days</primary>
+ </indexterm>
+ <function>justify_days</function> ( <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Adjust interval, converting 30-day time periods to months
+ </para>
+ <para>
+ <literal>justify_days(interval '1 year 65 days')</literal>
+ <returnvalue>1 year 2 mons 5 days</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm id="function-justify-hours">
+ <primary>justify_hours</primary>
+ </indexterm>
+ <function>justify_hours</function> ( <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Adjust interval, converting 24-hour time periods to days
+ </para>
+ <para>
+ <literal>justify_hours(interval '50 hours 10 minutes')</literal>
+ <returnvalue>2 days 02:10:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>justify_interval</primary>
+ </indexterm>
+ <function>justify_interval</function> ( <type>interval</type> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Adjust interval using <function>justify_days</function>
+ and <function>justify_hours</function>, with additional sign
+ adjustments
+ </para>
+ <para>
+ <literal>justify_interval(interval '1 mon -1 hour')</literal>
+ <returnvalue>29 days 23:00:00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>localtime</primary>
+ </indexterm>
+ <function>localtime</function>
+ <returnvalue>time</returnvalue>
+ </para>
+ <para>
+ Current time of day;
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>localtime</literal>
+ <returnvalue>14:39:53.662522</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>localtime</function> ( <type>integer</type> )
+ <returnvalue>time</returnvalue>
+ </para>
+ <para>
+ Current time of day, with limited precision;
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>localtime(0)</literal>
+ <returnvalue>14:39:53</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>localtimestamp</primary>
+ </indexterm>
+ <function>localtimestamp</function>
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current transaction);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>localtimestamp</literal>
+ <returnvalue>2019-12-23 14:39:53.662522</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <function>localtimestamp</function> ( <type>integer</type> )
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current
+ transaction), with limited precision;
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>localtimestamp(2)</literal>
+ <returnvalue>2019-12-23 14:39:53.66</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>make_date</primary>
+ </indexterm>
+ <function>make_date</function> ( <parameter>year</parameter> <type>int</type>,
+ <parameter>month</parameter> <type>int</type>,
+ <parameter>day</parameter> <type>int</type> )
+ <returnvalue>date</returnvalue>
+ </para>
+ <para>
+ Create date from year, month and day fields
+ (negative years signify BC)
+ </para>
+ <para>
+ <literal>make_date(2013, 7, 15)</literal>
+ <returnvalue>2013-07-15</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature"><indexterm>
+ <primary>make_interval</primary>
+ </indexterm>
+ <function>make_interval</function> ( <optional> <parameter>years</parameter> <type>int</type>
+ <optional>, <parameter>months</parameter> <type>int</type>
+ <optional>, <parameter>weeks</parameter> <type>int</type>
+ <optional>, <parameter>days</parameter> <type>int</type>
+ <optional>, <parameter>hours</parameter> <type>int</type>
+ <optional>, <parameter>mins</parameter> <type>int</type>
+ <optional>, <parameter>secs</parameter> <type>double precision</type>
+ </optional></optional></optional></optional></optional></optional></optional> )
+ <returnvalue>interval</returnvalue>
+ </para>
+ <para>
+ Create interval from years, months, weeks, days, hours, minutes and
+ seconds fields, each of which can default to zero
+ </para>
+ <para>
+ <literal>make_interval(days => 10)</literal>
+ <returnvalue>10 days</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>make_time</primary>
+ </indexterm>
+ <function>make_time</function> ( <parameter>hour</parameter> <type>int</type>,
+ <parameter>min</parameter> <type>int</type>,
+ <parameter>sec</parameter> <type>double precision</type> )
+ <returnvalue>time</returnvalue>
+ </para>
+ <para>
+ Create time from hour, minute and seconds fields
+ </para>
+ <para>
+ <literal>make_time(8, 15, 23.5)</literal>
+ <returnvalue>08:15:23.5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>make_timestamp</primary>
+ </indexterm>
+ <function>make_timestamp</function> ( <parameter>year</parameter> <type>int</type>,
+ <parameter>month</parameter> <type>int</type>,
+ <parameter>day</parameter> <type>int</type>,
+ <parameter>hour</parameter> <type>int</type>,
+ <parameter>min</parameter> <type>int</type>,
+ <parameter>sec</parameter> <type>double precision</type> )
+ <returnvalue>timestamp</returnvalue>
+ </para>
+ <para>
+ Create timestamp from year, month, day, hour, minute and seconds fields
+ (negative years signify BC)
+ </para>
+ <para>
+ <literal>make_timestamp(2013, 7, 15, 8, 15, 23.5)</literal>
+ <returnvalue>2013-07-15 08:15:23.5</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>make_timestamptz</primary>
+ </indexterm>
+ <function>make_timestamptz</function> ( <parameter>year</parameter> <type>int</type>,
+ <parameter>month</parameter> <type>int</type>,
+ <parameter>day</parameter> <type>int</type>,
+ <parameter>hour</parameter> <type>int</type>,
+ <parameter>min</parameter> <type>int</type>,
+ <parameter>sec</parameter> <type>double precision</type>
+ <optional>, <parameter>timezone</parameter> <type>text</type> </optional> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Create timestamp with time zone from year, month, day, hour, minute
+ and seconds fields (negative years signify BC).
+ If <parameter>timezone</parameter> is not
+ specified, the current time zone is used; the examples assume the
+ session time zone is <literal>Europe/London</literal>
+ </para>
+ <para>
+ <literal>make_timestamptz(2013, 7, 15, 8, 15, 23.5)</literal>
+ <returnvalue>2013-07-15 08:15:23.5+01</returnvalue>
+ </para>
+ <para>
+ <literal>make_timestamptz(2013, 7, 15, 8, 15, 23.5, 'America/New_York')</literal>
+ <returnvalue>2013-07-15 13:15:23.5+01</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>now</primary>
+ </indexterm>
+ <function>now</function> ( )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current transaction);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>now()</literal>
+ <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>statement_timestamp</primary>
+ </indexterm>
+ <function>statement_timestamp</function> ( )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current statement);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>statement_timestamp()</literal>
+ <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>timeofday</primary>
+ </indexterm>
+ <function>timeofday</function> ( )
+ <returnvalue>text</returnvalue>
+ </para>
+ <para>
+ Current date and time
+ (like <function>clock_timestamp</function>, but as a <type>text</type> string);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>timeofday()</literal>
+ <returnvalue>Mon Dec 23 14:39:53.662522 2019 EST</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>transaction_timestamp</primary>
+ </indexterm>
+ <function>transaction_timestamp</function> ( )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Current date and time (start of current transaction);
+ see <xref linkend="functions-datetime-current"/>
+ </para>
+ <para>
+ <literal>transaction_timestamp()</literal>
+ <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>to_timestamp</primary>
+ </indexterm>
+ <function>to_timestamp</function> ( <type>double precision</type> )
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Convert Unix epoch (seconds since 1970-01-01 00:00:00+00) to
+ timestamp with time zone
+ </para>
+ <para>
+ <literal>to_timestamp(1284352323)</literal>
+ <returnvalue>2010-09-13 04:32:03+00</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <indexterm>
+ <primary>OVERLAPS</primary>
+ </indexterm>
+ In addition to these functions, the SQL <literal>OVERLAPS</literal> operator is
+ supported:
+<synopsis>
+(<replaceable>start1</replaceable>, <replaceable>end1</replaceable>) OVERLAPS (<replaceable>start2</replaceable>, <replaceable>end2</replaceable>)
+(<replaceable>start1</replaceable>, <replaceable>length1</replaceable>) OVERLAPS (<replaceable>start2</replaceable>, <replaceable>length2</replaceable>)
+</synopsis>
+ This expression yields true when two time periods (defined by their
+ endpoints) overlap, false when they do not overlap. The endpoints
+ can be specified as pairs of dates, times, or time stamps; or as
+ a date, time, or time stamp followed by an interval. When a pair
+ of values is provided, either the start or the end can be written
+ first; <literal>OVERLAPS</literal> automatically takes the earlier value
+ of the pair as the start. Each time period is considered to
+ represent the half-open interval <replaceable>start</replaceable> <literal><=</literal>
+ <replaceable>time</replaceable> <literal><</literal> <replaceable>end</replaceable>, unless
+ <replaceable>start</replaceable> and <replaceable>end</replaceable> are equal in which case it
+ represents that single time instant. This means for instance that two
+ time periods with only an endpoint in common do not overlap.
+ </para>
+
+<screen>
+SELECT (DATE '2001-02-16', DATE '2001-12-21') OVERLAPS
+ (DATE '2001-10-30', DATE '2002-10-30');
+<lineannotation>Result: </lineannotation><computeroutput>true</computeroutput>
+SELECT (DATE '2001-02-16', INTERVAL '100 days') OVERLAPS
+ (DATE '2001-10-30', DATE '2002-10-30');
+<lineannotation>Result: </lineannotation><computeroutput>false</computeroutput>
+SELECT (DATE '2001-10-29', DATE '2001-10-30') OVERLAPS
+ (DATE '2001-10-30', DATE '2001-10-31');
+<lineannotation>Result: </lineannotation><computeroutput>false</computeroutput>
+SELECT (DATE '2001-10-30', DATE '2001-10-30') OVERLAPS
+ (DATE '2001-10-30', DATE '2001-10-31');
+<lineannotation>Result: </lineannotation><computeroutput>true</computeroutput>
+</screen>
+
+ <para>
+ When adding an <type>interval</type> value to (or subtracting an
+ <type>interval</type> value from) a <type>timestamp</type>
+ or <type>timestamp with time zone</type> value, the months, days, and
+ microseconds fields of the <type>interval</type> value are handled in turn.
+ First, a nonzero months field advances or decrements the date of the
+ timestamp by the indicated number of months, keeping the day of month the
+ same unless it would be past the end of the new month, in which case the
+ last day of that month is used. (For example, March 31 plus 1 month
+ becomes April 30, but March 31 plus 2 months becomes May 31.)
+ Then the days field advances or decrements the date of the timestamp by
+ the indicated number of days. In both these steps the local time of day
+ is kept the same. Finally, if there is a nonzero microseconds field, it
+ is added or subtracted literally.
+ When doing arithmetic on a <type>timestamp with time zone</type> value in
+ a time zone that recognizes DST, this means that adding or subtracting
+ (say) <literal>interval '1 day'</literal> does not necessarily have the
+ same result as adding or subtracting <literal>interval '24
+ hours'</literal>.
+ For example, with the session time zone set
+ to <literal>America/Denver</literal>:
+<screen>
+SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '1 day';
+<lineannotation>Result: </lineannotation><computeroutput>2005-04-03 12:00:00-06</computeroutput>
+SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '24 hours';
+<lineannotation>Result: </lineannotation><computeroutput>2005-04-03 13:00:00-06</computeroutput>
+</screen>
+ This happens because an hour was skipped due to a change in daylight saving
+ time at <literal>2005-04-03 02:00:00</literal> in time zone
+ <literal>America/Denver</literal>.
+ </para>
+
+ <para>
+ Note there can be ambiguity in the <literal>months</literal> field returned by
+ <function>age</function> because different months have different numbers of
+ days. <productname>PostgreSQL</productname>'s approach uses the month from the
+ earlier of the two dates when calculating partial months. For example,
+ <literal>age('2004-06-01', '2004-04-30')</literal> uses April to yield
+ <literal>1 mon 1 day</literal>, while using May would yield <literal>1 mon 2
+ days</literal> because May has 31 days, while April has only 30.
+ </para>
+
+ <para>
+ Subtraction of dates and timestamps can also be complex. One conceptually
+ simple way to perform subtraction is to convert each value to a number
+ of seconds using <literal>EXTRACT(EPOCH FROM ...)</literal>, then subtract the
+ results; this produces the
+ number of <emphasis>seconds</emphasis> between the two values. This will adjust
+ for the number of days in each month, timezone changes, and daylight
+ saving time adjustments. Subtraction of date or timestamp
+ values with the <quote><literal>-</literal></quote> operator
+ returns the number of days (24-hours) and hours/minutes/seconds
+ between the values, making the same adjustments. The <function>age</function>
+ function returns years, months, days, and hours/minutes/seconds,
+ performing field-by-field subtraction and then adjusting for negative
+ field values. The following queries illustrate the differences in these
+ approaches. The sample results were produced with <literal>timezone
+ = 'US/Eastern'</literal>; there is a daylight saving time change between the
+ two dates used:
+ </para>
+
+<screen>
+SELECT EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
+ EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00');
+<lineannotation>Result: </lineannotation><computeroutput>10537200.000000</computeroutput>
+SELECT (EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
+ EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00'))
+ / 60 / 60 / 24;
+<lineannotation>Result: </lineannotation><computeroutput>121.9583333333333333</computeroutput>
+SELECT timestamptz '2013-07-01 12:00:00' - timestamptz '2013-03-01 12:00:00';
+<lineannotation>Result: </lineannotation><computeroutput>121 days 23:00:00</computeroutput>
+SELECT age(timestamptz '2013-07-01 12:00:00', timestamptz '2013-03-01 12:00:00');
+<lineannotation>Result: </lineannotation><computeroutput>4 mons</computeroutput>
+</screen>
+
+ <sect2 id="functions-datetime-extract">
+ <title><function>EXTRACT</function>, <function>date_part</function></title>
+
+ <indexterm>
+ <primary>date_part</primary>
+ </indexterm>
+ <indexterm>
+ <primary>extract</primary>
+ </indexterm>
+
+<synopsis>
+EXTRACT(<replaceable>field</replaceable> FROM <replaceable>source</replaceable>)
+</synopsis>
+
+ <para>
+ The <function>extract</function> function retrieves subfields
+ such as year or hour from date/time values.
+ <replaceable>source</replaceable> must be a value expression of
+ type <type>timestamp</type>, <type>date</type>, <type>time</type>,
+ or <type>interval</type>. (Timestamps and times can be with or
+ without time zone.)
+ <replaceable>field</replaceable> is an identifier or
+ string that selects what field to extract from the source value.
+ Not all fields are valid for every input data type; for example, fields
+ smaller than a day cannot be extracted from a <type>date</type>, while
+ fields of a day or more cannot be extracted from a <type>time</type>.
+ The <function>extract</function> function returns values of type
+ <type>numeric</type>.
+ </para>
+
+ <para>
+ The following are valid field names:
+
+ <!-- alphabetical -->
+ <variablelist>
+ <varlistentry>
+ <term><literal>century</literal></term>
+ <listitem>
+ <para>
+ The century; for <type>interval</type> values, the year field
+ divided by 100
+ </para>
+
+<screen>
+SELECT EXTRACT(CENTURY FROM TIMESTAMP '2000-12-16 12:21:13');
+<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
+SELECT EXTRACT(CENTURY FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>21</computeroutput>
+SELECT EXTRACT(CENTURY FROM DATE '0001-01-01 AD');
+<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
+SELECT EXTRACT(CENTURY FROM DATE '0001-12-31 BC');
+<lineannotation>Result: </lineannotation><computeroutput>-1</computeroutput>
+SELECT EXTRACT(CENTURY FROM INTERVAL '2001 years');
+<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>day</literal></term>
+ <listitem>
+ <para>
+ The day of the month (1–31); for <type>interval</type>
+ values, the number of days
+ </para>
+
+<screen>
+SELECT EXTRACT(DAY FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>16</computeroutput>
+SELECT EXTRACT(DAY FROM INTERVAL '40 days 1 minute');
+<lineannotation>Result: </lineannotation><computeroutput>40</computeroutput>
+</screen>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>decade</literal></term>
+ <listitem>
+ <para>
+ The year field divided by 10
+ </para>
+
+<screen>
+SELECT EXTRACT(DECADE FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>200</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>dow</literal></term>
+ <listitem>
+ <para>
+ The day of the week as Sunday (<literal>0</literal>) to
+ Saturday (<literal>6</literal>)
+ </para>
+
+<screen>
+SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>5</computeroutput>
+</screen>
+ <para>
+ Note that <function>extract</function>'s day of the week numbering
+ differs from that of the <function>to_char(...,
+ 'D')</function> function.
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>doy</literal></term>
+ <listitem>
+ <para>
+ The day of the year (1–365/366)
+ </para>
+
+<screen>
+SELECT EXTRACT(DOY FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>47</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>epoch</literal></term>
+ <listitem>
+ <para>
+ For <type>timestamp with time zone</type> values, the
+ number of seconds since 1970-01-01 00:00:00 UTC (negative for
+ timestamps before that);
+ for <type>date</type> and <type>timestamp</type> values, the
+ nominal number of seconds since 1970-01-01 00:00:00,
+ without regard to timezone or daylight-savings rules;
+ for <type>interval</type> values, the total number
+ of seconds in the interval
+ </para>
+
+<screen>
+SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40.12-08');
+<lineannotation>Result: </lineannotation><computeroutput>982384720.120000</computeroutput>
+SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40.12');
+<lineannotation>Result: </lineannotation><computeroutput>982355920.120000</computeroutput>
+SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
+<lineannotation>Result: </lineannotation><computeroutput>442800.000000</computeroutput>
+</screen>
+
+ <para>
+ You can convert an epoch value back to a <type>timestamp with time zone</type>
+ with <function>to_timestamp</function>:
+ </para>
+<screen>
+SELECT to_timestamp(982384720.12);
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-17 04:38:40.12+00</computeroutput>
+</screen>
+
+ <para>
+ Beware that applying <function>to_timestamp</function> to an epoch
+ extracted from a <type>date</type> or <type>timestamp</type> value
+ could produce a misleading result: the result will effectively
+ assume that the original value had been given in UTC, which might
+ not be the case.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>hour</literal></term>
+ <listitem>
+ <para>
+ The hour field (0–23 in timestamps, unrestricted in
+ intervals)
+ </para>
+
+<screen>
+SELECT EXTRACT(HOUR FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>isodow</literal></term>
+ <listitem>
+ <para>
+ The day of the week as Monday (<literal>1</literal>) to
+ Sunday (<literal>7</literal>)
+ </para>
+
+<screen>
+SELECT EXTRACT(ISODOW FROM TIMESTAMP '2001-02-18 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>7</computeroutput>
+</screen>
+ <para>
+ This is identical to <literal>dow</literal> except for Sunday. This
+ matches the <acronym>ISO</acronym> 8601 day of the week numbering.
+ </para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>isoyear</literal></term>
+ <listitem>
+ <para>
+ The <acronym>ISO</acronym> 8601 week-numbering year that the date
+ falls in
+ </para>
+
+<screen>
+SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-01');
+<lineannotation>Result: </lineannotation><computeroutput>2005</computeroutput>
+SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-02');
+<lineannotation>Result: </lineannotation><computeroutput>2006</computeroutput>
+</screen>
+
+ <para>
+ Each <acronym>ISO</acronym> 8601 week-numbering year begins with the
+ Monday of the week containing the 4th of January, so in early
+ January or late December the <acronym>ISO</acronym> year may be
+ different from the Gregorian year. See the <literal>week</literal>
+ field for more information.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>julian</literal></term>
+ <listitem>
+ <para>
+ The <firstterm>Julian Date</firstterm> corresponding to the
+ date or timestamp. Timestamps
+ that are not local midnight result in a fractional value. See
+ <xref linkend="datetime-julian-dates"/> for more information.
+ </para>
+
+<screen>
+SELECT EXTRACT(JULIAN FROM DATE '2006-01-01');
+<lineannotation>Result: </lineannotation><computeroutput>2453737</computeroutput>
+SELECT EXTRACT(JULIAN FROM TIMESTAMP '2006-01-01 12:00');
+<lineannotation>Result: </lineannotation><computeroutput>2453737.50000000000000000000</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>microseconds</literal></term>
+ <listitem>
+ <para>
+ The seconds field, including fractional parts, multiplied by 1
+ 000 000; note that this includes full seconds
+ </para>
+
+<screen>
+SELECT EXTRACT(MICROSECONDS FROM TIME '17:12:28.5');
+<lineannotation>Result: </lineannotation><computeroutput>28500000</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>millennium</literal></term>
+ <listitem>
+ <para>
+ The millennium; for <type>interval</type> values, the year field
+ divided by 1000
+ </para>
+
+<screen>
+SELECT EXTRACT(MILLENNIUM FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>3</computeroutput>
+SELECT EXTRACT(MILLENNIUM FROM INTERVAL '2001 years');
+<lineannotation>Result: </lineannotation><computeroutput>2</computeroutput>
+</screen>
+
+ <para>
+ Years in the 1900s are in the second millennium.
+ The third millennium started January 1, 2001.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>milliseconds</literal></term>
+ <listitem>
+ <para>
+ The seconds field, including fractional parts, multiplied by
+ 1000. Note that this includes full seconds.
+ </para>
+
+<screen>
+SELECT EXTRACT(MILLISECONDS FROM TIME '17:12:28.5');
+<lineannotation>Result: </lineannotation><computeroutput>28500.000</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>minute</literal></term>
+ <listitem>
+ <para>
+ The minutes field (0–59)
+ </para>
+
+<screen>
+SELECT EXTRACT(MINUTE FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>38</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>month</literal></term>
+ <listitem>
+ <para>
+ The number of the month within the year (1–12);
+ for <type>interval</type> values, the number of months modulo 12
+ (0–11)
+ </para>
+
+<screen>
+SELECT EXTRACT(MONTH FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>2</computeroutput>
+SELECT EXTRACT(MONTH FROM INTERVAL '2 years 3 months');
+<lineannotation>Result: </lineannotation><computeroutput>3</computeroutput>
+SELECT EXTRACT(MONTH FROM INTERVAL '2 years 13 months');
+<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>quarter</literal></term>
+ <listitem>
+ <para>
+ The quarter of the year (1–4) that the date is in
+ </para>
+
+<screen>
+SELECT EXTRACT(QUARTER FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>second</literal></term>
+ <listitem>
+ <para>
+ The seconds field, including any fractional seconds
+ </para>
+
+<screen>
+SELECT EXTRACT(SECOND FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>40.000000</computeroutput>
+SELECT EXTRACT(SECOND FROM TIME '17:12:28.5');
+<lineannotation>Result: </lineannotation><computeroutput>28.500000</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>timezone</literal></term>
+ <listitem>
+ <para>
+ The time zone offset from UTC, measured in seconds. Positive values
+ correspond to time zones east of UTC, negative values to
+ zones west of UTC. (Technically,
+ <productname>PostgreSQL</productname> does not use UTC because
+ leap seconds are not handled.)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>timezone_hour</literal></term>
+ <listitem>
+ <para>
+ The hour component of the time zone offset
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>timezone_minute</literal></term>
+ <listitem>
+ <para>
+ The minute component of the time zone offset
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>week</literal></term>
+ <listitem>
+ <para>
+ The number of the <acronym>ISO</acronym> 8601 week-numbering week of
+ the year. By definition, ISO weeks start on Mondays and the first
+ week of a year contains January 4 of that year. In other words, the
+ first Thursday of a year is in week 1 of that year.
+ </para>
+ <para>
+ In the ISO week-numbering system, it is possible for early-January
+ dates to be part of the 52nd or 53rd week of the previous year, and for
+ late-December dates to be part of the first week of the next year.
+ For example, <literal>2005-01-01</literal> is part of the 53rd week of year
+ 2004, and <literal>2006-01-01</literal> is part of the 52nd week of year
+ 2005, while <literal>2012-12-31</literal> is part of the first week of 2013.
+ It's recommended to use the <literal>isoyear</literal> field together with
+ <literal>week</literal> to get consistent results.
+ </para>
+
+<screen>
+SELECT EXTRACT(WEEK FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>7</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>year</literal></term>
+ <listitem>
+ <para>
+ The year field. Keep in mind there is no <literal>0 AD</literal>, so subtracting
+ <literal>BC</literal> years from <literal>AD</literal> years should be done with care.
+ </para>
+
+<screen>
+SELECT EXTRACT(YEAR FROM TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>2001</computeroutput>
+</screen>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </para>
+
+ <para>
+ When processing an <type>interval</type> value,
+ the <function>extract</function> function produces field values that
+ match the interpretation used by the interval output function. This
+ can produce surprising results if one starts with a non-normalized
+ interval representation, for example:
+<screen>
+SELECT INTERVAL '80 minutes';
+<lineannotation>Result: </lineannotation><computeroutput>01:20:00</computeroutput>
+SELECT EXTRACT(MINUTES FROM INTERVAL '80 minutes');
+<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
+</screen>
+ </para>
+
+ <note>
+ <para>
+ When the input value is +/-Infinity, <function>extract</function> returns
+ +/-Infinity for monotonically-increasing fields (<literal>epoch</literal>,
+ <literal>julian</literal>, <literal>year</literal>, <literal>isoyear</literal>,
+ <literal>decade</literal>, <literal>century</literal>, and <literal>millennium</literal>
+ for <type>timestamp</type> inputs; <literal>epoch</literal>, <literal>hour</literal>,
+ <literal>day</literal>, <literal>year</literal>, <literal>decade</literal>,
+ <literal>century</literal>, and <literal>millennium</literal> for
+ <type>interval</type> inputs).
+ For other fields, NULL is returned. <productname>PostgreSQL</productname>
+ versions before 9.6 returned zero for all cases of infinite input.
+ </para>
+ </note>
+
+ <para>
+ The <function>extract</function> function is primarily intended
+ for computational processing. For formatting date/time values for
+ display, see <xref linkend="functions-formatting"/>.
+ </para>
+
+ <para>
+ The <function>date_part</function> function is modeled on the traditional
+ <productname>Ingres</productname> equivalent to the
+ <acronym>SQL</acronym>-standard function <function>extract</function>:
+<synopsis>
+date_part('<replaceable>field</replaceable>', <replaceable>source</replaceable>)
+</synopsis>
+ Note that here the <replaceable>field</replaceable> parameter needs to
+ be a string value, not a name. The valid field names for
+ <function>date_part</function> are the same as for
+ <function>extract</function>.
+ For historical reasons, the <function>date_part</function> function
+ returns values of type <type>double precision</type>. This can result in
+ a loss of precision in certain uses. Using <function>extract</function>
+ is recommended instead.
+ </para>
+
+<screen>
+SELECT date_part('day', TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>16</computeroutput>
+SELECT date_part('hour', INTERVAL '4 hours 3 minutes');
+<lineannotation>Result: </lineannotation><computeroutput>4</computeroutput>
+</screen>
+
+ </sect2>
+
+ <sect2 id="functions-datetime-trunc">
+ <title><function>date_trunc</function></title>
+
+ <indexterm>
+ <primary>date_trunc</primary>
+ </indexterm>
+
+ <para>
+ The function <function>date_trunc</function> is conceptually
+ similar to the <function>trunc</function> function for numbers.
+ </para>
+
+ <para>
+<synopsis>
+date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> [, <replaceable>time_zone</replaceable> ])
+</synopsis>
+ <replaceable>source</replaceable> is a value expression of type
+ <type>timestamp</type>, <type>timestamp with time zone</type>,
+ or <type>interval</type>.
+ (Values of type <type>date</type> and
+ <type>time</type> are cast automatically to <type>timestamp</type> or
+ <type>interval</type>, respectively.)
+ <replaceable>field</replaceable> selects to which precision to
+ truncate the input value. The return value is likewise of type
+ <type>timestamp</type>, <type>timestamp with time zone</type>,
+ or <type>interval</type>,
+ and it has all fields that are less significant than the
+ selected one set to zero (or one, for day and month).
+ </para>
+
+ <para>
+ Valid values for <replaceable>field</replaceable> are:
+ <simplelist>
+ <member><literal>microseconds</literal></member>
+ <member><literal>milliseconds</literal></member>
+ <member><literal>second</literal></member>
+ <member><literal>minute</literal></member>
+ <member><literal>hour</literal></member>
+ <member><literal>day</literal></member>
+ <member><literal>week</literal></member>
+ <member><literal>month</literal></member>
+ <member><literal>quarter</literal></member>
+ <member><literal>year</literal></member>
+ <member><literal>decade</literal></member>
+ <member><literal>century</literal></member>
+ <member><literal>millennium</literal></member>
+ </simplelist>
+ </para>
+
+ <para>
+ When the input value is of type <type>timestamp with time zone</type>,
+ the truncation is performed with respect to a particular time zone;
+ for example, truncation to <literal>day</literal> produces a value that
+ is midnight in that zone. By default, truncation is done with respect
+ to the current <xref linkend="guc-timezone"/> setting, but the
+ optional <replaceable>time_zone</replaceable> argument can be provided
+ to specify a different time zone. The time zone name can be specified
+ in any of the ways described in <xref linkend="datatype-timezones"/>.
+ </para>
+
+ <para>
+ A time zone cannot be specified when processing <type>timestamp without
+ time zone</type> or <type>interval</type> inputs. These are always
+ taken at face value.
+ </para>
+
+ <para>
+ Examples (assuming the local time zone is <literal>America/New_York</literal>):
+<screen>
+SELECT date_trunc('hour', TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 20:00:00</computeroutput>
+SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
+<lineannotation>Result: </lineannotation><computeroutput>2001-01-01 00:00:00</computeroutput>
+SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00');
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 00:00:00-05</computeroutput>
+SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00', 'Australia/Sydney');
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 08:00:00-05</computeroutput>
+SELECT date_trunc('hour', INTERVAL '3 days 02:47:33');
+<lineannotation>Result: </lineannotation><computeroutput>3 days 02:00:00</computeroutput>
+</screen>
+ </para>
+ </sect2>
+
+ <sect2 id="functions-datetime-bin">
+ <title><function>date_bin</function></title>
+
+ <indexterm>
+ <primary>date_bin</primary>
+ </indexterm>
+
+ <para>
+ The function <function>date_bin</function> <quote>bins</quote> the input
+ timestamp into the specified interval (the <firstterm>stride</firstterm>)
+ aligned with a specified origin.
+ </para>
+
+ <para>
+<synopsis>
+date_bin(<replaceable>stride</replaceable>, <replaceable>source</replaceable>, <replaceable>origin</replaceable>)
+</synopsis>
+ <replaceable>source</replaceable> is a value expression of type
+ <type>timestamp</type> or <type>timestamp with time zone</type>. (Values
+ of type <type>date</type> are cast automatically to
+ <type>timestamp</type>.) <replaceable>stride</replaceable> is a value
+ expression of type <type>interval</type>. The return value is likewise
+ of type <type>timestamp</type> or <type>timestamp with time zone</type>,
+ and it marks the beginning of the bin into which the
+ <replaceable>source</replaceable> is placed.
+ </para>
+
+ <para>
+ Examples:
+<screen>
+SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01');
+<lineannotation>Result: </lineannotation><computeroutput>2020-02-11 15:30:00</computeroutput>
+SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01 00:02:30');
+<lineannotation>Result: </lineannotation><computeroutput>2020-02-11 15:32:30</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ In the case of full units (1 minute, 1 hour, etc.), it gives the same result as
+ the analogous <function>date_trunc</function> call, but the difference is
+ that <function>date_bin</function> can truncate to an arbitrary interval.
+ </para>
+
+ <para>
+ The <parameter>stride</parameter> interval must be greater than zero and
+ cannot contain units of month or larger.
+ </para>
+ </sect2>
+
+ <sect2 id="functions-datetime-zoneconvert">
+ <title><literal>AT TIME ZONE and AT LOCAL</literal></title>
+
+ <indexterm>
+ <primary>time zone</primary>
+ <secondary>conversion</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>AT TIME ZONE</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>AT LOCAL</primary>
+ </indexterm>
+
+ <para>
+ The <literal>AT TIME ZONE</literal> operator converts time
+ stamp <emphasis>without</emphasis> time zone to/from
+ time stamp <emphasis>with</emphasis> time zone, and
+ <type>time with time zone</type> values to different time
+ zones. <xref linkend="functions-datetime-zoneconvert-table"/> shows its
+ variants.
+ </para>
+
+ <table id="functions-datetime-zoneconvert-table">
+ <title><literal>AT TIME ZONE</literal> and <literal>AT LOCAL</literal> Variants</title>
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp without time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time stamp <emphasis>without</emphasis> time zone to
+ time stamp <emphasis>with</emphasis> time zone, assuming the given
+ value is in the named time zone.
+ </para>
+ <para>
+ <literal>timestamp '2001-02-16 20:38:40' at time zone 'America/Denver'</literal>
+ <returnvalue>2001-02-17 03:38:40+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp without time zone</type> <literal>AT LOCAL</literal>
+ <returnvalue>timestamp with time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time stamp <emphasis>without</emphasis> time zone to
+ time stamp <emphasis>with</emphasis> the session's
+ <varname>TimeZone</varname> value as time zone.
+ </para>
+ <para>
+ <literal>timestamp '2001-02-16 20:38:40' at local</literal>
+ <returnvalue>2001-02-17 03:38:40+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp with time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
+ <returnvalue>timestamp without time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time stamp <emphasis>with</emphasis> time zone to
+ time stamp <emphasis>without</emphasis> time zone, as the time would
+ appear in that zone.
+ </para>
+ <para>
+ <literal>timestamp with time zone '2001-02-16 20:38:40-05' at time zone 'America/Denver'</literal>
+ <returnvalue>2001-02-16 18:38:40</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>timestamp with time zone</type> <literal>AT LOCAL</literal>
+ <returnvalue>timestamp without time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time stamp <emphasis>with</emphasis> time zone to
+ time stamp <emphasis>without</emphasis> time zone, as the time would
+ appear with the session's <varname>TimeZone</varname> value as time zone.
+ </para>
+ <para>
+ <literal>timestamp with time zone '2001-02-16 20:38:40-05' at local</literal>
+ <returnvalue>2001-02-16 18:38:40</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>time with time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
+ <returnvalue>time with time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time <emphasis>with</emphasis> time zone to a new time
+ zone. Since no date is supplied, this uses the currently active UTC
+ offset for the named destination zone.
+ </para>
+ <para>
+ <literal>time with time zone '05:34:17-05' at time zone 'UTC'</literal>
+ <returnvalue>10:34:17+00</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>time with time zone</type> <literal>AT LOCAL</literal>
+ <returnvalue>time with time zone</returnvalue>
+ </para>
+ <para>
+ Converts given time <emphasis>with</emphasis> time zone to a new time
+ zone. Since no date is supplied, this uses the currently active UTC
+ offset for the session's <varname>TimeZone</varname> value.
+ </para>
+ <para>
+ Assuming the session's <varname>TimeZone</varname> is set to <literal>UTC</literal>:
+ </para>
+ <para>
+ <literal>time with time zone '05:34:17-05' at local</literal>
+ <returnvalue>10:34:17+00</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ In these expressions, the desired time zone <replaceable>zone</replaceable> can be
+ specified either as a text value (e.g., <literal>'America/Los_Angeles'</literal>)
+ or as an interval (e.g., <literal>INTERVAL '-08:00'</literal>).
+ In the text case, a time zone name can be specified in any of the ways
+ described in <xref linkend="datatype-timezones"/>.
+ The interval case is only useful for zones that have fixed offsets from
+ UTC, so it is not very common in practice.
+ </para>
+
+ <para>
+ The syntax <literal>AT LOCAL</literal> may be used as shorthand for
+ <literal>AT TIME ZONE <replaceable>local</replaceable></literal>, where
+ <replaceable>local</replaceable> is the session's
+ <varname>TimeZone</varname> value.
+ </para>
+
+ <para>
+ Examples (assuming the current <xref linkend="guc-timezone"/> setting
+ is <literal>America/Los_Angeles</literal>):
+<screen>
+SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/Denver';
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 19:38:40-08</computeroutput>
+SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT TIME ZONE 'America/Denver';
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 18:38:40</computeroutput>
+SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'Asia/Tokyo' AT TIME ZONE 'America/Chicago';
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 05:38:40</computeroutput>
+SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT LOCAL;
+<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 17:38:40</computeroutput>
+SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
+<lineannotation>Result: </lineannotation><computeroutput>17:38:40</computeroutput>
+</screen>
+ The first example adds a time zone to a value that lacks it, and
+ displays the value using the current <varname>TimeZone</varname>
+ setting. The second example shifts the time stamp with time zone value
+ to the specified time zone, and returns the value without a time zone.
+ This allows storage and display of values different from the current
+ <varname>TimeZone</varname> setting. The third example converts
+ Tokyo time to Chicago time. The fourth example shifts the time stamp
+ with time zone value to the time zone currently specified by the
+ <varname>TimeZone</varname> setting and returns the value without a
+ time zone.
+ </para>
+
+ <para>
+ The fifth example is a cautionary tale. Due to the fact that there is no
+ date associated with the input value, the conversion is made using the
+ current date of the session. Therefore, this static example may show a wrong
+ result depending on the time of the year it is viewed because
+ <literal>'America/Los_Angeles'</literal> observes Daylight Savings Time.
+ </para>
+
+ <para>
+ The function <literal><function>timezone</function>(<replaceable>zone</replaceable>,
+ <replaceable>timestamp</replaceable>)</literal> is equivalent to the SQL-conforming construct
+ <literal><replaceable>timestamp</replaceable> AT TIME ZONE
+ <replaceable>zone</replaceable></literal>.
+ </para>
+
+ <para>
+ The function <literal><function>timezone</function>(<replaceable>zone</replaceable>,
+ <replaceable>time</replaceable>)</literal> is equivalent to the SQL-conforming construct
+ <literal><replaceable>time</replaceable> AT TIME ZONE
+ <replaceable>zone</replaceable></literal>.
+ </para>
+
+ <para>
+ The function <literal><function>timezone</function>(<replaceable>timestamp</replaceable>)</literal>
+ is equivalent to the SQL-conforming construct <literal><replaceable>timestamp</replaceable>
+ AT LOCAL</literal>.
+ </para>
+
+ <para>
+ The function <literal><function>timezone</function>(<replaceable>time</replaceable>)</literal>
+ is equivalent to the SQL-conforming construct <literal><replaceable>time</replaceable>
+ AT LOCAL</literal>.
+ </para>
+ </sect2>
+
+ <sect2 id="functions-datetime-current">
+ <title>Current Date/Time</title>
+
+ <indexterm>
+ <primary>date</primary>
+ <secondary>current</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>time</primary>
+ <secondary>current</secondary>
+ </indexterm>
+
+ <para>
+ <productname>PostgreSQL</productname> provides a number of functions
+ that return values related to the current date and time. These
+ SQL-standard functions all return values based on the start time of
+ the current transaction:
+<synopsis>
+CURRENT_DATE
+CURRENT_TIME
+CURRENT_TIMESTAMP
+CURRENT_TIME(<replaceable>precision</replaceable>)
+CURRENT_TIMESTAMP(<replaceable>precision</replaceable>)
+LOCALTIME
+LOCALTIMESTAMP
+LOCALTIME(<replaceable>precision</replaceable>)
+LOCALTIMESTAMP(<replaceable>precision</replaceable>)
+</synopsis>
+ </para>
+
+ <para>
+ <function>CURRENT_TIME</function> and
+ <function>CURRENT_TIMESTAMP</function> deliver values with time zone;
+ <function>LOCALTIME</function> and
+ <function>LOCALTIMESTAMP</function> deliver values without time zone.
+ </para>
+
+ <para>
+ <function>CURRENT_TIME</function>,
+ <function>CURRENT_TIMESTAMP</function>,
+ <function>LOCALTIME</function>, and
+ <function>LOCALTIMESTAMP</function>
+ can optionally take
+ a precision parameter, which causes the result to be rounded
+ to that many fractional digits in the seconds field. Without a precision parameter,
+ the result is given to the full available precision.
+ </para>
+
+ <para>
+ Some examples:
+<screen>
+SELECT CURRENT_TIME;
+<lineannotation>Result: </lineannotation><computeroutput>14:39:53.662522-05</computeroutput>
+SELECT CURRENT_DATE;
+<lineannotation>Result: </lineannotation><computeroutput>2019-12-23</computeroutput>
+SELECT CURRENT_TIMESTAMP;
+<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.662522-05</computeroutput>
+SELECT CURRENT_TIMESTAMP(2);
+<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.66-05</computeroutput>
+SELECT LOCALTIMESTAMP;
+<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.662522</computeroutput>
+</screen>
+ </para>
+
+ <para>
+ Since these functions return
+ the start time of the current transaction, their values do not
+ change during the transaction. This is considered a feature:
+ the intent is to allow a single transaction to have a consistent
+ notion of the <quote>current</quote> time, so that multiple
+ modifications within the same transaction bear the same
+ time stamp.
+ </para>
+
+ <note>
+ <para>
+ Other database systems might advance these values more
+ frequently.
+ </para>
+ </note>
+
+ <para>
+ <productname>PostgreSQL</productname> also provides functions that
+ return the start time of the current statement, as well as the actual
+ current time at the instant the function is called. The complete list
+ of non-SQL-standard time functions is:
+<synopsis>
+transaction_timestamp()
+statement_timestamp()
+clock_timestamp()
+timeofday()
+now()
+</synopsis>
+ </para>
+
+ <para>
+ <function>transaction_timestamp()</function> is equivalent to
+ <function>CURRENT_TIMESTAMP</function>, but is named to clearly reflect
+ what it returns.
+ <function>statement_timestamp()</function> returns the start time of the current
+ statement (more specifically, the time of receipt of the latest command
+ message from the client).
+ <function>statement_timestamp()</function> and <function>transaction_timestamp()</function>
+ return the same value during the first command of a transaction, but might
+ differ during subsequent commands.
+ <function>clock_timestamp()</function> returns the actual current time, and
+ therefore its value changes even within a single SQL command.
+ <function>timeofday()</function> is a historical
+ <productname>PostgreSQL</productname> function. Like
+ <function>clock_timestamp()</function>, it returns the actual current time,
+ but as a formatted <type>text</type> string rather than a <type>timestamp
+ with time zone</type> value.
+ <function>now()</function> is a traditional <productname>PostgreSQL</productname>
+ equivalent to <function>transaction_timestamp()</function>.
+ </para>
+
+ <para>
+ All the date/time data types also accept the special literal value
+ <literal>now</literal> to specify the current date and time (again,
+ interpreted as the transaction start time). Thus,
+ the following three all return the same result:
+<programlisting>
+SELECT CURRENT_TIMESTAMP;
+SELECT now();
+SELECT TIMESTAMP 'now'; -- but see tip below
+</programlisting>
+ </para>
+
+ <tip>
+ <para>
+ Do not use the third form when specifying a value to be evaluated later,
+ for example in a <literal>DEFAULT</literal> clause for a table column.
+ The system will convert <literal>now</literal>
+ to a <type>timestamp</type> as soon as the constant is parsed, so that when
+ the default value is needed,
+ the time of the table creation would be used! The first two
+ forms will not be evaluated until the default value is used,
+ because they are function calls. Thus they will give the desired
+ behavior of defaulting to the time of row insertion.
+ (See also <xref linkend="datatype-datetime-special-values"/>.)
+ </para>
+ </tip>
+ </sect2>
+
+ <sect2 id="functions-datetime-delay">
+ <title>Delaying Execution</title>
+
+ <indexterm>
+ <primary>pg_sleep</primary>
+ </indexterm>
+ <indexterm>
+ <primary>pg_sleep_for</primary>
+ </indexterm>
+ <indexterm>
+ <primary>pg_sleep_until</primary>
+ </indexterm>
+ <indexterm>
+ <primary>sleep</primary>
+ </indexterm>
+ <indexterm>
+ <primary>delay</primary>
+ </indexterm>
+
+ <para>
+ The following functions are available to delay execution of the server
+ process:
+<synopsis>
+pg_sleep ( <type>double precision</type> )
+pg_sleep_for ( <type>interval</type> )
+pg_sleep_until ( <type>timestamp with time zone</type> )
+</synopsis>
+
+ <function>pg_sleep</function> makes the current session's process
+ sleep until the given number of seconds have
+ elapsed. Fractional-second delays can be specified.
+ <function>pg_sleep_for</function> is a convenience function to
+ allow the sleep time to be specified as an <type>interval</type>.
+ <function>pg_sleep_until</function> is a convenience function for when
+ a specific wake-up time is desired.
+ For example:
+
+<programlisting>
+SELECT pg_sleep(1.5);
+SELECT pg_sleep_for('5 minutes');
+SELECT pg_sleep_until('tomorrow 03:00');
+</programlisting>
+ </para>
+
+ <note>
+ <para>
+ The effective resolution of the sleep interval is platform-specific;
+ 0.01 seconds is a common value. The sleep delay will be at least as long
+ as specified. It might be longer depending on factors such as server load.
+ In particular, <function>pg_sleep_until</function> is not guaranteed to
+ wake up exactly at the specified time, but it will not wake up any earlier.
+ </para>
+ </note>
+
+ <warning>
+ <para>
+ Make sure that your session does not hold more locks than necessary
+ when calling <function>pg_sleep</function> or its variants. Otherwise
+ other sessions might have to wait for your sleeping process, slowing down
+ the entire system.
+ </para>
+ </warning>
+ </sect2>
+
+ </sect1>
\ No newline at end of file
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index a49f212d..ca33edc7 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -4735,2192 +4735,7 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
</sect1>
-
- <sect1 id="functions-datetime">
- <title>Date/Time Functions and Operators</title>
-
- <para>
- <xref linkend="functions-datetime-table"/> shows the available
- functions for date/time value processing, with details appearing in
- the following subsections. <xref
- linkend="operators-datetime-table"/> illustrates the behaviors of
- the basic arithmetic operators (<literal>+</literal>,
- <literal>*</literal>, etc.). For formatting functions, refer to
- <xref linkend="functions-formatting"/>. You should be familiar with
- the background information on date/time data types from <xref
- linkend="datatype-datetime"/>.
- </para>
-
- <para>
- In addition, the usual comparison operators shown in
- <xref linkend="functions-comparison-op-table"/> are available for the
- date/time types. Dates and timestamps (with or without time zone) are
- all comparable, while times (with or without time zone) and intervals
- can only be compared to other values of the same data type. When
- comparing a timestamp without time zone to a timestamp with time zone,
- the former value is assumed to be given in the time zone specified by
- the <xref linkend="guc-timezone"/> configuration parameter, and is
- rotated to UTC for comparison to the latter value (which is already
- in UTC internally). Similarly, a date value is assumed to represent
- midnight in the <varname>TimeZone</varname> zone when comparing it
- to a timestamp.
- </para>
-
- <para>
- All the functions and operators described below that take <type>time</type> or <type>timestamp</type>
- inputs actually come in two variants: one that takes <type>time with time zone</type> or <type>timestamp
- with time zone</type>, and one that takes <type>time without time zone</type> or <type>timestamp without time zone</type>.
- For brevity, these variants are not shown separately. Also, the
- <literal>+</literal> and <literal>*</literal> operators come in commutative pairs (for
- example both <type>date</type> <literal>+</literal> <type>integer</type>
- and <type>integer</type> <literal>+</literal> <type>date</type>); we show
- only one of each such pair.
- </para>
-
- <table id="operators-datetime-table">
- <title>Date/Time Operators</title>
-
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>+</literal> <type>integer</type>
- <returnvalue>date</returnvalue>
- </para>
- <para>
- Add a number of days to a date
- </para>
- <para>
- <literal>date '2001-09-28' + 7</literal>
- <returnvalue>2001-10-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>+</literal> <type>interval</type>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Add an interval to a date
- </para>
- <para>
- <literal>date '2001-09-28' + interval '1 hour'</literal>
- <returnvalue>2001-09-28 01:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>+</literal> <type>time</type>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Add a time-of-day to a date
- </para>
- <para>
- <literal>date '2001-09-28' + time '03:00'</literal>
- <returnvalue>2001-09-28 03:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>interval</type> <literal>+</literal> <type>interval</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Add intervals
- </para>
- <para>
- <literal>interval '1 day' + interval '1 hour'</literal>
- <returnvalue>1 day 01:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp</type> <literal>+</literal> <type>interval</type>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Add an interval to a timestamp
- </para>
- <para>
- <literal>timestamp '2001-09-28 01:00' + interval '23 hours'</literal>
- <returnvalue>2001-09-29 00:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>time</type> <literal>+</literal> <type>interval</type>
- <returnvalue>time</returnvalue>
- </para>
- <para>
- Add an interval to a time
- </para>
- <para>
- <literal>time '01:00' + interval '3 hours'</literal>
- <returnvalue>04:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <literal>-</literal> <type>interval</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Negate an interval
- </para>
- <para>
- <literal>- interval '23 hours'</literal>
- <returnvalue>-23:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>-</literal> <type>date</type>
- <returnvalue>integer</returnvalue>
- </para>
- <para>
- Subtract dates, producing the number of days elapsed
- </para>
- <para>
- <literal>date '2001-10-01' - date '2001-09-28'</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>-</literal> <type>integer</type>
- <returnvalue>date</returnvalue>
- </para>
- <para>
- Subtract a number of days from a date
- </para>
- <para>
- <literal>date '2001-10-01' - 7</literal>
- <returnvalue>2001-09-24</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>date</type> <literal>-</literal> <type>interval</type>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Subtract an interval from a date
- </para>
- <para>
- <literal>date '2001-09-28' - interval '1 hour'</literal>
- <returnvalue>2001-09-27 23:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>time</type> <literal>-</literal> <type>time</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Subtract times
- </para>
- <para>
- <literal>time '05:00' - time '03:00'</literal>
- <returnvalue>02:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>time</type> <literal>-</literal> <type>interval</type>
- <returnvalue>time</returnvalue>
- </para>
- <para>
- Subtract an interval from a time
- </para>
- <para>
- <literal>time '05:00' - interval '2 hours'</literal>
- <returnvalue>03:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp</type> <literal>-</literal> <type>interval</type>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Subtract an interval from a timestamp
- </para>
- <para>
- <literal>timestamp '2001-09-28 23:00' - interval '23 hours'</literal>
- <returnvalue>2001-09-28 00:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>interval</type> <literal>-</literal> <type>interval</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Subtract intervals
- </para>
- <para>
- <literal>interval '1 day' - interval '1 hour'</literal>
- <returnvalue>1 day -01:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp</type> <literal>-</literal> <type>timestamp</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Subtract timestamps (converting 24-hour intervals into days,
- similarly to <link
- linkend="function-justify-hours"><function>justify_hours()</function></link>)
- </para>
- <para>
- <literal>timestamp '2001-09-29 03:00' - timestamp '2001-07-27 12:00'</literal>
- <returnvalue>63 days 15:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>interval</type> <literal>*</literal> <type>double precision</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Multiply an interval by a scalar
- </para>
- <para>
- <literal>interval '1 second' * 900</literal>
- <returnvalue>00:15:00</returnvalue>
- </para>
- <para>
- <literal>interval '1 day' * 21</literal>
- <returnvalue>21 days</returnvalue>
- </para>
- <para>
- <literal>interval '1 hour' * 3.5</literal>
- <returnvalue>03:30:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>interval</type> <literal>/</literal> <type>double precision</type>
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Divide an interval by a scalar
- </para>
- <para>
- <literal>interval '1 hour' / 1.5</literal>
- <returnvalue>00:40:00</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <table id="functions-datetime-table">
- <title>Date/Time Functions</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Function
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>age</primary>
- </indexterm>
- <function>age</function> ( <type>timestamp</type>, <type>timestamp</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Subtract arguments, producing a <quote>symbolic</quote> result that
- uses years and months, rather than just days
- </para>
- <para>
- <literal>age(timestamp '2001-04-10', timestamp '1957-06-13')</literal>
- <returnvalue>43 years 9 mons 27 days</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>age</function> ( <type>timestamp</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Subtract argument from <function>current_date</function> (at midnight)
- </para>
- <para>
- <literal>age(timestamp '1957-06-13')</literal>
- <returnvalue>62 years 6 mons 10 days</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>clock_timestamp</primary>
- </indexterm>
- <function>clock_timestamp</function> ( )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (changes during statement execution);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>clock_timestamp()</literal>
- <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_date</primary>
- </indexterm>
- <function>current_date</function>
- <returnvalue>date</returnvalue>
- </para>
- <para>
- Current date; see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>current_date</literal>
- <returnvalue>2019-12-23</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_time</primary>
- </indexterm>
- <function>current_time</function>
- <returnvalue>time with time zone</returnvalue>
- </para>
- <para>
- Current time of day; see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>current_time</literal>
- <returnvalue>14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>current_time</function> ( <type>integer</type> )
- <returnvalue>time with time zone</returnvalue>
- </para>
- <para>
- Current time of day, with limited precision;
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>current_time(2)</literal>
- <returnvalue>14:39:53.66-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>current_timestamp</primary>
- </indexterm>
- <function>current_timestamp</function>
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (start of current transaction);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>current_timestamp</literal>
- <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>current_timestamp</function> ( <type>integer</type> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (start of current transaction), with limited precision;
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>current_timestamp(0)</literal>
- <returnvalue>2019-12-23 14:39:53-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>date_add</primary>
- </indexterm>
- <function>date_add</function> ( <type>timestamp with time zone</type>, <type>interval</type> <optional>, <type>text</type> </optional> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Add an <type>interval</type> to a <type>timestamp with time
- zone</type>, computing times of day and daylight-savings adjustments
- according to the time zone named by the third argument, or the
- current <xref linkend="guc-timezone"/> setting if that is omitted.
- The form with two arguments is equivalent to the <type>timestamp with
- time zone</type> <literal>+</literal> <type>interval</type> operator.
- </para>
- <para>
- <literal>date_add('2021-10-31 00:00:00+02'::timestamptz, '1 day'::interval, 'Europe/Warsaw')</literal>
- <returnvalue>2021-10-31 23:00:00+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>date_bin</function> ( <type>interval</type>, <type>timestamp</type>, <type>timestamp</type> )
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Bin input into specified interval aligned with specified origin; see <xref linkend="functions-datetime-bin"/>
- </para>
- <para>
- <literal>date_bin('15 minutes', timestamp '2001-02-16 20:38:40', timestamp '2001-02-16 20:05:00')</literal>
- <returnvalue>2001-02-16 20:35:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>date_part</primary>
- </indexterm>
- <function>date_part</function> ( <type>text</type>, <type>timestamp</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Get timestamp subfield (equivalent to <function>extract</function>);
- see <xref linkend="functions-datetime-extract"/>
- </para>
- <para>
- <literal>date_part('hour', timestamp '2001-02-16 20:38:40')</literal>
- <returnvalue>20</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>date_part</function> ( <type>text</type>, <type>interval</type> )
- <returnvalue>double precision</returnvalue>
- </para>
- <para>
- Get interval subfield (equivalent to <function>extract</function>);
- see <xref linkend="functions-datetime-extract"/>
- </para>
- <para>
- <literal>date_part('month', interval '2 years 3 months')</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>date_subtract</primary>
- </indexterm>
- <function>date_subtract</function> ( <type>timestamp with time zone</type>, <type>interval</type> <optional>, <type>text</type> </optional> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Subtract an <type>interval</type> from a <type>timestamp with time
- zone</type>, computing times of day and daylight-savings adjustments
- according to the time zone named by the third argument, or the
- current <xref linkend="guc-timezone"/> setting if that is omitted.
- The form with two arguments is equivalent to the <type>timestamp with
- time zone</type> <literal>-</literal> <type>interval</type> operator.
- </para>
- <para>
- <literal>date_subtract('2021-11-01 00:00:00+01'::timestamptz, '1 day'::interval, 'Europe/Warsaw')</literal>
- <returnvalue>2021-10-30 22:00:00+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>date_trunc</primary>
- </indexterm>
- <function>date_trunc</function> ( <type>text</type>, <type>timestamp</type> )
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Truncate to specified precision; see <xref linkend="functions-datetime-trunc"/>
- </para>
- <para>
- <literal>date_trunc('hour', timestamp '2001-02-16 20:38:40')</literal>
- <returnvalue>2001-02-16 20:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>date_trunc</function> ( <type>text</type>, <type>timestamp with time zone</type>, <type>text</type> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Truncate to specified precision in the specified time zone; see
- <xref linkend="functions-datetime-trunc"/>
- </para>
- <para>
- <literal>date_trunc('day', timestamptz '2001-02-16 20:38:40+00', 'Australia/Sydney')</literal>
- <returnvalue>2001-02-16 13:00:00+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>date_trunc</function> ( <type>text</type>, <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Truncate to specified precision; see
- <xref linkend="functions-datetime-trunc"/>
- </para>
- <para>
- <literal>date_trunc('hour', interval '2 days 3 hours 40 minutes')</literal>
- <returnvalue>2 days 03:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>extract</primary>
- </indexterm>
- <function>extract</function> ( <parameter>field</parameter> <literal>from</literal> <type>timestamp</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para>
- Get timestamp subfield; see <xref linkend="functions-datetime-extract"/>
- </para>
- <para>
- <literal>extract(hour from timestamp '2001-02-16 20:38:40')</literal>
- <returnvalue>20</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>extract</function> ( <parameter>field</parameter> <literal>from</literal> <type>interval</type> )
- <returnvalue>numeric</returnvalue>
- </para>
- <para>
- Get interval subfield; see <xref linkend="functions-datetime-extract"/>
- </para>
- <para>
- <literal>extract(month from interval '2 years 3 months')</literal>
- <returnvalue>3</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>isfinite</primary>
- </indexterm>
- <function>isfinite</function> ( <type>date</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Test for finite date (not +/-infinity)
- </para>
- <para>
- <literal>isfinite(date '2001-02-16')</literal>
- <returnvalue>true</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>isfinite</function> ( <type>timestamp</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Test for finite timestamp (not +/-infinity)
- </para>
- <para>
- <literal>isfinite(timestamp 'infinity')</literal>
- <returnvalue>false</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>isfinite</function> ( <type>interval</type> )
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- Test for finite interval (not +/-infinity)
- </para>
- <para>
- <literal>isfinite(interval '4 hours')</literal>
- <returnvalue>true</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm id="function-justify-days">
- <primary>justify_days</primary>
- </indexterm>
- <function>justify_days</function> ( <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Adjust interval, converting 30-day time periods to months
- </para>
- <para>
- <literal>justify_days(interval '1 year 65 days')</literal>
- <returnvalue>1 year 2 mons 5 days</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm id="function-justify-hours">
- <primary>justify_hours</primary>
- </indexterm>
- <function>justify_hours</function> ( <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Adjust interval, converting 24-hour time periods to days
- </para>
- <para>
- <literal>justify_hours(interval '50 hours 10 minutes')</literal>
- <returnvalue>2 days 02:10:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>justify_interval</primary>
- </indexterm>
- <function>justify_interval</function> ( <type>interval</type> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Adjust interval using <function>justify_days</function>
- and <function>justify_hours</function>, with additional sign
- adjustments
- </para>
- <para>
- <literal>justify_interval(interval '1 mon -1 hour')</literal>
- <returnvalue>29 days 23:00:00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>localtime</primary>
- </indexterm>
- <function>localtime</function>
- <returnvalue>time</returnvalue>
- </para>
- <para>
- Current time of day;
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>localtime</literal>
- <returnvalue>14:39:53.662522</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>localtime</function> ( <type>integer</type> )
- <returnvalue>time</returnvalue>
- </para>
- <para>
- Current time of day, with limited precision;
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>localtime(0)</literal>
- <returnvalue>14:39:53</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>localtimestamp</primary>
- </indexterm>
- <function>localtimestamp</function>
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Current date and time (start of current transaction);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>localtimestamp</literal>
- <returnvalue>2019-12-23 14:39:53.662522</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <function>localtimestamp</function> ( <type>integer</type> )
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Current date and time (start of current
- transaction), with limited precision;
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>localtimestamp(2)</literal>
- <returnvalue>2019-12-23 14:39:53.66</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>make_date</primary>
- </indexterm>
- <function>make_date</function> ( <parameter>year</parameter> <type>int</type>,
- <parameter>month</parameter> <type>int</type>,
- <parameter>day</parameter> <type>int</type> )
- <returnvalue>date</returnvalue>
- </para>
- <para>
- Create date from year, month and day fields
- (negative years signify BC)
- </para>
- <para>
- <literal>make_date(2013, 7, 15)</literal>
- <returnvalue>2013-07-15</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature"><indexterm>
- <primary>make_interval</primary>
- </indexterm>
- <function>make_interval</function> ( <optional> <parameter>years</parameter> <type>int</type>
- <optional>, <parameter>months</parameter> <type>int</type>
- <optional>, <parameter>weeks</parameter> <type>int</type>
- <optional>, <parameter>days</parameter> <type>int</type>
- <optional>, <parameter>hours</parameter> <type>int</type>
- <optional>, <parameter>mins</parameter> <type>int</type>
- <optional>, <parameter>secs</parameter> <type>double precision</type>
- </optional></optional></optional></optional></optional></optional></optional> )
- <returnvalue>interval</returnvalue>
- </para>
- <para>
- Create interval from years, months, weeks, days, hours, minutes and
- seconds fields, each of which can default to zero
- </para>
- <para>
- <literal>make_interval(days => 10)</literal>
- <returnvalue>10 days</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>make_time</primary>
- </indexterm>
- <function>make_time</function> ( <parameter>hour</parameter> <type>int</type>,
- <parameter>min</parameter> <type>int</type>,
- <parameter>sec</parameter> <type>double precision</type> )
- <returnvalue>time</returnvalue>
- </para>
- <para>
- Create time from hour, minute and seconds fields
- </para>
- <para>
- <literal>make_time(8, 15, 23.5)</literal>
- <returnvalue>08:15:23.5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>make_timestamp</primary>
- </indexterm>
- <function>make_timestamp</function> ( <parameter>year</parameter> <type>int</type>,
- <parameter>month</parameter> <type>int</type>,
- <parameter>day</parameter> <type>int</type>,
- <parameter>hour</parameter> <type>int</type>,
- <parameter>min</parameter> <type>int</type>,
- <parameter>sec</parameter> <type>double precision</type> )
- <returnvalue>timestamp</returnvalue>
- </para>
- <para>
- Create timestamp from year, month, day, hour, minute and seconds fields
- (negative years signify BC)
- </para>
- <para>
- <literal>make_timestamp(2013, 7, 15, 8, 15, 23.5)</literal>
- <returnvalue>2013-07-15 08:15:23.5</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>make_timestamptz</primary>
- </indexterm>
- <function>make_timestamptz</function> ( <parameter>year</parameter> <type>int</type>,
- <parameter>month</parameter> <type>int</type>,
- <parameter>day</parameter> <type>int</type>,
- <parameter>hour</parameter> <type>int</type>,
- <parameter>min</parameter> <type>int</type>,
- <parameter>sec</parameter> <type>double precision</type>
- <optional>, <parameter>timezone</parameter> <type>text</type> </optional> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Create timestamp with time zone from year, month, day, hour, minute
- and seconds fields (negative years signify BC).
- If <parameter>timezone</parameter> is not
- specified, the current time zone is used; the examples assume the
- session time zone is <literal>Europe/London</literal>
- </para>
- <para>
- <literal>make_timestamptz(2013, 7, 15, 8, 15, 23.5)</literal>
- <returnvalue>2013-07-15 08:15:23.5+01</returnvalue>
- </para>
- <para>
- <literal>make_timestamptz(2013, 7, 15, 8, 15, 23.5, 'America/New_York')</literal>
- <returnvalue>2013-07-15 13:15:23.5+01</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>now</primary>
- </indexterm>
- <function>now</function> ( )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (start of current transaction);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>now()</literal>
- <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>statement_timestamp</primary>
- </indexterm>
- <function>statement_timestamp</function> ( )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (start of current statement);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>statement_timestamp()</literal>
- <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>timeofday</primary>
- </indexterm>
- <function>timeofday</function> ( )
- <returnvalue>text</returnvalue>
- </para>
- <para>
- Current date and time
- (like <function>clock_timestamp</function>, but as a <type>text</type> string);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>timeofday()</literal>
- <returnvalue>Mon Dec 23 14:39:53.662522 2019 EST</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>transaction_timestamp</primary>
- </indexterm>
- <function>transaction_timestamp</function> ( )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Current date and time (start of current transaction);
- see <xref linkend="functions-datetime-current"/>
- </para>
- <para>
- <literal>transaction_timestamp()</literal>
- <returnvalue>2019-12-23 14:39:53.662522-05</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <indexterm>
- <primary>to_timestamp</primary>
- </indexterm>
- <function>to_timestamp</function> ( <type>double precision</type> )
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Convert Unix epoch (seconds since 1970-01-01 00:00:00+00) to
- timestamp with time zone
- </para>
- <para>
- <literal>to_timestamp(1284352323)</literal>
- <returnvalue>2010-09-13 04:32:03+00</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <indexterm>
- <primary>OVERLAPS</primary>
- </indexterm>
- In addition to these functions, the SQL <literal>OVERLAPS</literal> operator is
- supported:
-<synopsis>
-(<replaceable>start1</replaceable>, <replaceable>end1</replaceable>) OVERLAPS (<replaceable>start2</replaceable>, <replaceable>end2</replaceable>)
-(<replaceable>start1</replaceable>, <replaceable>length1</replaceable>) OVERLAPS (<replaceable>start2</replaceable>, <replaceable>length2</replaceable>)
-</synopsis>
- This expression yields true when two time periods (defined by their
- endpoints) overlap, false when they do not overlap. The endpoints
- can be specified as pairs of dates, times, or time stamps; or as
- a date, time, or time stamp followed by an interval. When a pair
- of values is provided, either the start or the end can be written
- first; <literal>OVERLAPS</literal> automatically takes the earlier value
- of the pair as the start. Each time period is considered to
- represent the half-open interval <replaceable>start</replaceable> <literal><=</literal>
- <replaceable>time</replaceable> <literal><</literal> <replaceable>end</replaceable>, unless
- <replaceable>start</replaceable> and <replaceable>end</replaceable> are equal in which case it
- represents that single time instant. This means for instance that two
- time periods with only an endpoint in common do not overlap.
- </para>
-
-<screen>
-SELECT (DATE '2001-02-16', DATE '2001-12-21') OVERLAPS
- (DATE '2001-10-30', DATE '2002-10-30');
-<lineannotation>Result: </lineannotation><computeroutput>true</computeroutput>
-SELECT (DATE '2001-02-16', INTERVAL '100 days') OVERLAPS
- (DATE '2001-10-30', DATE '2002-10-30');
-<lineannotation>Result: </lineannotation><computeroutput>false</computeroutput>
-SELECT (DATE '2001-10-29', DATE '2001-10-30') OVERLAPS
- (DATE '2001-10-30', DATE '2001-10-31');
-<lineannotation>Result: </lineannotation><computeroutput>false</computeroutput>
-SELECT (DATE '2001-10-30', DATE '2001-10-30') OVERLAPS
- (DATE '2001-10-30', DATE '2001-10-31');
-<lineannotation>Result: </lineannotation><computeroutput>true</computeroutput>
-</screen>
-
- <para>
- When adding an <type>interval</type> value to (or subtracting an
- <type>interval</type> value from) a <type>timestamp</type>
- or <type>timestamp with time zone</type> value, the months, days, and
- microseconds fields of the <type>interval</type> value are handled in turn.
- First, a nonzero months field advances or decrements the date of the
- timestamp by the indicated number of months, keeping the day of month the
- same unless it would be past the end of the new month, in which case the
- last day of that month is used. (For example, March 31 plus 1 month
- becomes April 30, but March 31 plus 2 months becomes May 31.)
- Then the days field advances or decrements the date of the timestamp by
- the indicated number of days. In both these steps the local time of day
- is kept the same. Finally, if there is a nonzero microseconds field, it
- is added or subtracted literally.
- When doing arithmetic on a <type>timestamp with time zone</type> value in
- a time zone that recognizes DST, this means that adding or subtracting
- (say) <literal>interval '1 day'</literal> does not necessarily have the
- same result as adding or subtracting <literal>interval '24
- hours'</literal>.
- For example, with the session time zone set
- to <literal>America/Denver</literal>:
-<screen>
-SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '1 day';
-<lineannotation>Result: </lineannotation><computeroutput>2005-04-03 12:00:00-06</computeroutput>
-SELECT timestamp with time zone '2005-04-02 12:00:00-07' + interval '24 hours';
-<lineannotation>Result: </lineannotation><computeroutput>2005-04-03 13:00:00-06</computeroutput>
-</screen>
- This happens because an hour was skipped due to a change in daylight saving
- time at <literal>2005-04-03 02:00:00</literal> in time zone
- <literal>America/Denver</literal>.
- </para>
-
- <para>
- Note there can be ambiguity in the <literal>months</literal> field returned by
- <function>age</function> because different months have different numbers of
- days. <productname>PostgreSQL</productname>'s approach uses the month from the
- earlier of the two dates when calculating partial months. For example,
- <literal>age('2004-06-01', '2004-04-30')</literal> uses April to yield
- <literal>1 mon 1 day</literal>, while using May would yield <literal>1 mon 2
- days</literal> because May has 31 days, while April has only 30.
- </para>
-
- <para>
- Subtraction of dates and timestamps can also be complex. One conceptually
- simple way to perform subtraction is to convert each value to a number
- of seconds using <literal>EXTRACT(EPOCH FROM ...)</literal>, then subtract the
- results; this produces the
- number of <emphasis>seconds</emphasis> between the two values. This will adjust
- for the number of days in each month, timezone changes, and daylight
- saving time adjustments. Subtraction of date or timestamp
- values with the <quote><literal>-</literal></quote> operator
- returns the number of days (24-hours) and hours/minutes/seconds
- between the values, making the same adjustments. The <function>age</function>
- function returns years, months, days, and hours/minutes/seconds,
- performing field-by-field subtraction and then adjusting for negative
- field values. The following queries illustrate the differences in these
- approaches. The sample results were produced with <literal>timezone
- = 'US/Eastern'</literal>; there is a daylight saving time change between the
- two dates used:
- </para>
-
-<screen>
-SELECT EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
- EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00');
-<lineannotation>Result: </lineannotation><computeroutput>10537200.000000</computeroutput>
-SELECT (EXTRACT(EPOCH FROM timestamptz '2013-07-01 12:00:00') -
- EXTRACT(EPOCH FROM timestamptz '2013-03-01 12:00:00'))
- / 60 / 60 / 24;
-<lineannotation>Result: </lineannotation><computeroutput>121.9583333333333333</computeroutput>
-SELECT timestamptz '2013-07-01 12:00:00' - timestamptz '2013-03-01 12:00:00';
-<lineannotation>Result: </lineannotation><computeroutput>121 days 23:00:00</computeroutput>
-SELECT age(timestamptz '2013-07-01 12:00:00', timestamptz '2013-03-01 12:00:00');
-<lineannotation>Result: </lineannotation><computeroutput>4 mons</computeroutput>
-</screen>
-
- <sect2 id="functions-datetime-extract">
- <title><function>EXTRACT</function>, <function>date_part</function></title>
-
- <indexterm>
- <primary>date_part</primary>
- </indexterm>
- <indexterm>
- <primary>extract</primary>
- </indexterm>
-
-<synopsis>
-EXTRACT(<replaceable>field</replaceable> FROM <replaceable>source</replaceable>)
-</synopsis>
-
- <para>
- The <function>extract</function> function retrieves subfields
- such as year or hour from date/time values.
- <replaceable>source</replaceable> must be a value expression of
- type <type>timestamp</type>, <type>date</type>, <type>time</type>,
- or <type>interval</type>. (Timestamps and times can be with or
- without time zone.)
- <replaceable>field</replaceable> is an identifier or
- string that selects what field to extract from the source value.
- Not all fields are valid for every input data type; for example, fields
- smaller than a day cannot be extracted from a <type>date</type>, while
- fields of a day or more cannot be extracted from a <type>time</type>.
- The <function>extract</function> function returns values of type
- <type>numeric</type>.
- </para>
-
- <para>
- The following are valid field names:
-
- <!-- alphabetical -->
- <variablelist>
- <varlistentry>
- <term><literal>century</literal></term>
- <listitem>
- <para>
- The century; for <type>interval</type> values, the year field
- divided by 100
- </para>
-
-<screen>
-SELECT EXTRACT(CENTURY FROM TIMESTAMP '2000-12-16 12:21:13');
-<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
-SELECT EXTRACT(CENTURY FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>21</computeroutput>
-SELECT EXTRACT(CENTURY FROM DATE '0001-01-01 AD');
-<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
-SELECT EXTRACT(CENTURY FROM DATE '0001-12-31 BC');
-<lineannotation>Result: </lineannotation><computeroutput>-1</computeroutput>
-SELECT EXTRACT(CENTURY FROM INTERVAL '2001 years');
-<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>day</literal></term>
- <listitem>
- <para>
- The day of the month (1–31); for <type>interval</type>
- values, the number of days
- </para>
-
-<screen>
-SELECT EXTRACT(DAY FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>16</computeroutput>
-SELECT EXTRACT(DAY FROM INTERVAL '40 days 1 minute');
-<lineannotation>Result: </lineannotation><computeroutput>40</computeroutput>
-</screen>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>decade</literal></term>
- <listitem>
- <para>
- The year field divided by 10
- </para>
-
-<screen>
-SELECT EXTRACT(DECADE FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>200</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>dow</literal></term>
- <listitem>
- <para>
- The day of the week as Sunday (<literal>0</literal>) to
- Saturday (<literal>6</literal>)
- </para>
-
-<screen>
-SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>5</computeroutput>
-</screen>
- <para>
- Note that <function>extract</function>'s day of the week numbering
- differs from that of the <function>to_char(...,
- 'D')</function> function.
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>doy</literal></term>
- <listitem>
- <para>
- The day of the year (1–365/366)
- </para>
-
-<screen>
-SELECT EXTRACT(DOY FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>47</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>epoch</literal></term>
- <listitem>
- <para>
- For <type>timestamp with time zone</type> values, the
- number of seconds since 1970-01-01 00:00:00 UTC (negative for
- timestamps before that);
- for <type>date</type> and <type>timestamp</type> values, the
- nominal number of seconds since 1970-01-01 00:00:00,
- without regard to timezone or daylight-savings rules;
- for <type>interval</type> values, the total number
- of seconds in the interval
- </para>
-
-<screen>
-SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40.12-08');
-<lineannotation>Result: </lineannotation><computeroutput>982384720.120000</computeroutput>
-SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40.12');
-<lineannotation>Result: </lineannotation><computeroutput>982355920.120000</computeroutput>
-SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours');
-<lineannotation>Result: </lineannotation><computeroutput>442800.000000</computeroutput>
-</screen>
-
- <para>
- You can convert an epoch value back to a <type>timestamp with time zone</type>
- with <function>to_timestamp</function>:
- </para>
-<screen>
-SELECT to_timestamp(982384720.12);
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-17 04:38:40.12+00</computeroutput>
-</screen>
-
- <para>
- Beware that applying <function>to_timestamp</function> to an epoch
- extracted from a <type>date</type> or <type>timestamp</type> value
- could produce a misleading result: the result will effectively
- assume that the original value had been given in UTC, which might
- not be the case.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>hour</literal></term>
- <listitem>
- <para>
- The hour field (0–23 in timestamps, unrestricted in
- intervals)
- </para>
-
-<screen>
-SELECT EXTRACT(HOUR FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>isodow</literal></term>
- <listitem>
- <para>
- The day of the week as Monday (<literal>1</literal>) to
- Sunday (<literal>7</literal>)
- </para>
-
-<screen>
-SELECT EXTRACT(ISODOW FROM TIMESTAMP '2001-02-18 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>7</computeroutput>
-</screen>
- <para>
- This is identical to <literal>dow</literal> except for Sunday. This
- matches the <acronym>ISO</acronym> 8601 day of the week numbering.
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>isoyear</literal></term>
- <listitem>
- <para>
- The <acronym>ISO</acronym> 8601 week-numbering year that the date
- falls in
- </para>
-
-<screen>
-SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-01');
-<lineannotation>Result: </lineannotation><computeroutput>2005</computeroutput>
-SELECT EXTRACT(ISOYEAR FROM DATE '2006-01-02');
-<lineannotation>Result: </lineannotation><computeroutput>2006</computeroutput>
-</screen>
-
- <para>
- Each <acronym>ISO</acronym> 8601 week-numbering year begins with the
- Monday of the week containing the 4th of January, so in early
- January or late December the <acronym>ISO</acronym> year may be
- different from the Gregorian year. See the <literal>week</literal>
- field for more information.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>julian</literal></term>
- <listitem>
- <para>
- The <firstterm>Julian Date</firstterm> corresponding to the
- date or timestamp. Timestamps
- that are not local midnight result in a fractional value. See
- <xref linkend="datetime-julian-dates"/> for more information.
- </para>
-
-<screen>
-SELECT EXTRACT(JULIAN FROM DATE '2006-01-01');
-<lineannotation>Result: </lineannotation><computeroutput>2453737</computeroutput>
-SELECT EXTRACT(JULIAN FROM TIMESTAMP '2006-01-01 12:00');
-<lineannotation>Result: </lineannotation><computeroutput>2453737.50000000000000000000</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>microseconds</literal></term>
- <listitem>
- <para>
- The seconds field, including fractional parts, multiplied by 1
- 000 000; note that this includes full seconds
- </para>
-
-<screen>
-SELECT EXTRACT(MICROSECONDS FROM TIME '17:12:28.5');
-<lineannotation>Result: </lineannotation><computeroutput>28500000</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>millennium</literal></term>
- <listitem>
- <para>
- The millennium; for <type>interval</type> values, the year field
- divided by 1000
- </para>
-
-<screen>
-SELECT EXTRACT(MILLENNIUM FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>3</computeroutput>
-SELECT EXTRACT(MILLENNIUM FROM INTERVAL '2001 years');
-<lineannotation>Result: </lineannotation><computeroutput>2</computeroutput>
-</screen>
-
- <para>
- Years in the 1900s are in the second millennium.
- The third millennium started January 1, 2001.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>milliseconds</literal></term>
- <listitem>
- <para>
- The seconds field, including fractional parts, multiplied by
- 1000. Note that this includes full seconds.
- </para>
-
-<screen>
-SELECT EXTRACT(MILLISECONDS FROM TIME '17:12:28.5');
-<lineannotation>Result: </lineannotation><computeroutput>28500.000</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>minute</literal></term>
- <listitem>
- <para>
- The minutes field (0–59)
- </para>
-
-<screen>
-SELECT EXTRACT(MINUTE FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>38</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>month</literal></term>
- <listitem>
- <para>
- The number of the month within the year (1–12);
- for <type>interval</type> values, the number of months modulo 12
- (0–11)
- </para>
-
-<screen>
-SELECT EXTRACT(MONTH FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>2</computeroutput>
-SELECT EXTRACT(MONTH FROM INTERVAL '2 years 3 months');
-<lineannotation>Result: </lineannotation><computeroutput>3</computeroutput>
-SELECT EXTRACT(MONTH FROM INTERVAL '2 years 13 months');
-<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>quarter</literal></term>
- <listitem>
- <para>
- The quarter of the year (1–4) that the date is in
- </para>
-
-<screen>
-SELECT EXTRACT(QUARTER FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>second</literal></term>
- <listitem>
- <para>
- The seconds field, including any fractional seconds
- </para>
-
-<screen>
-SELECT EXTRACT(SECOND FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>40.000000</computeroutput>
-SELECT EXTRACT(SECOND FROM TIME '17:12:28.5');
-<lineannotation>Result: </lineannotation><computeroutput>28.500000</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>timezone</literal></term>
- <listitem>
- <para>
- The time zone offset from UTC, measured in seconds. Positive values
- correspond to time zones east of UTC, negative values to
- zones west of UTC. (Technically,
- <productname>PostgreSQL</productname> does not use UTC because
- leap seconds are not handled.)
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>timezone_hour</literal></term>
- <listitem>
- <para>
- The hour component of the time zone offset
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>timezone_minute</literal></term>
- <listitem>
- <para>
- The minute component of the time zone offset
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>week</literal></term>
- <listitem>
- <para>
- The number of the <acronym>ISO</acronym> 8601 week-numbering week of
- the year. By definition, ISO weeks start on Mondays and the first
- week of a year contains January 4 of that year. In other words, the
- first Thursday of a year is in week 1 of that year.
- </para>
- <para>
- In the ISO week-numbering system, it is possible for early-January
- dates to be part of the 52nd or 53rd week of the previous year, and for
- late-December dates to be part of the first week of the next year.
- For example, <literal>2005-01-01</literal> is part of the 53rd week of year
- 2004, and <literal>2006-01-01</literal> is part of the 52nd week of year
- 2005, while <literal>2012-12-31</literal> is part of the first week of 2013.
- It's recommended to use the <literal>isoyear</literal> field together with
- <literal>week</literal> to get consistent results.
- </para>
-
-<screen>
-SELECT EXTRACT(WEEK FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>7</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>year</literal></term>
- <listitem>
- <para>
- The year field. Keep in mind there is no <literal>0 AD</literal>, so subtracting
- <literal>BC</literal> years from <literal>AD</literal> years should be done with care.
- </para>
-
-<screen>
-SELECT EXTRACT(YEAR FROM TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>2001</computeroutput>
-</screen>
- </listitem>
- </varlistentry>
-
- </variablelist>
- </para>
-
- <para>
- When processing an <type>interval</type> value,
- the <function>extract</function> function produces field values that
- match the interpretation used by the interval output function. This
- can produce surprising results if one starts with a non-normalized
- interval representation, for example:
-<screen>
-SELECT INTERVAL '80 minutes';
-<lineannotation>Result: </lineannotation><computeroutput>01:20:00</computeroutput>
-SELECT EXTRACT(MINUTES FROM INTERVAL '80 minutes');
-<lineannotation>Result: </lineannotation><computeroutput>20</computeroutput>
-</screen>
- </para>
-
- <note>
- <para>
- When the input value is +/-Infinity, <function>extract</function> returns
- +/-Infinity for monotonically-increasing fields (<literal>epoch</literal>,
- <literal>julian</literal>, <literal>year</literal>, <literal>isoyear</literal>,
- <literal>decade</literal>, <literal>century</literal>, and <literal>millennium</literal>
- for <type>timestamp</type> inputs; <literal>epoch</literal>, <literal>hour</literal>,
- <literal>day</literal>, <literal>year</literal>, <literal>decade</literal>,
- <literal>century</literal>, and <literal>millennium</literal> for
- <type>interval</type> inputs).
- For other fields, NULL is returned. <productname>PostgreSQL</productname>
- versions before 9.6 returned zero for all cases of infinite input.
- </para>
- </note>
-
- <para>
- The <function>extract</function> function is primarily intended
- for computational processing. For formatting date/time values for
- display, see <xref linkend="functions-formatting"/>.
- </para>
-
- <para>
- The <function>date_part</function> function is modeled on the traditional
- <productname>Ingres</productname> equivalent to the
- <acronym>SQL</acronym>-standard function <function>extract</function>:
-<synopsis>
-date_part('<replaceable>field</replaceable>', <replaceable>source</replaceable>)
-</synopsis>
- Note that here the <replaceable>field</replaceable> parameter needs to
- be a string value, not a name. The valid field names for
- <function>date_part</function> are the same as for
- <function>extract</function>.
- For historical reasons, the <function>date_part</function> function
- returns values of type <type>double precision</type>. This can result in
- a loss of precision in certain uses. Using <function>extract</function>
- is recommended instead.
- </para>
-
-<screen>
-SELECT date_part('day', TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>16</computeroutput>
-SELECT date_part('hour', INTERVAL '4 hours 3 minutes');
-<lineannotation>Result: </lineannotation><computeroutput>4</computeroutput>
-</screen>
-
- </sect2>
-
- <sect2 id="functions-datetime-trunc">
- <title><function>date_trunc</function></title>
-
- <indexterm>
- <primary>date_trunc</primary>
- </indexterm>
-
- <para>
- The function <function>date_trunc</function> is conceptually
- similar to the <function>trunc</function> function for numbers.
- </para>
-
- <para>
-<synopsis>
-date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> [, <replaceable>time_zone</replaceable> ])
-</synopsis>
- <replaceable>source</replaceable> is a value expression of type
- <type>timestamp</type>, <type>timestamp with time zone</type>,
- or <type>interval</type>.
- (Values of type <type>date</type> and
- <type>time</type> are cast automatically to <type>timestamp</type> or
- <type>interval</type>, respectively.)
- <replaceable>field</replaceable> selects to which precision to
- truncate the input value. The return value is likewise of type
- <type>timestamp</type>, <type>timestamp with time zone</type>,
- or <type>interval</type>,
- and it has all fields that are less significant than the
- selected one set to zero (or one, for day and month).
- </para>
-
- <para>
- Valid values for <replaceable>field</replaceable> are:
- <simplelist>
- <member><literal>microseconds</literal></member>
- <member><literal>milliseconds</literal></member>
- <member><literal>second</literal></member>
- <member><literal>minute</literal></member>
- <member><literal>hour</literal></member>
- <member><literal>day</literal></member>
- <member><literal>week</literal></member>
- <member><literal>month</literal></member>
- <member><literal>quarter</literal></member>
- <member><literal>year</literal></member>
- <member><literal>decade</literal></member>
- <member><literal>century</literal></member>
- <member><literal>millennium</literal></member>
- </simplelist>
- </para>
-
- <para>
- When the input value is of type <type>timestamp with time zone</type>,
- the truncation is performed with respect to a particular time zone;
- for example, truncation to <literal>day</literal> produces a value that
- is midnight in that zone. By default, truncation is done with respect
- to the current <xref linkend="guc-timezone"/> setting, but the
- optional <replaceable>time_zone</replaceable> argument can be provided
- to specify a different time zone. The time zone name can be specified
- in any of the ways described in <xref linkend="datatype-timezones"/>.
- </para>
-
- <para>
- A time zone cannot be specified when processing <type>timestamp without
- time zone</type> or <type>interval</type> inputs. These are always
- taken at face value.
- </para>
-
- <para>
- Examples (assuming the local time zone is <literal>America/New_York</literal>):
-<screen>
-SELECT date_trunc('hour', TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 20:00:00</computeroutput>
-SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
-<lineannotation>Result: </lineannotation><computeroutput>2001-01-01 00:00:00</computeroutput>
-SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00');
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 00:00:00-05</computeroutput>
-SELECT date_trunc('day', TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40+00', 'Australia/Sydney');
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 08:00:00-05</computeroutput>
-SELECT date_trunc('hour', INTERVAL '3 days 02:47:33');
-<lineannotation>Result: </lineannotation><computeroutput>3 days 02:00:00</computeroutput>
-</screen>
- </para>
- </sect2>
-
- <sect2 id="functions-datetime-bin">
- <title><function>date_bin</function></title>
-
- <indexterm>
- <primary>date_bin</primary>
- </indexterm>
-
- <para>
- The function <function>date_bin</function> <quote>bins</quote> the input
- timestamp into the specified interval (the <firstterm>stride</firstterm>)
- aligned with a specified origin.
- </para>
-
- <para>
-<synopsis>
-date_bin(<replaceable>stride</replaceable>, <replaceable>source</replaceable>, <replaceable>origin</replaceable>)
-</synopsis>
- <replaceable>source</replaceable> is a value expression of type
- <type>timestamp</type> or <type>timestamp with time zone</type>. (Values
- of type <type>date</type> are cast automatically to
- <type>timestamp</type>.) <replaceable>stride</replaceable> is a value
- expression of type <type>interval</type>. The return value is likewise
- of type <type>timestamp</type> or <type>timestamp with time zone</type>,
- and it marks the beginning of the bin into which the
- <replaceable>source</replaceable> is placed.
- </para>
-
- <para>
- Examples:
-<screen>
-SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01');
-<lineannotation>Result: </lineannotation><computeroutput>2020-02-11 15:30:00</computeroutput>
-SELECT date_bin('15 minutes', TIMESTAMP '2020-02-11 15:44:17', TIMESTAMP '2001-01-01 00:02:30');
-<lineannotation>Result: </lineannotation><computeroutput>2020-02-11 15:32:30</computeroutput>
-</screen>
- </para>
-
- <para>
- In the case of full units (1 minute, 1 hour, etc.), it gives the same result as
- the analogous <function>date_trunc</function> call, but the difference is
- that <function>date_bin</function> can truncate to an arbitrary interval.
- </para>
-
- <para>
- The <parameter>stride</parameter> interval must be greater than zero and
- cannot contain units of month or larger.
- </para>
- </sect2>
-
- <sect2 id="functions-datetime-zoneconvert">
- <title><literal>AT TIME ZONE and AT LOCAL</literal></title>
-
- <indexterm>
- <primary>time zone</primary>
- <secondary>conversion</secondary>
- </indexterm>
-
- <indexterm>
- <primary>AT TIME ZONE</primary>
- </indexterm>
-
- <indexterm>
- <primary>AT LOCAL</primary>
- </indexterm>
-
- <para>
- The <literal>AT TIME ZONE</literal> operator converts time
- stamp <emphasis>without</emphasis> time zone to/from
- time stamp <emphasis>with</emphasis> time zone, and
- <type>time with time zone</type> values to different time
- zones. <xref linkend="functions-datetime-zoneconvert-table"/> shows its
- variants.
- </para>
-
- <table id="functions-datetime-zoneconvert-table">
- <title><literal>AT TIME ZONE</literal> and <literal>AT LOCAL</literal> Variants</title>
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp without time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Converts given time stamp <emphasis>without</emphasis> time zone to
- time stamp <emphasis>with</emphasis> time zone, assuming the given
- value is in the named time zone.
- </para>
- <para>
- <literal>timestamp '2001-02-16 20:38:40' at time zone 'America/Denver'</literal>
- <returnvalue>2001-02-17 03:38:40+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp without time zone</type> <literal>AT LOCAL</literal>
- <returnvalue>timestamp with time zone</returnvalue>
- </para>
- <para>
- Converts given time stamp <emphasis>without</emphasis> time zone to
- time stamp <emphasis>with</emphasis> the session's
- <varname>TimeZone</varname> value as time zone.
- </para>
- <para>
- <literal>timestamp '2001-02-16 20:38:40' at local</literal>
- <returnvalue>2001-02-17 03:38:40+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp with time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
- <returnvalue>timestamp without time zone</returnvalue>
- </para>
- <para>
- Converts given time stamp <emphasis>with</emphasis> time zone to
- time stamp <emphasis>without</emphasis> time zone, as the time would
- appear in that zone.
- </para>
- <para>
- <literal>timestamp with time zone '2001-02-16 20:38:40-05' at time zone 'America/Denver'</literal>
- <returnvalue>2001-02-16 18:38:40</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>timestamp with time zone</type> <literal>AT LOCAL</literal>
- <returnvalue>timestamp without time zone</returnvalue>
- </para>
- <para>
- Converts given time stamp <emphasis>with</emphasis> time zone to
- time stamp <emphasis>without</emphasis> time zone, as the time would
- appear with the session's <varname>TimeZone</varname> value as time zone.
- </para>
- <para>
- <literal>timestamp with time zone '2001-02-16 20:38:40-05' at local</literal>
- <returnvalue>2001-02-16 18:38:40</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>time with time zone</type> <literal>AT TIME ZONE</literal> <replaceable>zone</replaceable>
- <returnvalue>time with time zone</returnvalue>
- </para>
- <para>
- Converts given time <emphasis>with</emphasis> time zone to a new time
- zone. Since no date is supplied, this uses the currently active UTC
- offset for the named destination zone.
- </para>
- <para>
- <literal>time with time zone '05:34:17-05' at time zone 'UTC'</literal>
- <returnvalue>10:34:17+00</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>time with time zone</type> <literal>AT LOCAL</literal>
- <returnvalue>time with time zone</returnvalue>
- </para>
- <para>
- Converts given time <emphasis>with</emphasis> time zone to a new time
- zone. Since no date is supplied, this uses the currently active UTC
- offset for the session's <varname>TimeZone</varname> value.
- </para>
- <para>
- Assuming the session's <varname>TimeZone</varname> is set to <literal>UTC</literal>:
- </para>
- <para>
- <literal>time with time zone '05:34:17-05' at local</literal>
- <returnvalue>10:34:17+00</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- In these expressions, the desired time zone <replaceable>zone</replaceable> can be
- specified either as a text value (e.g., <literal>'America/Los_Angeles'</literal>)
- or as an interval (e.g., <literal>INTERVAL '-08:00'</literal>).
- In the text case, a time zone name can be specified in any of the ways
- described in <xref linkend="datatype-timezones"/>.
- The interval case is only useful for zones that have fixed offsets from
- UTC, so it is not very common in practice.
- </para>
-
- <para>
- The syntax <literal>AT LOCAL</literal> may be used as shorthand for
- <literal>AT TIME ZONE <replaceable>local</replaceable></literal>, where
- <replaceable>local</replaceable> is the session's
- <varname>TimeZone</varname> value.
- </para>
-
- <para>
- Examples (assuming the current <xref linkend="guc-timezone"/> setting
- is <literal>America/Los_Angeles</literal>):
-<screen>
-SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'America/Denver';
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 19:38:40-08</computeroutput>
-SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT TIME ZONE 'America/Denver';
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 18:38:40</computeroutput>
-SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'Asia/Tokyo' AT TIME ZONE 'America/Chicago';
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 05:38:40</computeroutput>
-SELECT TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-05' AT LOCAL;
-<lineannotation>Result: </lineannotation><computeroutput>2001-02-16 17:38:40</computeroutput>
-SELECT TIME WITH TIME ZONE '20:38:40-05' AT LOCAL;
-<lineannotation>Result: </lineannotation><computeroutput>17:38:40</computeroutput>
-</screen>
- The first example adds a time zone to a value that lacks it, and
- displays the value using the current <varname>TimeZone</varname>
- setting. The second example shifts the time stamp with time zone value
- to the specified time zone, and returns the value without a time zone.
- This allows storage and display of values different from the current
- <varname>TimeZone</varname> setting. The third example converts
- Tokyo time to Chicago time. The fourth example shifts the time stamp
- with time zone value to the time zone currently specified by the
- <varname>TimeZone</varname> setting and returns the value without a
- time zone.
- </para>
-
- <para>
- The fifth example is a cautionary tale. Due to the fact that there is no
- date associated with the input value, the conversion is made using the
- current date of the session. Therefore, this static example may show a wrong
- result depending on the time of the year it is viewed because
- <literal>'America/Los_Angeles'</literal> observes Daylight Savings Time.
- </para>
-
- <para>
- The function <literal><function>timezone</function>(<replaceable>zone</replaceable>,
- <replaceable>timestamp</replaceable>)</literal> is equivalent to the SQL-conforming construct
- <literal><replaceable>timestamp</replaceable> AT TIME ZONE
- <replaceable>zone</replaceable></literal>.
- </para>
-
- <para>
- The function <literal><function>timezone</function>(<replaceable>zone</replaceable>,
- <replaceable>time</replaceable>)</literal> is equivalent to the SQL-conforming construct
- <literal><replaceable>time</replaceable> AT TIME ZONE
- <replaceable>zone</replaceable></literal>.
- </para>
-
- <para>
- The function <literal><function>timezone</function>(<replaceable>timestamp</replaceable>)</literal>
- is equivalent to the SQL-conforming construct <literal><replaceable>timestamp</replaceable>
- AT LOCAL</literal>.
- </para>
-
- <para>
- The function <literal><function>timezone</function>(<replaceable>time</replaceable>)</literal>
- is equivalent to the SQL-conforming construct <literal><replaceable>time</replaceable>
- AT LOCAL</literal>.
- </para>
- </sect2>
-
- <sect2 id="functions-datetime-current">
- <title>Current Date/Time</title>
-
- <indexterm>
- <primary>date</primary>
- <secondary>current</secondary>
- </indexterm>
-
- <indexterm>
- <primary>time</primary>
- <secondary>current</secondary>
- </indexterm>
-
- <para>
- <productname>PostgreSQL</productname> provides a number of functions
- that return values related to the current date and time. These
- SQL-standard functions all return values based on the start time of
- the current transaction:
-<synopsis>
-CURRENT_DATE
-CURRENT_TIME
-CURRENT_TIMESTAMP
-CURRENT_TIME(<replaceable>precision</replaceable>)
-CURRENT_TIMESTAMP(<replaceable>precision</replaceable>)
-LOCALTIME
-LOCALTIMESTAMP
-LOCALTIME(<replaceable>precision</replaceable>)
-LOCALTIMESTAMP(<replaceable>precision</replaceable>)
-</synopsis>
- </para>
-
- <para>
- <function>CURRENT_TIME</function> and
- <function>CURRENT_TIMESTAMP</function> deliver values with time zone;
- <function>LOCALTIME</function> and
- <function>LOCALTIMESTAMP</function> deliver values without time zone.
- </para>
-
- <para>
- <function>CURRENT_TIME</function>,
- <function>CURRENT_TIMESTAMP</function>,
- <function>LOCALTIME</function>, and
- <function>LOCALTIMESTAMP</function>
- can optionally take
- a precision parameter, which causes the result to be rounded
- to that many fractional digits in the seconds field. Without a precision parameter,
- the result is given to the full available precision.
- </para>
-
- <para>
- Some examples:
-<screen>
-SELECT CURRENT_TIME;
-<lineannotation>Result: </lineannotation><computeroutput>14:39:53.662522-05</computeroutput>
-SELECT CURRENT_DATE;
-<lineannotation>Result: </lineannotation><computeroutput>2019-12-23</computeroutput>
-SELECT CURRENT_TIMESTAMP;
-<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.662522-05</computeroutput>
-SELECT CURRENT_TIMESTAMP(2);
-<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.66-05</computeroutput>
-SELECT LOCALTIMESTAMP;
-<lineannotation>Result: </lineannotation><computeroutput>2019-12-23 14:39:53.662522</computeroutput>
-</screen>
- </para>
-
- <para>
- Since these functions return
- the start time of the current transaction, their values do not
- change during the transaction. This is considered a feature:
- the intent is to allow a single transaction to have a consistent
- notion of the <quote>current</quote> time, so that multiple
- modifications within the same transaction bear the same
- time stamp.
- </para>
-
- <note>
- <para>
- Other database systems might advance these values more
- frequently.
- </para>
- </note>
-
- <para>
- <productname>PostgreSQL</productname> also provides functions that
- return the start time of the current statement, as well as the actual
- current time at the instant the function is called. The complete list
- of non-SQL-standard time functions is:
-<synopsis>
-transaction_timestamp()
-statement_timestamp()
-clock_timestamp()
-timeofday()
-now()
-</synopsis>
- </para>
-
- <para>
- <function>transaction_timestamp()</function> is equivalent to
- <function>CURRENT_TIMESTAMP</function>, but is named to clearly reflect
- what it returns.
- <function>statement_timestamp()</function> returns the start time of the current
- statement (more specifically, the time of receipt of the latest command
- message from the client).
- <function>statement_timestamp()</function> and <function>transaction_timestamp()</function>
- return the same value during the first command of a transaction, but might
- differ during subsequent commands.
- <function>clock_timestamp()</function> returns the actual current time, and
- therefore its value changes even within a single SQL command.
- <function>timeofday()</function> is a historical
- <productname>PostgreSQL</productname> function. Like
- <function>clock_timestamp()</function>, it returns the actual current time,
- but as a formatted <type>text</type> string rather than a <type>timestamp
- with time zone</type> value.
- <function>now()</function> is a traditional <productname>PostgreSQL</productname>
- equivalent to <function>transaction_timestamp()</function>.
- </para>
-
- <para>
- All the date/time data types also accept the special literal value
- <literal>now</literal> to specify the current date and time (again,
- interpreted as the transaction start time). Thus,
- the following three all return the same result:
-<programlisting>
-SELECT CURRENT_TIMESTAMP;
-SELECT now();
-SELECT TIMESTAMP 'now'; -- but see tip below
-</programlisting>
- </para>
-
- <tip>
- <para>
- Do not use the third form when specifying a value to be evaluated later,
- for example in a <literal>DEFAULT</literal> clause for a table column.
- The system will convert <literal>now</literal>
- to a <type>timestamp</type> as soon as the constant is parsed, so that when
- the default value is needed,
- the time of the table creation would be used! The first two
- forms will not be evaluated until the default value is used,
- because they are function calls. Thus they will give the desired
- behavior of defaulting to the time of row insertion.
- (See also <xref linkend="datatype-datetime-special-values"/>.)
- </para>
- </tip>
- </sect2>
-
- <sect2 id="functions-datetime-delay">
- <title>Delaying Execution</title>
-
- <indexterm>
- <primary>pg_sleep</primary>
- </indexterm>
- <indexterm>
- <primary>pg_sleep_for</primary>
- </indexterm>
- <indexterm>
- <primary>pg_sleep_until</primary>
- </indexterm>
- <indexterm>
- <primary>sleep</primary>
- </indexterm>
- <indexterm>
- <primary>delay</primary>
- </indexterm>
-
- <para>
- The following functions are available to delay execution of the server
- process:
-<synopsis>
-pg_sleep ( <type>double precision</type> )
-pg_sleep_for ( <type>interval</type> )
-pg_sleep_until ( <type>timestamp with time zone</type> )
-</synopsis>
-
- <function>pg_sleep</function> makes the current session's process
- sleep until the given number of seconds have
- elapsed. Fractional-second delays can be specified.
- <function>pg_sleep_for</function> is a convenience function to
- allow the sleep time to be specified as an <type>interval</type>.
- <function>pg_sleep_until</function> is a convenience function for when
- a specific wake-up time is desired.
- For example:
-
-<programlisting>
-SELECT pg_sleep(1.5);
-SELECT pg_sleep_for('5 minutes');
-SELECT pg_sleep_until('tomorrow 03:00');
-</programlisting>
- </para>
-
- <note>
- <para>
- The effective resolution of the sleep interval is platform-specific;
- 0.01 seconds is a common value. The sleep delay will be at least as long
- as specified. It might be longer depending on factors such as server load.
- In particular, <function>pg_sleep_until</function> is not guaranteed to
- wake up exactly at the specified time, but it will not wake up any earlier.
- </para>
- </note>
-
- <warning>
- <para>
- Make sure that your session does not hold more locks than necessary
- when calling <function>pg_sleep</function> or its variants. Otherwise
- other sessions might have to wait for your sleeping process, slowing down
- the entire system.
- </para>
- </warning>
- </sect2>
-
- </sect1>
-
+&func-datetime;
<sect1 id="functions-enum">
<title>Enum Support Functions</title>
--
2.34.1
v1-0002-split-functions-matching-sect1-from-func.sgml.patchtext/x-patch; charset=US-ASCII; name=v1-0002-split-functions-matching-sect1-from-func.sgml.patchDownload
From a93abe5e6e7fa145938ce8996948fe5b1ba04de5 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 26 Apr 2024 14:25:30 +0800
Subject: [PATCH v1 2/7] split "functions-matching" sect1 from func.sgml
"functions-matching" live in a new file: doc/src/sgml/func-matching.sgml,
it will hold functions-matching.html content.
http://postgr.es/m/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd%3Dxt6k-jDizBVUKK6O4KQ%40mail.gmail.com
---
doc/src/sgml/filelist.sgml | 1 +
doc/src/sgml/func-matching.sgml | 2429 ++++++++++++++++++++++++++++++
doc/src/sgml/func.sgml | 2431 +------------------------------
3 files changed, 2431 insertions(+), 2430 deletions(-)
create mode 100644 doc/src/sgml/func-matching.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index c795833b..13bc4be5 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -19,6 +19,7 @@
<!ENTITY dml SYSTEM "dml.sgml">
<!ENTITY func SYSTEM "func.sgml">
<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func-matching.sgml b/doc/src/sgml/func-matching.sgml
new file mode 100644
index 00000000..772e2567
--- /dev/null
+++ b/doc/src/sgml/func-matching.sgml
@@ -0,0 +1,2429 @@
+ <sect1 id="functions-matching">
+ <title>Pattern Matching</title>
+
+ <indexterm zone="functions-matching">
+ <primary>pattern matching</primary>
+ </indexterm>
+
+ <para>
+ There are three separate approaches to pattern matching provided
+ by <productname>PostgreSQL</productname>: the traditional
+ <acronym>SQL</acronym> <function>LIKE</function> operator, the
+ more recent <function>SIMILAR TO</function> operator (added in
+ SQL:1999), and <acronym>POSIX</acronym>-style regular
+ expressions. Aside from the basic <quote>does this string match
+ this pattern?</quote> operators, functions are available to extract
+ or replace matching substrings and to split a string at matching
+ locations.
+ </para>
+
+ <tip>
+ <para>
+ If you have pattern matching needs that go beyond this,
+ consider writing a user-defined function in Perl or Tcl.
+ </para>
+ </tip>
+
+ <caution>
+ <para>
+ While most regular-expression searches can be executed very quickly,
+ regular expressions can be contrived that take arbitrary amounts of
+ time and memory to process. Be wary of accepting regular-expression
+ search patterns from hostile sources. If you must do so, it is
+ advisable to impose a statement timeout.
+ </para>
+
+ <para>
+ Searches using <function>SIMILAR TO</function> patterns have the same
+ security hazards, since <function>SIMILAR TO</function> provides many
+ of the same capabilities as <acronym>POSIX</acronym>-style regular
+ expressions.
+ </para>
+
+ <para>
+ <function>LIKE</function> searches, being much simpler than the other
+ two options, are safer to use with possibly-hostile pattern sources.
+ </para>
+ </caution>
+
+ <para>
+ The pattern matching operators of all three kinds do not support
+ nondeterministic collations. If required, apply a different collation to
+ the expression to work around this limitation.
+ </para>
+
+ <sect2 id="functions-like">
+ <title><function>LIKE</function></title>
+
+ <indexterm>
+ <primary>LIKE</primary>
+ </indexterm>
+
+<synopsis>
+<replaceable>string</replaceable> LIKE <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
+<replaceable>string</replaceable> NOT LIKE <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
+</synopsis>
+
+ <para>
+ The <function>LIKE</function> expression returns true if the
+ <replaceable>string</replaceable> matches the supplied
+ <replaceable>pattern</replaceable>. (As
+ expected, the <function>NOT LIKE</function> expression returns
+ false if <function>LIKE</function> returns true, and vice versa.
+ An equivalent expression is
+ <literal>NOT (<replaceable>string</replaceable> LIKE
+ <replaceable>pattern</replaceable>)</literal>.)
+ </para>
+
+ <para>
+ If <replaceable>pattern</replaceable> does not contain percent
+ signs or underscores, then the pattern only represents the string
+ itself; in that case <function>LIKE</function> acts like the
+ equals operator. An underscore (<literal>_</literal>) in
+ <replaceable>pattern</replaceable> stands for (matches) any single
+ character; a percent sign (<literal>%</literal>) matches any sequence
+ of zero or more characters.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+'abc' LIKE 'abc' <lineannotation>true</lineannotation>
+'abc' LIKE 'a%' <lineannotation>true</lineannotation>
+'abc' LIKE '_b_' <lineannotation>true</lineannotation>
+'abc' LIKE 'c' <lineannotation>false</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ <function>LIKE</function> pattern matching always covers the entire
+ string. Therefore, if it's desired to match a sequence anywhere within
+ a string, the pattern must start and end with a percent sign.
+ </para>
+
+ <para>
+ To match a literal underscore or percent sign without matching
+ other characters, the respective character in
+ <replaceable>pattern</replaceable> must be
+ preceded by the escape character. The default escape
+ character is the backslash but a different one can be selected by
+ using the <literal>ESCAPE</literal> clause. To match the escape
+ character itself, write two escape characters.
+ </para>
+
+ <note>
+ <para>
+ If you have <xref linkend="guc-standard-conforming-strings"/> turned off,
+ any backslashes you write in literal string constants will need to be
+ doubled. See <xref linkend="sql-syntax-strings"/> for more information.
+ </para>
+ </note>
+
+ <para>
+ It's also possible to select no escape character by writing
+ <literal>ESCAPE ''</literal>. This effectively disables the
+ escape mechanism, which makes it impossible to turn off the
+ special meaning of underscore and percent signs in the pattern.
+ </para>
+
+ <para>
+ According to the SQL standard, omitting <literal>ESCAPE</literal>
+ means there is no escape character (rather than defaulting to a
+ backslash), and a zero-length <literal>ESCAPE</literal> value is
+ disallowed. <productname>PostgreSQL</productname>'s behavior in
+ this regard is therefore slightly nonstandard.
+ </para>
+
+ <para>
+ The key word <token>ILIKE</token> can be used instead of
+ <token>LIKE</token> to make the match case-insensitive according
+ to the active locale. This is not in the <acronym>SQL</acronym> standard but is a
+ <productname>PostgreSQL</productname> extension.
+ </para>
+
+ <para>
+ The operator <literal>~~</literal> is equivalent to
+ <function>LIKE</function>, and <literal>~~*</literal> corresponds to
+ <function>ILIKE</function>. There are also
+ <literal>!~~</literal> and <literal>!~~*</literal> operators that
+ represent <function>NOT LIKE</function> and <function>NOT
+ ILIKE</function>, respectively. All of these operators are
+ <productname>PostgreSQL</productname>-specific. You may see these
+ operator names in <command>EXPLAIN</command> output and similar
+ places, since the parser actually translates <function>LIKE</function>
+ et al. to these operators.
+ </para>
+
+ <para>
+ The phrases <function>LIKE</function>, <function>ILIKE</function>,
+ <function>NOT LIKE</function>, and <function>NOT ILIKE</function> are
+ generally treated as operators
+ in <productname>PostgreSQL</productname> syntax; for example they can
+ be used in <replaceable>expression</replaceable>
+ <replaceable>operator</replaceable> ANY
+ (<replaceable>subquery</replaceable>) constructs, although
+ an <literal>ESCAPE</literal> clause cannot be included there. In some
+ obscure cases it may be necessary to use the underlying operator names
+ instead.
+ </para>
+
+ <para>
+ Also see the starts-with operator <literal>^@</literal> and the
+ corresponding <function>starts_with()</function> function, which are
+ useful in cases where simply matching the beginning of a string is
+ needed.
+ </para>
+ </sect2>
+
+
+ <sect2 id="functions-similarto-regexp">
+ <title><function>SIMILAR TO</function> Regular Expressions</title>
+
+ <indexterm>
+ <primary>regular expression</primary>
+ <!-- <seealso>pattern matching</seealso> breaks index build -->
+ </indexterm>
+
+ <indexterm>
+ <primary>SIMILAR TO</primary>
+ </indexterm>
+ <indexterm>
+ <primary>substring</primary>
+ </indexterm>
+
+<synopsis>
+<replaceable>string</replaceable> SIMILAR TO <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
+<replaceable>string</replaceable> NOT SIMILAR TO <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
+</synopsis>
+
+ <para>
+ The <function>SIMILAR TO</function> operator returns true or
+ false depending on whether its pattern matches the given string.
+ It is similar to <function>LIKE</function>, except that it
+ interprets the pattern using the SQL standard's definition of a
+ regular expression. SQL regular expressions are a curious cross
+ between <function>LIKE</function> notation and common (POSIX) regular
+ expression notation.
+ </para>
+
+ <para>
+ Like <function>LIKE</function>, the <function>SIMILAR TO</function>
+ operator succeeds only if its pattern matches the entire string;
+ this is unlike common regular expression behavior where the pattern
+ can match any part of the string.
+ Also like
+ <function>LIKE</function>, <function>SIMILAR TO</function> uses
+ <literal>_</literal> and <literal>%</literal> as wildcard characters denoting
+ any single character and any string, respectively (these are
+ comparable to <literal>.</literal> and <literal>.*</literal> in POSIX regular
+ expressions).
+ </para>
+
+ <para>
+ In addition to these facilities borrowed from <function>LIKE</function>,
+ <function>SIMILAR TO</function> supports these pattern-matching
+ metacharacters borrowed from POSIX regular expressions:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>|</literal> denotes alternation (either of two alternatives).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>*</literal> denotes repetition of the previous item zero
+ or more times.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>+</literal> denotes repetition of the previous item one
+ or more times.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>?</literal> denotes repetition of the previous item zero
+ or one time.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>{</literal><replaceable>m</replaceable><literal>}</literal> denotes repetition
+ of the previous item exactly <replaceable>m</replaceable> times.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> denotes repetition
+ of the previous item <replaceable>m</replaceable> or more times.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal>
+ denotes repetition of the previous item at least <replaceable>m</replaceable> and
+ not more than <replaceable>n</replaceable> times.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Parentheses <literal>()</literal> can be used to group items into
+ a single logical item.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A bracket expression <literal>[...]</literal> specifies a character
+ class, just as in POSIX regular expressions.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ Notice that the period (<literal>.</literal>) is not a metacharacter
+ for <function>SIMILAR TO</function>.
+ </para>
+
+ <para>
+ As with <function>LIKE</function>, a backslash disables the special
+ meaning of any of these metacharacters. A different escape character
+ can be specified with <literal>ESCAPE</literal>, or the escape
+ capability can be disabled by writing <literal>ESCAPE ''</literal>.
+ </para>
+
+ <para>
+ According to the SQL standard, omitting <literal>ESCAPE</literal>
+ means there is no escape character (rather than defaulting to a
+ backslash), and a zero-length <literal>ESCAPE</literal> value is
+ disallowed. <productname>PostgreSQL</productname>'s behavior in
+ this regard is therefore slightly nonstandard.
+ </para>
+
+ <para>
+ Another nonstandard extension is that following the escape character
+ with a letter or digit provides access to the escape sequences
+ defined for POSIX regular expressions; see
+ <xref linkend="posix-character-entry-escapes-table"/>,
+ <xref linkend="posix-class-shorthand-escapes-table"/>, and
+ <xref linkend="posix-constraint-escapes-table"/> below.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+'abc' SIMILAR TO 'abc' <lineannotation>true</lineannotation>
+'abc' SIMILAR TO 'a' <lineannotation>false</lineannotation>
+'abc' SIMILAR TO '%(b|d)%' <lineannotation>true</lineannotation>
+'abc' SIMILAR TO '(b|c)%' <lineannotation>false</lineannotation>
+'-abc-' SIMILAR TO '%\mabc\M%' <lineannotation>true</lineannotation>
+'xabcy' SIMILAR TO '%\mabc\M%' <lineannotation>false</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>substring</function> function with three parameters
+ provides extraction of a substring that matches an SQL
+ regular expression pattern. The function can be written according
+ to standard SQL syntax:
+<synopsis>
+substring(<replaceable>string</replaceable> similar <replaceable>pattern</replaceable> escape <replaceable>escape-character</replaceable>)
+</synopsis>
+ or using the now obsolete SQL:1999 syntax:
+<synopsis>
+substring(<replaceable>string</replaceable> from <replaceable>pattern</replaceable> for <replaceable>escape-character</replaceable>)
+</synopsis>
+ or as a plain three-argument function:
+<synopsis>
+substring(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>, <replaceable>escape-character</replaceable>)
+</synopsis>
+ As with <literal>SIMILAR TO</literal>, the
+ specified pattern must match the entire data string, or else the
+ function fails and returns null. To indicate the part of the
+ pattern for which the matching data sub-string is of interest,
+ the pattern should contain
+ two occurrences of the escape character followed by a double quote
+ (<literal>"</literal>). <!-- " font-lock sanity -->
+ The text matching the portion of the pattern
+ between these separators is returned when the match is successful.
+ </para>
+
+ <para>
+ The escape-double-quote separators actually
+ divide <function>substring</function>'s pattern into three independent
+ regular expressions; for example, a vertical bar (<literal>|</literal>)
+ in any of the three sections affects only that section. Also, the first
+ and third of these regular expressions are defined to match the smallest
+ possible amount of text, not the largest, when there is any ambiguity
+ about how much of the data string matches which pattern. (In POSIX
+ parlance, the first and third regular expressions are forced to be
+ non-greedy.)
+ </para>
+
+ <para>
+ As an extension to the SQL standard, <productname>PostgreSQL</productname>
+ allows there to be just one escape-double-quote separator, in which case
+ the third regular expression is taken as empty; or no separators, in which
+ case the first and third regular expressions are taken as empty.
+ </para>
+
+ <para>
+ Some examples, with <literal>#"</literal> delimiting the return string:
+<programlisting>
+substring('foobar' similar '%#"o_b#"%' escape '#') <lineannotation>oob</lineannotation>
+substring('foobar' similar '#"o_b#"%' escape '#') <lineannotation>NULL</lineannotation>
+</programlisting>
+ </para>
+ </sect2>
+
+ <sect2 id="functions-posix-regexp">
+ <title><acronym>POSIX</acronym> Regular Expressions</title>
+
+ <indexterm zone="functions-posix-regexp">
+ <primary>regular expression</primary>
+ <seealso>pattern matching</seealso>
+ </indexterm>
+ <indexterm>
+ <primary>substring</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_count</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_instr</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_like</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_match</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_matches</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_replace</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_split_to_table</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_split_to_array</primary>
+ </indexterm>
+ <indexterm>
+ <primary>regexp_substr</primary>
+ </indexterm>
+
+ <para>
+ <xref linkend="functions-posix-table"/> lists the available
+ operators for pattern matching using POSIX regular expressions.
+ </para>
+
+ <table id="functions-posix-table">
+ <title>Regular Expression Match Operators</title>
+
+ <tgroup cols="1">
+ <thead>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ Operator
+ </para>
+ <para>
+ Description
+ </para>
+ <para>
+ Example(s)
+ </para></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>text</type> <literal>~</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ String matches regular expression, case sensitively
+ </para>
+ <para>
+ <literal>'thomas' ~ 't.*ma'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>text</type> <literal>~*</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ String matches regular expression, case-insensitively
+ </para>
+ <para>
+ <literal>'thomas' ~* 'T.*ma'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>text</type> <literal>!~</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ String does not match regular expression, case sensitively
+ </para>
+ <para>
+ <literal>'thomas' !~ 't.*max'</literal>
+ <returnvalue>t</returnvalue>
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <type>text</type> <literal>!~*</literal> <type>text</type>
+ <returnvalue>boolean</returnvalue>
+ </para>
+ <para>
+ String does not match regular expression, case-insensitively
+ </para>
+ <para>
+ <literal>'thomas' !~* 'T.*ma'</literal>
+ <returnvalue>f</returnvalue>
+ </para></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ <acronym>POSIX</acronym> regular expressions provide a more
+ powerful means for pattern matching than the <function>LIKE</function> and
+ <function>SIMILAR TO</function> operators.
+ Many Unix tools such as <command>egrep</command>,
+ <command>sed</command>, or <command>awk</command> use a pattern
+ matching language that is similar to the one described here.
+ </para>
+
+ <para>
+ A regular expression is a character sequence that is an
+ abbreviated definition of a set of strings (a <firstterm>regular
+ set</firstterm>). A string is said to match a regular expression
+ if it is a member of the regular set described by the regular
+ expression. As with <function>LIKE</function>, pattern characters
+ match string characters exactly unless they are special characters
+ in the regular expression language — but regular expressions use
+ different special characters than <function>LIKE</function> does.
+ Unlike <function>LIKE</function> patterns, a
+ regular expression is allowed to match anywhere within a string, unless
+ the regular expression is explicitly anchored to the beginning or
+ end of the string.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+'abcd' ~ 'bc' <lineannotation>true</lineannotation>
+'abcd' ~ 'a.c' <lineannotation>true — dot matches any character</lineannotation>
+'abcd' ~ 'a.*d' <lineannotation>true — <literal>*</literal> repeats the preceding pattern item</lineannotation>
+'abcd' ~ '(b|x)' <lineannotation>true — <literal>|</literal> means OR, parentheses group</lineannotation>
+'abcd' ~ '^a' <lineannotation>true — <literal>^</literal> anchors to start of string</lineannotation>
+'abcd' ~ '^(b|c)' <lineannotation>false — would match except for anchoring</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <acronym>POSIX</acronym> pattern language is described in much
+ greater detail below.
+ </para>
+
+ <para>
+ The <function>substring</function> function with two parameters,
+ <function>substring(<replaceable>string</replaceable> from
+ <replaceable>pattern</replaceable>)</function>, provides extraction of a
+ substring
+ that matches a POSIX regular expression pattern. It returns null if
+ there is no match, otherwise the first portion of the text that matched the
+ pattern. But if the pattern contains any parentheses, the portion
+ of the text that matched the first parenthesized subexpression (the
+ one whose left parenthesis comes first) is
+ returned. You can put parentheses around the whole expression
+ if you want to use parentheses within it without triggering this
+ exception. If you need parentheses in the pattern before the
+ subexpression you want to extract, see the non-capturing parentheses
+ described below.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+substring('foobar' from 'o.b') <lineannotation>oob</lineannotation>
+substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>regexp_count</function> function counts the number of
+ places where a POSIX regular expression pattern matches a string.
+ It has the syntax
+ <function>regexp_count</function>(<replaceable>string</replaceable>,
+ <replaceable>pattern</replaceable>
+ <optional>, <replaceable>start</replaceable>
+ <optional>, <replaceable>flags</replaceable>
+ </optional></optional>).
+ <replaceable>pattern</replaceable> is searched for
+ in <replaceable>string</replaceable>, normally from the beginning of
+ the string, but if the <replaceable>start</replaceable> parameter is
+ provided then beginning from that character index.
+ The <replaceable>flags</replaceable> parameter is an optional text
+ string containing zero or more single-letter flags that change the
+ function's behavior. For example, including <literal>i</literal> in
+ <replaceable>flags</replaceable> specifies case-insensitive matching.
+ Supported flags are described in
+ <xref linkend="posix-embedded-options-table"/>.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+regexp_count('ABCABCAXYaxy', 'A.') <lineannotation>3</lineannotation>
+regexp_count('ABCABCAXYaxy', 'A.', 1, 'i') <lineannotation>4</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>regexp_instr</function> function returns the starting or
+ ending position of the <replaceable>N</replaceable>'th match of a
+ POSIX regular expression pattern to a string, or zero if there is no
+ such match. It has the syntax
+ <function>regexp_instr</function>(<replaceable>string</replaceable>,
+ <replaceable>pattern</replaceable>
+ <optional>, <replaceable>start</replaceable>
+ <optional>, <replaceable>N</replaceable>
+ <optional>, <replaceable>endoption</replaceable>
+ <optional>, <replaceable>flags</replaceable>
+ <optional>, <replaceable>subexpr</replaceable>
+ </optional></optional></optional></optional></optional>).
+ <replaceable>pattern</replaceable> is searched for
+ in <replaceable>string</replaceable>, normally from the beginning of
+ the string, but if the <replaceable>start</replaceable> parameter is
+ provided then beginning from that character index.
+ If <replaceable>N</replaceable> is specified
+ then the <replaceable>N</replaceable>'th match of the pattern
+ is located, otherwise the first match is located.
+ If the <replaceable>endoption</replaceable> parameter is omitted or
+ specified as zero, the function returns the position of the first
+ character of the match. Otherwise, <replaceable>endoption</replaceable>
+ must be one, and the function returns the position of the character
+ following the match.
+ The <replaceable>flags</replaceable> parameter is an optional text
+ string containing zero or more single-letter flags that change the
+ function's behavior. Supported flags are described
+ in <xref linkend="posix-embedded-options-table"/>.
+ For a pattern containing parenthesized
+ subexpressions, <replaceable>subexpr</replaceable> is an integer
+ indicating which subexpression is of interest: the result identifies
+ the position of the substring matching that subexpression.
+ Subexpressions are numbered in the order of their leading parentheses.
+ When <replaceable>subexpr</replaceable> is omitted or zero, the result
+ identifies the position of the whole match regardless of
+ parenthesized subexpressions.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+regexp_instr('number of your street, town zip, FR', '[^,]+', 1, 2)
+ <lineannotation>23</lineannotation>
+regexp_instr('ABCDEFGHI', '(c..)(...)', 1, 1, 0, 'i', 2)
+ <lineannotation>6</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>regexp_like</function> function checks whether a match
+ of a POSIX regular expression pattern occurs within a string,
+ returning boolean true or false. It has the syntax
+ <function>regexp_like</function>(<replaceable>string</replaceable>,
+ <replaceable>pattern</replaceable>
+ <optional>, <replaceable>flags</replaceable> </optional>).
+ The <replaceable>flags</replaceable> parameter is an optional text
+ string containing zero or more single-letter flags that change the
+ function's behavior. Supported flags are described
+ in <xref linkend="posix-embedded-options-table"/>.
+ This function has the same results as the <literal>~</literal>
+ operator if no flags are specified. If only the <literal>i</literal>
+ flag is specified, it has the same results as
+ the <literal>~*</literal> operator.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+regexp_like('Hello World', 'world') <lineannotation>false</lineannotation>
+regexp_like('Hello World', 'world', 'i') <lineannotation>true</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>regexp_match</function> function returns a text array of
+ matching substring(s) within the first match of a POSIX
+ regular expression pattern to a string. It has the syntax
+ <function>regexp_match</function>(<replaceable>string</replaceable>,
+ <replaceable>pattern</replaceable> <optional>, <replaceable>flags</replaceable> </optional>).
+ If there is no match, the result is <literal>NULL</literal>.
+ If a match is found, and the <replaceable>pattern</replaceable> contains no
+ parenthesized subexpressions, then the result is a single-element text
+ array containing the substring matching the whole pattern.
+ If a match is found, and the <replaceable>pattern</replaceable> contains
+ parenthesized subexpressions, then the result is a text array
+ whose <replaceable>n</replaceable>'th element is the substring matching
+ the <replaceable>n</replaceable>'th parenthesized subexpression of
+ the <replaceable>pattern</replaceable> (not counting <quote>non-capturing</quote>
+ parentheses; see below for details).
+ The <replaceable>flags</replaceable> parameter is an optional text string
+ containing zero or more single-letter flags that change the function's
+ behavior. Supported flags are described
+ in <xref linkend="posix-embedded-options-table"/>.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+SELECT regexp_match('foobarbequebaz', 'bar.*que');
+ regexp_match
+--------------
+ {barbeque}
+(1 row)
+
+SELECT regexp_match('foobarbequebaz', '(bar)(beque)');
+ regexp_match
+--------------
+ {bar,beque}
+(1 row)
+</programlisting>
+ </para>
+
+ <tip>
+ <para>
+ In the common case where you just want the whole matching substring
+ or <literal>NULL</literal> for no match, the best solution is to
+ use <function>regexp_substr()</function>.
+ However, <function>regexp_substr()</function> only exists
+ in <productname>PostgreSQL</productname> version 15 and up. When
+ working in older versions, you can extract the first element
+ of <function>regexp_match()</function>'s result, for example:
+<programlisting>
+SELECT (regexp_match('foobarbequebaz', 'bar.*que'))[1];
+ regexp_match
+--------------
+ barbeque
+(1 row)
+</programlisting>
+ </para>
+ </tip>
+
+ <para>
+ The <function>regexp_matches</function> function returns a set of text arrays
+ of matching substring(s) within matches of a POSIX regular
+ expression pattern to a string. It has the same syntax as
+ <function>regexp_match</function>.
+ This function returns no rows if there is no match, one row if there is
+ a match and the <literal>g</literal> flag is not given, or <replaceable>N</replaceable>
+ rows if there are <replaceable>N</replaceable> matches and the <literal>g</literal> flag
+ is given. Each returned row is a text array containing the whole
+ matched substring or the substrings matching parenthesized
+ subexpressions of the <replaceable>pattern</replaceable>, just as described above
+ for <function>regexp_match</function>.
+ <function>regexp_matches</function> accepts all the flags shown
+ in <xref linkend="posix-embedded-options-table"/>, plus
+ the <literal>g</literal> flag which commands it to return all matches, not
+ just the first one.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+SELECT regexp_matches('foo', 'not there');
+ regexp_matches
+----------------
+(0 rows)
+
+SELECT regexp_matches('foobarbequebazilbarfbonk', '(b[^b]+)(b[^b]+)', 'g');
+ regexp_matches
+----------------
+ {bar,beque}
+ {bazil,barf}
+(2 rows)
+</programlisting>
+ </para>
+
+ <tip>
+ <para>
+ In most cases <function>regexp_matches()</function> should be used with
+ the <literal>g</literal> flag, since if you only want the first match, it's
+ easier and more efficient to use <function>regexp_match()</function>.
+ However, <function>regexp_match()</function> only exists
+ in <productname>PostgreSQL</productname> version 10 and up. When working in older
+ versions, a common trick is to place a <function>regexp_matches()</function>
+ call in a sub-select, for example:
+<programlisting>
+SELECT col1, (SELECT regexp_matches(col2, '(bar)(beque)')) FROM tab;
+</programlisting>
+ This produces a text array if there's a match, or <literal>NULL</literal> if
+ not, the same as <function>regexp_match()</function> would do. Without the
+ sub-select, this query would produce no output at all for table rows
+ without a match, which is typically not the desired behavior.
+ </para>
+ </tip>
+
+ <para>
+ The <function>regexp_replace</function> function provides substitution of
+ new text for substrings that match POSIX regular expression patterns.
+ It has the syntax
+ <function>regexp_replace</function>(<replaceable>source</replaceable>,
+ <replaceable>pattern</replaceable>, <replaceable>replacement</replaceable>
+ <optional>, <replaceable>start</replaceable>
+ <optional>, <replaceable>N</replaceable>
+ </optional></optional>
+ <optional>, <replaceable>flags</replaceable> </optional>).
+ (Notice that <replaceable>N</replaceable> cannot be specified
+ unless <replaceable>start</replaceable> is,
+ but <replaceable>flags</replaceable> can be given in any case.)
+ The <replaceable>source</replaceable> string is returned unchanged if
+ there is no match to the <replaceable>pattern</replaceable>. If there is a
+ match, the <replaceable>source</replaceable> string is returned with the
+ <replaceable>replacement</replaceable> string substituted for the matching
+ substring. The <replaceable>replacement</replaceable> string can contain
+ <literal>\</literal><replaceable>n</replaceable>, where <replaceable>n</replaceable> is 1
+ through 9, to indicate that the source substring matching the
+ <replaceable>n</replaceable>'th parenthesized subexpression of the pattern should be
+ inserted, and it can contain <literal>\&</literal> to indicate that the
+ substring matching the entire pattern should be inserted. Write
+ <literal>\\</literal> if you need to put a literal backslash in the replacement
+ text.
+ <replaceable>pattern</replaceable> is searched for
+ in <replaceable>string</replaceable>, normally from the beginning of
+ the string, but if the <replaceable>start</replaceable> parameter is
+ provided then beginning from that character index.
+ By default, only the first match of the pattern is replaced.
+ If <replaceable>N</replaceable> is specified and is greater than zero,
+ then the <replaceable>N</replaceable>'th match of the pattern
+ is replaced.
+ If the <literal>g</literal> flag is given, or
+ if <replaceable>N</replaceable> is specified and is zero, then all
+ matches at or after the <replaceable>start</replaceable> position are
+ replaced. (The <literal>g</literal> flag is ignored
+ when <replaceable>N</replaceable> is specified.)
+ The <replaceable>flags</replaceable> parameter is an optional text
+ string containing zero or more single-letter flags that change the
+ function's behavior. Supported flags (though
+ not <literal>g</literal>) are
+ described in <xref linkend="posix-embedded-options-table"/>.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+regexp_replace('foobarbaz', 'b..', 'X')
+ <lineannotation>fooXbaz</lineannotation>
+regexp_replace('foobarbaz', 'b..', 'X', 'g')
+ <lineannotation>fooXX</lineannotation>
+regexp_replace('foobarbaz', 'b(..)', 'X\1Y', 'g')
+ <lineannotation>fooXarYXazY</lineannotation>
+regexp_replace('A PostgreSQL function', 'a|e|i|o|u', 'X', 1, 0, 'i')
+ <lineannotation>X PXstgrXSQL fXnctXXn</lineannotation>
+regexp_replace('A PostgreSQL function', 'a|e|i|o|u', 'X', 1, 3, 'i')
+ <lineannotation>A PostgrXSQL function</lineannotation>
+</programlisting>
+ </para>
+
+ <para>
+ The <function>regexp_split_to_table</function> function splits a string using a POSIX
+ regular expression pattern as a delimiter. It has the syntax
+ <function>regexp_split_to_table</function>(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>
+ <optional>, <replaceable>flags</replaceable> </optional>).
+ If there is no match to the <replaceable>pattern</replaceable>, the function returns the
+ <replaceable>string</replaceable>. If there is at least one match, for each match it returns
+ the text from the end of the last match (or the beginning of the string)
+ to the beginning of the match. When there are no more matches, it
+ returns the text from the end of the last match to the end of the string.
+ The <replaceable>flags</replaceable> parameter is an optional text string containing
+ zero or more single-letter flags that change the function's behavior.
+ <function>regexp_split_to_table</function> supports the flags described in
+ <xref linkend="posix-embedded-options-table"/>.
+ </para>
+
+ <para>
+ The <function>regexp_split_to_array</function> function behaves the same as
+ <function>regexp_split_to_table</function>, except that <function>regexp_split_to_array</function>
+ returns its result as an array of <type>text</type>. It has the syntax
+ <function>regexp_split_to_array</function>(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>
+ <optional>, <replaceable>flags</replaceable> </optional>).
+ The parameters are the same as for <function>regexp_split_to_table</function>.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+SELECT foo FROM regexp_split_to_table('the quick brown fox jumps over the lazy dog', '\s+') AS foo;
+ foo
+-------
+ the
+ quick
+ brown
+ fox
+ jumps
+ over
+ the
+ lazy
+ dog
+(9 rows)
+
+SELECT regexp_split_to_array('the quick brown fox jumps over the lazy dog', '\s+');
+ regexp_split_to_array
+-----------------------------------------------
+ {the,quick,brown,fox,jumps,over,the,lazy,dog}
+(1 row)
+
+SELECT foo FROM regexp_split_to_table('the quick brown fox', '\s*') AS foo;
+ foo
+-----
+ t
+ h
+ e
+ q
+ u
+ i
+ c
+ k
+ b
+ r
+ o
+ w
+ n
+ f
+ o
+ x
+(16 rows)
+</programlisting>
+ </para>
+
+ <para>
+ As the last example demonstrates, the regexp split functions ignore
+ zero-length matches that occur at the start or end of the string
+ or immediately after a previous match. This is contrary to the strict
+ definition of regexp matching that is implemented by
+ the other regexp functions, but is usually the most convenient behavior
+ in practice. Other software systems such as Perl use similar definitions.
+ </para>
+
+ <para>
+ The <function>regexp_substr</function> function returns the substring
+ that matches a POSIX regular expression pattern,
+ or <literal>NULL</literal> if there is no match. It has the syntax
+ <function>regexp_substr</function>(<replaceable>string</replaceable>,
+ <replaceable>pattern</replaceable>
+ <optional>, <replaceable>start</replaceable>
+ <optional>, <replaceable>N</replaceable>
+ <optional>, <replaceable>flags</replaceable>
+ <optional>, <replaceable>subexpr</replaceable>
+ </optional></optional></optional></optional>).
+ <replaceable>pattern</replaceable> is searched for
+ in <replaceable>string</replaceable>, normally from the beginning of
+ the string, but if the <replaceable>start</replaceable> parameter is
+ provided then beginning from that character index.
+ If <replaceable>N</replaceable> is specified
+ then the <replaceable>N</replaceable>'th match of the pattern
+ is returned, otherwise the first match is returned.
+ The <replaceable>flags</replaceable> parameter is an optional text
+ string containing zero or more single-letter flags that change the
+ function's behavior. Supported flags are described
+ in <xref linkend="posix-embedded-options-table"/>.
+ For a pattern containing parenthesized
+ subexpressions, <replaceable>subexpr</replaceable> is an integer
+ indicating which subexpression is of interest: the result is the
+ substring matching that subexpression.
+ Subexpressions are numbered in the order of their leading parentheses.
+ When <replaceable>subexpr</replaceable> is omitted or zero, the result
+ is the whole match regardless of parenthesized subexpressions.
+ </para>
+
+ <para>
+ Some examples:
+<programlisting>
+regexp_substr('number of your street, town zip, FR', '[^,]+', 1, 2)
+ <lineannotation> town zip</lineannotation>
+regexp_substr('ABCDEFGHI', '(c..)(...)', 1, 1, 'i', 2)
+ <lineannotation>FGH</lineannotation>
+</programlisting>
+ </para>
+
+<!-- derived from the re_syntax.n man page -->
+
+ <sect3 id="posix-syntax-details">
+ <title>Regular Expression Details</title>
+
+ <para>
+ <productname>PostgreSQL</productname>'s regular expressions are implemented
+ using a software package written by Henry Spencer. Much of
+ the description of regular expressions below is copied verbatim from his
+ manual.
+ </para>
+
+ <para>
+ Regular expressions (<acronym>RE</acronym>s), as defined in
+ <acronym>POSIX</acronym> 1003.2, come in two forms:
+ <firstterm>extended</firstterm> <acronym>RE</acronym>s or <acronym>ERE</acronym>s
+ (roughly those of <command>egrep</command>), and
+ <firstterm>basic</firstterm> <acronym>RE</acronym>s or <acronym>BRE</acronym>s
+ (roughly those of <command>ed</command>).
+ <productname>PostgreSQL</productname> supports both forms, and
+ also implements some extensions
+ that are not in the POSIX standard, but have become widely used
+ due to their availability in programming languages such as Perl and Tcl.
+ <acronym>RE</acronym>s using these non-POSIX extensions are called
+ <firstterm>advanced</firstterm> <acronym>RE</acronym>s or <acronym>ARE</acronym>s
+ in this documentation. AREs are almost an exact superset of EREs,
+ but BREs have several notational incompatibilities (as well as being
+ much more limited).
+ We first describe the ARE and ERE forms, noting features that apply
+ only to AREs, and then describe how BREs differ.
+ </para>
+
+ <note>
+ <para>
+ <productname>PostgreSQL</productname> always initially presumes that a regular
+ expression follows the ARE rules. However, the more limited ERE or
+ BRE rules can be chosen by prepending an <firstterm>embedded option</firstterm>
+ to the RE pattern, as described in <xref linkend="posix-metasyntax"/>.
+ This can be useful for compatibility with applications that expect
+ exactly the <acronym>POSIX</acronym> 1003.2 rules.
+ </para>
+ </note>
+
+ <para>
+ A regular expression is defined as one or more
+ <firstterm>branches</firstterm>, separated by
+ <literal>|</literal>. It matches anything that matches one of the
+ branches.
+ </para>
+
+ <para>
+ A branch is zero or more <firstterm>quantified atoms</firstterm> or
+ <firstterm>constraints</firstterm>, concatenated.
+ It matches a match for the first, followed by a match for the second, etc.;
+ an empty branch matches the empty string.
+ </para>
+
+ <para>
+ A quantified atom is an <firstterm>atom</firstterm> possibly followed
+ by a single <firstterm>quantifier</firstterm>.
+ Without a quantifier, it matches a match for the atom.
+ With a quantifier, it can match some number of matches of the atom.
+ An <firstterm>atom</firstterm> can be any of the possibilities
+ shown in <xref linkend="posix-atoms-table"/>.
+ The possible quantifiers and their meanings are shown in
+ <xref linkend="posix-quantifiers-table"/>.
+ </para>
+
+ <para>
+ A <firstterm>constraint</firstterm> matches an empty string, but matches only when
+ specific conditions are met. A constraint can be used where an atom
+ could be used, except it cannot be followed by a quantifier.
+ The simple constraints are shown in
+ <xref linkend="posix-constraints-table"/>;
+ some more constraints are described later.
+ </para>
+
+
+ <table id="posix-atoms-table">
+ <title>Regular Expression Atoms</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Atom</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>(</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> (where <replaceable>re</replaceable> is any regular expression)
+ matches a match for
+ <replaceable>re</replaceable>, with the match noted for possible reporting </entry>
+ </row>
+
+ <row>
+ <entry> <literal>(?:</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> as above, but the match is not noted for reporting
+ (a <quote>non-capturing</quote> set of parentheses)
+ (AREs only) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>.</literal> </entry>
+ <entry> matches any single character </entry>
+ </row>
+
+ <row>
+ <entry> <literal>[</literal><replaceable>chars</replaceable><literal>]</literal> </entry>
+ <entry> a <firstterm>bracket expression</firstterm>,
+ matching any one of the <replaceable>chars</replaceable> (see
+ <xref linkend="posix-bracket-expressions"/> for more detail) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\</literal><replaceable>k</replaceable> </entry>
+ <entry> (where <replaceable>k</replaceable> is a non-alphanumeric character)
+ matches that character taken as an ordinary character,
+ e.g., <literal>\\</literal> matches a backslash character </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\</literal><replaceable>c</replaceable> </entry>
+ <entry> where <replaceable>c</replaceable> is alphanumeric
+ (possibly followed by other characters)
+ is an <firstterm>escape</firstterm>, see <xref linkend="posix-escape-sequences"/>
+ (AREs only; in EREs and BREs, this matches <replaceable>c</replaceable>) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>{</literal> </entry>
+ <entry> when followed by a character other than a digit,
+ matches the left-brace character <literal>{</literal>;
+ when followed by a digit, it is the beginning of a
+ <replaceable>bound</replaceable> (see below) </entry>
+ </row>
+
+ <row>
+ <entry> <replaceable>x</replaceable> </entry>
+ <entry> where <replaceable>x</replaceable> is a single character with no other
+ significance, matches that character </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ An RE cannot end with a backslash (<literal>\</literal>).
+ </para>
+
+ <note>
+ <para>
+ If you have <xref linkend="guc-standard-conforming-strings"/> turned off,
+ any backslashes you write in literal string constants will need to be
+ doubled. See <xref linkend="sql-syntax-strings"/> for more information.
+ </para>
+ </note>
+
+ <table id="posix-quantifiers-table">
+ <title>Regular Expression Quantifiers</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Quantifier</entry>
+ <entry>Matches</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>*</literal> </entry>
+ <entry> a sequence of 0 or more matches of the atom </entry>
+ </row>
+
+ <row>
+ <entry> <literal>+</literal> </entry>
+ <entry> a sequence of 1 or more matches of the atom </entry>
+ </row>
+
+ <row>
+ <entry> <literal>?</literal> </entry>
+ <entry> a sequence of 0 or 1 matches of the atom </entry>
+ </row>
+
+ <row>
+ <entry> <literal>{</literal><replaceable>m</replaceable><literal>}</literal> </entry>
+ <entry> a sequence of exactly <replaceable>m</replaceable> matches of the atom </entry>
+ </row>
+
+ <row>
+ <entry> <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> </entry>
+ <entry> a sequence of <replaceable>m</replaceable> or more matches of the atom </entry>
+ </row>
+
+ <row>
+ <entry>
+ <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal> </entry>
+ <entry> a sequence of <replaceable>m</replaceable> through <replaceable>n</replaceable>
+ (inclusive) matches of the atom; <replaceable>m</replaceable> cannot exceed
+ <replaceable>n</replaceable> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>*?</literal> </entry>
+ <entry> non-greedy version of <literal>*</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>+?</literal> </entry>
+ <entry> non-greedy version of <literal>+</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>??</literal> </entry>
+ <entry> non-greedy version of <literal>?</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>{</literal><replaceable>m</replaceable><literal>}?</literal> </entry>
+ <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>}</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>{</literal><replaceable>m</replaceable><literal>,}?</literal> </entry>
+ <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> </entry>
+ </row>
+
+ <row>
+ <entry>
+ <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}?</literal> </entry>
+ <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal> </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The forms using <literal>{</literal><replaceable>...</replaceable><literal>}</literal>
+ are known as <firstterm>bounds</firstterm>.
+ The numbers <replaceable>m</replaceable> and <replaceable>n</replaceable> within a bound are
+ unsigned decimal integers with permissible values from 0 to 255 inclusive.
+ </para>
+
+ <para>
+ <firstterm>Non-greedy</firstterm> quantifiers (available in AREs only) match the
+ same possibilities as their corresponding normal (<firstterm>greedy</firstterm>)
+ counterparts, but prefer the smallest number rather than the largest
+ number of matches.
+ See <xref linkend="posix-matching-rules"/> for more detail.
+ </para>
+
+ <note>
+ <para>
+ A quantifier cannot immediately follow another quantifier, e.g.,
+ <literal>**</literal> is invalid.
+ A quantifier cannot
+ begin an expression or subexpression or follow
+ <literal>^</literal> or <literal>|</literal>.
+ </para>
+ </note>
+
+ <table id="posix-constraints-table">
+ <title>Regular Expression Constraints</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Constraint</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>^</literal> </entry>
+ <entry> matches at the beginning of the string </entry>
+ </row>
+
+ <row>
+ <entry> <literal>$</literal> </entry>
+ <entry> matches at the end of the string </entry>
+ </row>
+
+ <row>
+ <entry> <literal>(?=</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> <firstterm>positive lookahead</firstterm> matches at any point
+ where a substring matching <replaceable>re</replaceable> begins
+ (AREs only) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>(?!</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> <firstterm>negative lookahead</firstterm> matches at any point
+ where no substring matching <replaceable>re</replaceable> begins
+ (AREs only) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>(?<=</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> <firstterm>positive lookbehind</firstterm> matches at any point
+ where a substring matching <replaceable>re</replaceable> ends
+ (AREs only) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>(?<!</literal><replaceable>re</replaceable><literal>)</literal> </entry>
+ <entry> <firstterm>negative lookbehind</firstterm> matches at any point
+ where no substring matching <replaceable>re</replaceable> ends
+ (AREs only) </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Lookahead and lookbehind constraints cannot contain <firstterm>back
+ references</firstterm> (see <xref linkend="posix-escape-sequences"/>),
+ and all parentheses within them are considered non-capturing.
+ </para>
+ </sect3>
+
+ <sect3 id="posix-bracket-expressions">
+ <title>Bracket Expressions</title>
+
+ <para>
+ A <firstterm>bracket expression</firstterm> is a list of
+ characters enclosed in <literal>[]</literal>. It normally matches
+ any single character from the list (but see below). If the list
+ begins with <literal>^</literal>, it matches any single character
+ <emphasis>not</emphasis> from the rest of the list.
+ If two characters
+ in the list are separated by <literal>-</literal>, this is
+ shorthand for the full range of characters between those two
+ (inclusive) in the collating sequence,
+ e.g., <literal>[0-9]</literal> in <acronym>ASCII</acronym> matches
+ any decimal digit. It is illegal for two ranges to share an
+ endpoint, e.g., <literal>a-c-e</literal>. Ranges are very
+ collating-sequence-dependent, so portable programs should avoid
+ relying on them.
+ </para>
+
+ <para>
+ To include a literal <literal>]</literal> in the list, make it the
+ first character (after <literal>^</literal>, if that is used). To
+ include a literal <literal>-</literal>, make it the first or last
+ character, or the second endpoint of a range. To use a literal
+ <literal>-</literal> as the first endpoint of a range, enclose it
+ in <literal>[.</literal> and <literal>.]</literal> to make it a
+ collating element (see below). With the exception of these characters,
+ some combinations using <literal>[</literal>
+ (see next paragraphs), and escapes (AREs only), all other special
+ characters lose their special significance within a bracket expression.
+ In particular, <literal>\</literal> is not special when following
+ ERE or BRE rules, though it is special (as introducing an escape)
+ in AREs.
+ </para>
+
+ <para>
+ Within a bracket expression, a collating element (a character, a
+ multiple-character sequence that collates as if it were a single
+ character, or a collating-sequence name for either) enclosed in
+ <literal>[.</literal> and <literal>.]</literal> stands for the
+ sequence of characters of that collating element. The sequence is
+ treated as a single element of the bracket expression's list. This
+ allows a bracket
+ expression containing a multiple-character collating element to
+ match more than one character, e.g., if the collating sequence
+ includes a <literal>ch</literal> collating element, then the RE
+ <literal>[[.ch.]]*c</literal> matches the first five characters of
+ <literal>chchcc</literal>.
+ </para>
+
+ <note>
+ <para>
+ <productname>PostgreSQL</productname> currently does not support multi-character collating
+ elements. This information describes possible future behavior.
+ </para>
+ </note>
+
+ <para>
+ Within a bracket expression, a collating element enclosed in
+ <literal>[=</literal> and <literal>=]</literal> is an <firstterm>equivalence
+ class</firstterm>, standing for the sequences of characters of all collating
+ elements equivalent to that one, including itself. (If there are
+ no other equivalent collating elements, the treatment is as if the
+ enclosing delimiters were <literal>[.</literal> and
+ <literal>.]</literal>.) For example, if <literal>o</literal> and
+ <literal>^</literal> are the members of an equivalence class, then
+ <literal>[[=o=]]</literal>, <literal>[[=^=]]</literal>, and
+ <literal>[o^]</literal> are all synonymous. An equivalence class
+ cannot be an endpoint of a range.
+ </para>
+
+ <para>
+ Within a bracket expression, the name of a character class
+ enclosed in <literal>[:</literal> and <literal>:]</literal> stands
+ for the list of all characters belonging to that class. A character
+ class cannot be used as an endpoint of a range.
+ The <acronym>POSIX</acronym> standard defines these character class
+ names:
+ <literal>alnum</literal> (letters and numeric digits),
+ <literal>alpha</literal> (letters),
+ <literal>blank</literal> (space and tab),
+ <literal>cntrl</literal> (control characters),
+ <literal>digit</literal> (numeric digits),
+ <literal>graph</literal> (printable characters except space),
+ <literal>lower</literal> (lower-case letters),
+ <literal>print</literal> (printable characters including space),
+ <literal>punct</literal> (punctuation),
+ <literal>space</literal> (any white space),
+ <literal>upper</literal> (upper-case letters),
+ and <literal>xdigit</literal> (hexadecimal digits).
+ The behavior of these standard character classes is generally
+ consistent across platforms for characters in the 7-bit ASCII set.
+ Whether a given non-ASCII character is considered to belong to one
+ of these classes depends on the <firstterm>collation</firstterm>
+ that is used for the regular-expression function or operator
+ (see <xref linkend="collation"/>), or by default on the
+ database's <envar>LC_CTYPE</envar> locale setting (see
+ <xref linkend="locale"/>). The classification of non-ASCII
+ characters can vary across platforms even in similarly-named
+ locales. (But the <literal>C</literal> locale never considers any
+ non-ASCII characters to belong to any of these classes.)
+ In addition to these standard character
+ classes, <productname>PostgreSQL</productname> defines
+ the <literal>word</literal> character class, which is the same as
+ <literal>alnum</literal> plus the underscore (<literal>_</literal>)
+ character, and
+ the <literal>ascii</literal> character class, which contains exactly
+ the 7-bit ASCII set.
+ </para>
+
+ <para>
+ There are two special cases of bracket expressions: the bracket
+ expressions <literal>[[:<:]]</literal> and
+ <literal>[[:>:]]</literal> are constraints,
+ matching empty strings at the beginning
+ and end of a word respectively. A word is defined as a sequence
+ of word characters that is neither preceded nor followed by word
+ characters. A word character is any character belonging to the
+ <literal>word</literal> character class, that is, any letter, digit,
+ or underscore. This is an extension, compatible with but not
+ specified by <acronym>POSIX</acronym> 1003.2, and should be used with
+ caution in software intended to be portable to other systems.
+ The constraint escapes described below are usually preferable; they
+ are no more standard, but are easier to type.
+ </para>
+ </sect3>
+
+ <sect3 id="posix-escape-sequences">
+ <title>Regular Expression Escapes</title>
+
+ <para>
+ <firstterm>Escapes</firstterm> are special sequences beginning with <literal>\</literal>
+ followed by an alphanumeric character. Escapes come in several varieties:
+ character entry, class shorthands, constraint escapes, and back references.
+ A <literal>\</literal> followed by an alphanumeric character but not constituting
+ a valid escape is illegal in AREs.
+ In EREs, there are no escapes: outside a bracket expression,
+ a <literal>\</literal> followed by an alphanumeric character merely stands for
+ that character as an ordinary character, and inside a bracket expression,
+ <literal>\</literal> is an ordinary character.
+ (The latter is the one actual incompatibility between EREs and AREs.)
+ </para>
+
+ <para>
+ <firstterm>Character-entry escapes</firstterm> exist to make it easier to specify
+ non-printing and other inconvenient characters in REs. They are
+ shown in <xref linkend="posix-character-entry-escapes-table"/>.
+ </para>
+
+ <para>
+ <firstterm>Class-shorthand escapes</firstterm> provide shorthands for certain
+ commonly-used character classes. They are
+ shown in <xref linkend="posix-class-shorthand-escapes-table"/>.
+ </para>
+
+ <para>
+ A <firstterm>constraint escape</firstterm> is a constraint,
+ matching the empty string if specific conditions are met,
+ written as an escape. They are
+ shown in <xref linkend="posix-constraint-escapes-table"/>.
+ </para>
+
+ <para>
+ A <firstterm>back reference</firstterm> (<literal>\</literal><replaceable>n</replaceable>) matches the
+ same string matched by the previous parenthesized subexpression specified
+ by the number <replaceable>n</replaceable>
+ (see <xref linkend="posix-constraint-backref-table"/>). For example,
+ <literal>([bc])\1</literal> matches <literal>bb</literal> or <literal>cc</literal>
+ but not <literal>bc</literal> or <literal>cb</literal>.
+ The subexpression must entirely precede the back reference in the RE.
+ Subexpressions are numbered in the order of their leading parentheses.
+ Non-capturing parentheses do not define subexpressions.
+ The back reference considers only the string characters matched by the
+ referenced subexpression, not any constraints contained in it. For
+ example, <literal>(^\d)\1</literal> will match <literal>22</literal>.
+ </para>
+
+ <table id="posix-character-entry-escapes-table">
+ <title>Regular Expression Character-Entry Escapes</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Escape</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>\a</literal> </entry>
+ <entry> alert (bell) character, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\b</literal> </entry>
+ <entry> backspace, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\B</literal> </entry>
+ <entry> synonym for backslash (<literal>\</literal>) to help reduce the need for backslash
+ doubling </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\c</literal><replaceable>X</replaceable> </entry>
+ <entry> (where <replaceable>X</replaceable> is any character) the character whose
+ low-order 5 bits are the same as those of
+ <replaceable>X</replaceable>, and whose other bits are all zero </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\e</literal> </entry>
+ <entry> the character whose collating-sequence name
+ is <literal>ESC</literal>,
+ or failing that, the character with octal value <literal>033</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\f</literal> </entry>
+ <entry> form feed, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\n</literal> </entry>
+ <entry> newline, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\r</literal> </entry>
+ <entry> carriage return, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\t</literal> </entry>
+ <entry> horizontal tab, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\u</literal><replaceable>wxyz</replaceable> </entry>
+ <entry> (where <replaceable>wxyz</replaceable> is exactly four hexadecimal digits)
+ the character whose hexadecimal value is
+ <literal>0x</literal><replaceable>wxyz</replaceable>
+ </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\U</literal><replaceable>stuvwxyz</replaceable> </entry>
+ <entry> (where <replaceable>stuvwxyz</replaceable> is exactly eight hexadecimal
+ digits)
+ the character whose hexadecimal value is
+ <literal>0x</literal><replaceable>stuvwxyz</replaceable>
+ </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\v</literal> </entry>
+ <entry> vertical tab, as in C </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\x</literal><replaceable>hhh</replaceable> </entry>
+ <entry> (where <replaceable>hhh</replaceable> is any sequence of hexadecimal
+ digits)
+ the character whose hexadecimal value is
+ <literal>0x</literal><replaceable>hhh</replaceable>
+ (a single character no matter how many hexadecimal digits are used)
+ </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\0</literal> </entry>
+ <entry> the character whose value is <literal>0</literal> (the null byte)</entry>
+ </row>
+
+ <row>
+ <entry> <literal>\</literal><replaceable>xy</replaceable> </entry>
+ <entry> (where <replaceable>xy</replaceable> is exactly two octal digits,
+ and is not a <firstterm>back reference</firstterm>)
+ the character whose octal value is
+ <literal>0</literal><replaceable>xy</replaceable> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\</literal><replaceable>xyz</replaceable> </entry>
+ <entry> (where <replaceable>xyz</replaceable> is exactly three octal digits,
+ and is not a <firstterm>back reference</firstterm>)
+ the character whose octal value is
+ <literal>0</literal><replaceable>xyz</replaceable> </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Hexadecimal digits are <literal>0</literal>-<literal>9</literal>,
+ <literal>a</literal>-<literal>f</literal>, and <literal>A</literal>-<literal>F</literal>.
+ Octal digits are <literal>0</literal>-<literal>7</literal>.
+ </para>
+
+ <para>
+ Numeric character-entry escapes specifying values outside the ASCII range
+ (0–127) have meanings dependent on the database encoding. When the
+ encoding is UTF-8, escape values are equivalent to Unicode code points,
+ for example <literal>\u1234</literal> means the character <literal>U+1234</literal>.
+ For other multibyte encodings, character-entry escapes usually just
+ specify the concatenation of the byte values for the character. If the
+ escape value does not correspond to any legal character in the database
+ encoding, no error will be raised, but it will never match any data.
+ </para>
+
+ <para>
+ The character-entry escapes are always taken as ordinary characters.
+ For example, <literal>\135</literal> is <literal>]</literal> in ASCII, but
+ <literal>\135</literal> does not terminate a bracket expression.
+ </para>
+
+ <table id="posix-class-shorthand-escapes-table">
+ <title>Regular Expression Class-Shorthand Escapes</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Escape</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>\d</literal> </entry>
+ <entry> matches any digit, like
+ <literal>[[:digit:]]</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\s</literal> </entry>
+ <entry> matches any whitespace character, like
+ <literal>[[:space:]]</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\w</literal> </entry>
+ <entry> matches any word character, like
+ <literal>[[:word:]]</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\D</literal> </entry>
+ <entry> matches any non-digit, like
+ <literal>[^[:digit:]]</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\S</literal> </entry>
+ <entry> matches any non-whitespace character, like
+ <literal>[^[:space:]]</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\W</literal> </entry>
+ <entry> matches any non-word character, like
+ <literal>[^[:word:]]</literal> </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The class-shorthand escapes also work within bracket expressions,
+ although the definitions shown above are not quite syntactically
+ valid in that context.
+ For example, <literal>[a-c\d]</literal> is equivalent to
+ <literal>[a-c[:digit:]]</literal>.
+ </para>
+
+ <table id="posix-constraint-escapes-table">
+ <title>Regular Expression Constraint Escapes</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Escape</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>\A</literal> </entry>
+ <entry> matches only at the beginning of the string
+ (see <xref linkend="posix-matching-rules"/> for how this differs from
+ <literal>^</literal>) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\m</literal> </entry>
+ <entry> matches only at the beginning of a word </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\M</literal> </entry>
+ <entry> matches only at the end of a word </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\y</literal> </entry>
+ <entry> matches only at the beginning or end of a word </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\Y</literal> </entry>
+ <entry> matches only at a point that is not the beginning or end of a
+ word </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\Z</literal> </entry>
+ <entry> matches only at the end of the string
+ (see <xref linkend="posix-matching-rules"/> for how this differs from
+ <literal>$</literal>) </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ A word is defined as in the specification of
+ <literal>[[:<:]]</literal> and <literal>[[:>:]]</literal> above.
+ Constraint escapes are illegal within bracket expressions.
+ </para>
+
+ <table id="posix-constraint-backref-table">
+ <title>Regular Expression Back References</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Escape</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>\</literal><replaceable>m</replaceable> </entry>
+ <entry> (where <replaceable>m</replaceable> is a nonzero digit)
+ a back reference to the <replaceable>m</replaceable>'th subexpression </entry>
+ </row>
+
+ <row>
+ <entry> <literal>\</literal><replaceable>mnn</replaceable> </entry>
+ <entry> (where <replaceable>m</replaceable> is a nonzero digit, and
+ <replaceable>nn</replaceable> is some more digits, and the decimal value
+ <replaceable>mnn</replaceable> is not greater than the number of closing capturing
+ parentheses seen so far)
+ a back reference to the <replaceable>mnn</replaceable>'th subexpression </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <note>
+ <para>
+ There is an inherent ambiguity between octal character-entry
+ escapes and back references, which is resolved by the following heuristics,
+ as hinted at above.
+ A leading zero always indicates an octal escape.
+ A single non-zero digit, not followed by another digit,
+ is always taken as a back reference.
+ A multi-digit sequence not starting with a zero is taken as a back
+ reference if it comes after a suitable subexpression
+ (i.e., the number is in the legal range for a back reference),
+ and otherwise is taken as octal.
+ </para>
+ </note>
+ </sect3>
+
+ <sect3 id="posix-metasyntax">
+ <title>Regular Expression Metasyntax</title>
+
+ <para>
+ In addition to the main syntax described above, there are some special
+ forms and miscellaneous syntactic facilities available.
+ </para>
+
+ <para>
+ An RE can begin with one of two special <firstterm>director</firstterm> prefixes.
+ If an RE begins with <literal>***:</literal>,
+ the rest of the RE is taken as an ARE. (This normally has no effect in
+ <productname>PostgreSQL</productname>, since REs are assumed to be AREs;
+ but it does have an effect if ERE or BRE mode had been specified by
+ the <replaceable>flags</replaceable> parameter to a regex function.)
+ If an RE begins with <literal>***=</literal>,
+ the rest of the RE is taken to be a literal string,
+ with all characters considered ordinary characters.
+ </para>
+
+ <para>
+ An ARE can begin with <firstterm>embedded options</firstterm>:
+ a sequence <literal>(?</literal><replaceable>xyz</replaceable><literal>)</literal>
+ (where <replaceable>xyz</replaceable> is one or more alphabetic characters)
+ specifies options affecting the rest of the RE.
+ These options override any previously determined options —
+ in particular, they can override the case-sensitivity behavior implied by
+ a regex operator, or the <replaceable>flags</replaceable> parameter to a regex
+ function.
+ The available option letters are
+ shown in <xref linkend="posix-embedded-options-table"/>.
+ Note that these same option letters are used in the <replaceable>flags</replaceable>
+ parameters of regex functions.
+ </para>
+
+ <table id="posix-embedded-options-table">
+ <title>ARE Embedded-Option Letters</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>Option</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry> <literal>b</literal> </entry>
+ <entry> rest of RE is a BRE </entry>
+ </row>
+
+ <row>
+ <entry> <literal>c</literal> </entry>
+ <entry> case-sensitive matching (overrides operator type) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>e</literal> </entry>
+ <entry> rest of RE is an ERE </entry>
+ </row>
+
+ <row>
+ <entry> <literal>i</literal> </entry>
+ <entry> case-insensitive matching (see
+ <xref linkend="posix-matching-rules"/>) (overrides operator type) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>m</literal> </entry>
+ <entry> historical synonym for <literal>n</literal> </entry>
+ </row>
+
+ <row>
+ <entry> <literal>n</literal> </entry>
+ <entry> newline-sensitive matching (see
+ <xref linkend="posix-matching-rules"/>) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>p</literal> </entry>
+ <entry> partial newline-sensitive matching (see
+ <xref linkend="posix-matching-rules"/>) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>q</literal> </entry>
+ <entry> rest of RE is a literal (<quote>quoted</quote>) string, all ordinary
+ characters </entry>
+ </row>
+
+ <row>
+ <entry> <literal>s</literal> </entry>
+ <entry> non-newline-sensitive matching (default) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>t</literal> </entry>
+ <entry> tight syntax (default; see below) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>w</literal> </entry>
+ <entry> inverse partial newline-sensitive (<quote>weird</quote>) matching
+ (see <xref linkend="posix-matching-rules"/>) </entry>
+ </row>
+
+ <row>
+ <entry> <literal>x</literal> </entry>
+ <entry> expanded syntax (see below) </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Embedded options take effect at the <literal>)</literal> terminating the sequence.
+ They can appear only at the start of an ARE (after the
+ <literal>***:</literal> director if any).
+ </para>
+
+ <para>
+ In addition to the usual (<firstterm>tight</firstterm>) RE syntax, in which all
+ characters are significant, there is an <firstterm>expanded</firstterm> syntax,
+ available by specifying the embedded <literal>x</literal> option.
+ In the expanded syntax,
+ white-space characters in the RE are ignored, as are
+ all characters between a <literal>#</literal>
+ and the following newline (or the end of the RE). This
+ permits paragraphing and commenting a complex RE.
+ There are three exceptions to that basic rule:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ a white-space character or <literal>#</literal> preceded by <literal>\</literal> is
+ retained
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ white space or <literal>#</literal> within a bracket expression is retained
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ white space and comments cannot appear within multi-character symbols,
+ such as <literal>(?:</literal>
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ For this purpose, white-space characters are blank, tab, newline, and
+ any character that belongs to the <replaceable>space</replaceable> character class.
+ </para>
+
+ <para>
+ Finally, in an ARE, outside bracket expressions, the sequence
+ <literal>(?#</literal><replaceable>ttt</replaceable><literal>)</literal>
+ (where <replaceable>ttt</replaceable> is any text not containing a <literal>)</literal>)
+ is a comment, completely ignored.
+ Again, this is not allowed between the characters of
+ multi-character symbols, like <literal>(?:</literal>.
+ Such comments are more a historical artifact than a useful facility,
+ and their use is deprecated; use the expanded syntax instead.
+ </para>
+
+ <para>
+ <emphasis>None</emphasis> of these metasyntax extensions is available if
+ an initial <literal>***=</literal> director
+ has specified that the user's input be treated as a literal string
+ rather than as an RE.
+ </para>
+ </sect3>
+
+ <sect3 id="posix-matching-rules">
+ <title>Regular Expression Matching Rules</title>
+
+ <para>
+ In the event that an RE could match more than one substring of a given
+ string, the RE matches the one starting earliest in the string.
+ If the RE could match more than one substring starting at that point,
+ either the longest possible match or the shortest possible match will
+ be taken, depending on whether the RE is <firstterm>greedy</firstterm> or
+ <firstterm>non-greedy</firstterm>.
+ </para>
+
+ <para>
+ Whether an RE is greedy or not is determined by the following rules:
+ <itemizedlist>
+ <listitem>
+ <para>
+ Most atoms, and all constraints, have no greediness attribute (because
+ they cannot match variable amounts of text anyway).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Adding parentheses around an RE does not change its greediness.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A quantified atom with a fixed-repetition quantifier
+ (<literal>{</literal><replaceable>m</replaceable><literal>}</literal>
+ or
+ <literal>{</literal><replaceable>m</replaceable><literal>}?</literal>)
+ has the same greediness (possibly none) as the atom itself.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A quantified atom with other normal quantifiers (including
+ <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal>
+ with <replaceable>m</replaceable> equal to <replaceable>n</replaceable>)
+ is greedy (prefers longest match).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A quantified atom with a non-greedy quantifier (including
+ <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}?</literal>
+ with <replaceable>m</replaceable> equal to <replaceable>n</replaceable>)
+ is non-greedy (prefers shortest match).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A branch — that is, an RE that has no top-level
+ <literal>|</literal> operator — has the same greediness as the first
+ quantified atom in it that has a greediness attribute.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ An RE consisting of two or more branches connected by the
+ <literal>|</literal> operator is always greedy.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The above rules associate greediness attributes not only with individual
+ quantified atoms, but with branches and entire REs that contain quantified
+ atoms. What that means is that the matching is done in such a way that
+ the branch, or whole RE, matches the longest or shortest possible
+ substring <emphasis>as a whole</emphasis>. Once the length of the entire match
+ is determined, the part of it that matches any particular subexpression
+ is determined on the basis of the greediness attribute of that
+ subexpression, with subexpressions starting earlier in the RE taking
+ priority over ones starting later.
+ </para>
+
+ <para>
+ An example of what this means:
+<screen>
+SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
+<lineannotation>Result: </lineannotation><computeroutput>123</computeroutput>
+SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
+<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
+</screen>
+ In the first case, the RE as a whole is greedy because <literal>Y*</literal>
+ is greedy. It can match beginning at the <literal>Y</literal>, and it matches
+ the longest possible string starting there, i.e., <literal>Y123</literal>.
+ The output is the parenthesized part of that, or <literal>123</literal>.
+ In the second case, the RE as a whole is non-greedy because <literal>Y*?</literal>
+ is non-greedy. It can match beginning at the <literal>Y</literal>, and it matches
+ the shortest possible string starting there, i.e., <literal>Y1</literal>.
+ The subexpression <literal>[0-9]{1,3}</literal> is greedy but it cannot change
+ the decision as to the overall match length; so it is forced to match
+ just <literal>1</literal>.
+ </para>
+
+ <para>
+ In short, when an RE contains both greedy and non-greedy subexpressions,
+ the total match length is either as long as possible or as short as
+ possible, according to the attribute assigned to the whole RE. The
+ attributes assigned to the subexpressions only affect how much of that
+ match they are allowed to <quote>eat</quote> relative to each other.
+ </para>
+
+ <para>
+ The quantifiers <literal>{1,1}</literal> and <literal>{1,1}?</literal>
+ can be used to force greediness or non-greediness, respectively,
+ on a subexpression or a whole RE.
+ This is useful when you need the whole RE to have a greediness attribute
+ different from what's deduced from its elements. As an example,
+ suppose that we are trying to separate a string containing some digits
+ into the digits and the parts before and after them. We might try to
+ do that like this:
+<screen>
+SELECT regexp_match('abc01234xyz', '(.*)(\d+)(.*)');
+<lineannotation>Result: </lineannotation><computeroutput>{abc0123,4,xyz}</computeroutput>
+</screen>
+ That didn't work: the first <literal>.*</literal> is greedy so
+ it <quote>eats</quote> as much as it can, leaving the <literal>\d+</literal> to
+ match at the last possible place, the last digit. We might try to fix
+ that by making it non-greedy:
+<screen>
+SELECT regexp_match('abc01234xyz', '(.*?)(\d+)(.*)');
+<lineannotation>Result: </lineannotation><computeroutput>{abc,0,""}</computeroutput>
+</screen>
+ That didn't work either, because now the RE as a whole is non-greedy
+ and so it ends the overall match as soon as possible. We can get what
+ we want by forcing the RE as a whole to be greedy:
+<screen>
+SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
+<lineannotation>Result: </lineannotation><computeroutput>{abc,01234,xyz}</computeroutput>
+</screen>
+ Controlling the RE's overall greediness separately from its components'
+ greediness allows great flexibility in handling variable-length patterns.
+ </para>
+
+ <para>
+ When deciding what is a longer or shorter match,
+ match lengths are measured in characters, not collating elements.
+ An empty string is considered longer than no match at all.
+ For example:
+ <literal>bb*</literal>
+ matches the three middle characters of <literal>abbbc</literal>;
+ <literal>(week|wee)(night|knights)</literal>
+ matches all ten characters of <literal>weeknights</literal>;
+ when <literal>(.*).*</literal>
+ is matched against <literal>abc</literal> the parenthesized subexpression
+ matches all three characters; and when
+ <literal>(a*)*</literal> is matched against <literal>bc</literal>
+ both the whole RE and the parenthesized
+ subexpression match an empty string.
+ </para>
+
+ <para>
+ If case-independent matching is specified,
+ the effect is much as if all case distinctions had vanished from the
+ alphabet.
+ When an alphabetic that exists in multiple cases appears as an
+ ordinary character outside a bracket expression, it is effectively
+ transformed into a bracket expression containing both cases,
+ e.g., <literal>x</literal> becomes <literal>[xX]</literal>.
+ When it appears inside a bracket expression, all case counterparts
+ of it are added to the bracket expression, e.g.,
+ <literal>[x]</literal> becomes <literal>[xX]</literal>
+ and <literal>[^x]</literal> becomes <literal>[^xX]</literal>.
+ </para>
+
+ <para>
+ If newline-sensitive matching is specified, <literal>.</literal>
+ and bracket expressions using <literal>^</literal>
+ will never match the newline character
+ (so that matches will not cross lines unless the RE
+ explicitly includes a newline)
+ and <literal>^</literal> and <literal>$</literal>
+ will match the empty string after and before a newline
+ respectively, in addition to matching at beginning and end of string
+ respectively.
+ But the ARE escapes <literal>\A</literal> and <literal>\Z</literal>
+ continue to match beginning or end of string <emphasis>only</emphasis>.
+ Also, the character class shorthands <literal>\D</literal>
+ and <literal>\W</literal> will match a newline regardless of this mode.
+ (Before <productname>PostgreSQL</productname> 14, they did not match
+ newlines when in newline-sensitive mode.
+ Write <literal>[^[:digit:]]</literal>
+ or <literal>[^[:word:]]</literal> to get the old behavior.)
+ </para>
+
+ <para>
+ If partial newline-sensitive matching is specified,
+ this affects <literal>.</literal> and bracket expressions
+ as with newline-sensitive matching, but not <literal>^</literal>
+ and <literal>$</literal>.
+ </para>
+
+ <para>
+ If inverse partial newline-sensitive matching is specified,
+ this affects <literal>^</literal> and <literal>$</literal>
+ as with newline-sensitive matching, but not <literal>.</literal>
+ and bracket expressions.
+ This isn't very useful but is provided for symmetry.
+ </para>
+ </sect3>
+
+ <sect3 id="posix-limits-compatibility">
+ <title>Limits and Compatibility</title>
+
+ <para>
+ No particular limit is imposed on the length of REs in this
+ implementation. However,
+ programs intended to be highly portable should not employ REs longer
+ than 256 bytes,
+ as a POSIX-compliant implementation can refuse to accept such REs.
+ </para>
+
+ <para>
+ The only feature of AREs that is actually incompatible with
+ POSIX EREs is that <literal>\</literal> does not lose its special
+ significance inside bracket expressions.
+ All other ARE features use syntax which is illegal or has
+ undefined or unspecified effects in POSIX EREs;
+ the <literal>***</literal> syntax of directors likewise is outside the POSIX
+ syntax for both BREs and EREs.
+ </para>
+
+ <para>
+ Many of the ARE extensions are borrowed from Perl, but some have
+ been changed to clean them up, and a few Perl extensions are not present.
+ Incompatibilities of note include <literal>\b</literal>, <literal>\B</literal>,
+ the lack of special treatment for a trailing newline,
+ the addition of complemented bracket expressions to the things
+ affected by newline-sensitive matching,
+ the restrictions on parentheses and back references in lookahead/lookbehind
+ constraints, and the longest/shortest-match (rather than first-match)
+ matching semantics.
+ </para>
+ </sect3>
+
+ <sect3 id="posix-basic-regexes">
+ <title>Basic Regular Expressions</title>
+
+ <para>
+ BREs differ from EREs in several respects.
+ In BREs, <literal>|</literal>, <literal>+</literal>, and <literal>?</literal>
+ are ordinary characters and there is no equivalent
+ for their functionality.
+ The delimiters for bounds are
+ <literal>\{</literal> and <literal>\}</literal>,
+ with <literal>{</literal> and <literal>}</literal>
+ by themselves ordinary characters.
+ The parentheses for nested subexpressions are
+ <literal>\(</literal> and <literal>\)</literal>,
+ with <literal>(</literal> and <literal>)</literal> by themselves ordinary characters.
+ <literal>^</literal> is an ordinary character except at the beginning of the
+ RE or the beginning of a parenthesized subexpression,
+ <literal>$</literal> is an ordinary character except at the end of the
+ RE or the end of a parenthesized subexpression,
+ and <literal>*</literal> is an ordinary character if it appears at the beginning
+ of the RE or the beginning of a parenthesized subexpression
+ (after a possible leading <literal>^</literal>).
+ Finally, single-digit back references are available, and
+ <literal>\<</literal> and <literal>\></literal>
+ are synonyms for
+ <literal>[[:<:]]</literal> and <literal>[[:>:]]</literal>
+ respectively; no other escapes are available in BREs.
+ </para>
+ </sect3>
+
+<!-- end re_syntax.n man page -->
+
+ <sect3 id="posix-vs-xquery">
+ <title>Differences from SQL Standard and XQuery</title>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>LIKE_REGEX</primary>
+ </indexterm>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>OCCURRENCES_REGEX</primary>
+ </indexterm>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>POSITION_REGEX</primary>
+ </indexterm>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>SUBSTRING_REGEX</primary>
+ </indexterm>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>TRANSLATE_REGEX</primary>
+ </indexterm>
+
+ <indexterm zone="posix-vs-xquery">
+ <primary>XQuery regular expressions</primary>
+ </indexterm>
+
+ <para>
+ Since SQL:2008, the SQL standard includes regular expression operators
+ and functions that performs pattern
+ matching according to the XQuery regular expression
+ standard:
+ <itemizedlist>
+ <listitem><para><literal>LIKE_REGEX</literal></para></listitem>
+ <listitem><para><literal>OCCURRENCES_REGEX</literal></para></listitem>
+ <listitem><para><literal>POSITION_REGEX</literal></para></listitem>
+ <listitem><para><literal>SUBSTRING_REGEX</literal></para></listitem>
+ <listitem><para><literal>TRANSLATE_REGEX</literal></para></listitem>
+ </itemizedlist>
+ <productname>PostgreSQL</productname> does not currently implement these
+ operators and functions. You can get approximately equivalent
+ functionality in each case as shown in <xref
+ linkend="functions-regexp-sql-table"/>. (Various optional clauses on
+ both sides have been omitted in this table.)
+ </para>
+
+ <table id="functions-regexp-sql-table">
+ <title>Regular Expression Functions Equivalencies</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>SQL standard</entry>
+ <entry><productname>PostgreSQL</productname></entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><literal><replaceable>string</replaceable> LIKE_REGEX <replaceable>pattern</replaceable></literal></entry>
+ <entry><literal>regexp_like(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal> or <literal><replaceable>string</replaceable> ~ <replaceable>pattern</replaceable></literal></entry>
+ </row>
+
+ <row>
+ <entry><literal>OCCURRENCES_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
+ <entry><literal>regexp_count(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
+ </row>
+
+ <row>
+ <entry><literal>POSITION_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
+ <entry><literal>regexp_instr(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
+ </row>
+
+ <row>
+ <entry><literal>SUBSTRING_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
+ <entry><literal>regexp_substr(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
+ </row>
+
+ <row>
+ <entry><literal>TRANSLATE_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable> WITH <replaceable>replacement</replaceable>)</literal></entry>
+ <entry><literal>regexp_replace(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>, <replaceable>replacement</replaceable>)</literal></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ Regular expression functions similar to those provided by PostgreSQL are
+ also available in a number of other SQL implementations, whereas the
+ SQL-standard functions are not as widely implemented. Some of the
+ details of the regular expression syntax will likely differ in each
+ implementation.
+ </para>
+
+ <para>
+ The SQL-standard operators and functions use XQuery regular expressions,
+ which are quite close to the ARE syntax described above.
+ Notable differences between the existing POSIX-based
+ regular-expression feature and XQuery regular expressions include:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ XQuery character class subtraction is not supported. An example of
+ this feature is using the following to match only English
+ consonants: <literal>[a-z-[aeiou]]</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XQuery character class shorthands <literal>\c</literal>,
+ <literal>\C</literal>, <literal>\i</literal>,
+ and <literal>\I</literal> are not supported.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XQuery character class elements
+ using <literal>\p{UnicodeProperty}</literal> or the
+ inverse <literal>\P{UnicodeProperty}</literal> are not supported.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ POSIX interprets character classes such as <literal>\w</literal>
+ (see <xref linkend="posix-class-shorthand-escapes-table"/>)
+ according to the prevailing locale (which you can control by
+ attaching a <literal>COLLATE</literal> clause to the operator or
+ function). XQuery specifies these classes by reference to Unicode
+ character properties, so equivalent behavior is obtained only with
+ a locale that follows the Unicode rules.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The SQL standard (not XQuery itself) attempts to cater for more
+ variants of <quote>newline</quote> than POSIX does. The
+ newline-sensitive matching options described above consider only
+ ASCII NL (<literal>\n</literal>) to be a newline, but SQL would have
+ us treat CR (<literal>\r</literal>), CRLF (<literal>\r\n</literal>)
+ (a Windows-style newline), and some Unicode-only characters like
+ LINE SEPARATOR (U+2028) as newlines as well.
+ Notably, <literal>.</literal> and <literal>\s</literal> should
+ count <literal>\r\n</literal> as one character not two according to
+ SQL.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Of the character-entry escapes described in
+ <xref linkend="posix-character-entry-escapes-table"/>,
+ XQuery supports only <literal>\n</literal>, <literal>\r</literal>,
+ and <literal>\t</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XQuery does not support
+ the <literal>[:<replaceable>name</replaceable>:]</literal> syntax
+ for character classes within bracket expressions.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XQuery does not have lookahead or lookbehind constraints,
+ nor any of the constraint escapes described in
+ <xref linkend="posix-constraint-escapes-table"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The metasyntax forms described in <xref linkend="posix-metasyntax"/>
+ do not exist in XQuery.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The regular expression flag letters defined by XQuery are
+ related to but not the same as the option letters for POSIX
+ (<xref linkend="posix-embedded-options-table"/>). While the
+ <literal>i</literal> and <literal>q</literal> options behave the
+ same, others do not:
+ <itemizedlist>
+ <listitem>
+ <para>
+ XQuery's <literal>s</literal> (allow dot to match newline)
+ and <literal>m</literal> (allow <literal>^</literal>
+ and <literal>$</literal> to match at newlines) flags provide
+ access to the same behaviors as
+ POSIX's <literal>n</literal>, <literal>p</literal>
+ and <literal>w</literal> flags, but they
+ do <emphasis>not</emphasis> match the behavior of
+ POSIX's <literal>s</literal> and <literal>m</literal> flags.
+ Note in particular that dot-matches-newline is the default
+ behavior in POSIX but not XQuery.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XQuery's <literal>x</literal> (ignore whitespace in pattern) flag
+ is noticeably different from POSIX's expanded-mode flag.
+ POSIX's <literal>x</literal> flag also
+ allows <literal>#</literal> to begin a comment in the pattern,
+ and POSIX will not ignore a whitespace character after a
+ backslash.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ </sect3>
+ </sect2>
+ </sect1>
\ No newline at end of file
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5c0847f4..a49f212d 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -3554,2436 +3554,7 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
</sect1>
- <sect1 id="functions-matching">
- <title>Pattern Matching</title>
-
- <indexterm zone="functions-matching">
- <primary>pattern matching</primary>
- </indexterm>
-
- <para>
- There are three separate approaches to pattern matching provided
- by <productname>PostgreSQL</productname>: the traditional
- <acronym>SQL</acronym> <function>LIKE</function> operator, the
- more recent <function>SIMILAR TO</function> operator (added in
- SQL:1999), and <acronym>POSIX</acronym>-style regular
- expressions. Aside from the basic <quote>does this string match
- this pattern?</quote> operators, functions are available to extract
- or replace matching substrings and to split a string at matching
- locations.
- </para>
-
- <tip>
- <para>
- If you have pattern matching needs that go beyond this,
- consider writing a user-defined function in Perl or Tcl.
- </para>
- </tip>
-
- <caution>
- <para>
- While most regular-expression searches can be executed very quickly,
- regular expressions can be contrived that take arbitrary amounts of
- time and memory to process. Be wary of accepting regular-expression
- search patterns from hostile sources. If you must do so, it is
- advisable to impose a statement timeout.
- </para>
-
- <para>
- Searches using <function>SIMILAR TO</function> patterns have the same
- security hazards, since <function>SIMILAR TO</function> provides many
- of the same capabilities as <acronym>POSIX</acronym>-style regular
- expressions.
- </para>
-
- <para>
- <function>LIKE</function> searches, being much simpler than the other
- two options, are safer to use with possibly-hostile pattern sources.
- </para>
- </caution>
-
- <para>
- The pattern matching operators of all three kinds do not support
- nondeterministic collations. If required, apply a different collation to
- the expression to work around this limitation.
- </para>
-
- <sect2 id="functions-like">
- <title><function>LIKE</function></title>
-
- <indexterm>
- <primary>LIKE</primary>
- </indexterm>
-
-<synopsis>
-<replaceable>string</replaceable> LIKE <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
-<replaceable>string</replaceable> NOT LIKE <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
-</synopsis>
-
- <para>
- The <function>LIKE</function> expression returns true if the
- <replaceable>string</replaceable> matches the supplied
- <replaceable>pattern</replaceable>. (As
- expected, the <function>NOT LIKE</function> expression returns
- false if <function>LIKE</function> returns true, and vice versa.
- An equivalent expression is
- <literal>NOT (<replaceable>string</replaceable> LIKE
- <replaceable>pattern</replaceable>)</literal>.)
- </para>
-
- <para>
- If <replaceable>pattern</replaceable> does not contain percent
- signs or underscores, then the pattern only represents the string
- itself; in that case <function>LIKE</function> acts like the
- equals operator. An underscore (<literal>_</literal>) in
- <replaceable>pattern</replaceable> stands for (matches) any single
- character; a percent sign (<literal>%</literal>) matches any sequence
- of zero or more characters.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-'abc' LIKE 'abc' <lineannotation>true</lineannotation>
-'abc' LIKE 'a%' <lineannotation>true</lineannotation>
-'abc' LIKE '_b_' <lineannotation>true</lineannotation>
-'abc' LIKE 'c' <lineannotation>false</lineannotation>
-</programlisting>
- </para>
-
- <para>
- <function>LIKE</function> pattern matching always covers the entire
- string. Therefore, if it's desired to match a sequence anywhere within
- a string, the pattern must start and end with a percent sign.
- </para>
-
- <para>
- To match a literal underscore or percent sign without matching
- other characters, the respective character in
- <replaceable>pattern</replaceable> must be
- preceded by the escape character. The default escape
- character is the backslash but a different one can be selected by
- using the <literal>ESCAPE</literal> clause. To match the escape
- character itself, write two escape characters.
- </para>
-
- <note>
- <para>
- If you have <xref linkend="guc-standard-conforming-strings"/> turned off,
- any backslashes you write in literal string constants will need to be
- doubled. See <xref linkend="sql-syntax-strings"/> for more information.
- </para>
- </note>
-
- <para>
- It's also possible to select no escape character by writing
- <literal>ESCAPE ''</literal>. This effectively disables the
- escape mechanism, which makes it impossible to turn off the
- special meaning of underscore and percent signs in the pattern.
- </para>
-
- <para>
- According to the SQL standard, omitting <literal>ESCAPE</literal>
- means there is no escape character (rather than defaulting to a
- backslash), and a zero-length <literal>ESCAPE</literal> value is
- disallowed. <productname>PostgreSQL</productname>'s behavior in
- this regard is therefore slightly nonstandard.
- </para>
-
- <para>
- The key word <token>ILIKE</token> can be used instead of
- <token>LIKE</token> to make the match case-insensitive according
- to the active locale. This is not in the <acronym>SQL</acronym> standard but is a
- <productname>PostgreSQL</productname> extension.
- </para>
-
- <para>
- The operator <literal>~~</literal> is equivalent to
- <function>LIKE</function>, and <literal>~~*</literal> corresponds to
- <function>ILIKE</function>. There are also
- <literal>!~~</literal> and <literal>!~~*</literal> operators that
- represent <function>NOT LIKE</function> and <function>NOT
- ILIKE</function>, respectively. All of these operators are
- <productname>PostgreSQL</productname>-specific. You may see these
- operator names in <command>EXPLAIN</command> output and similar
- places, since the parser actually translates <function>LIKE</function>
- et al. to these operators.
- </para>
-
- <para>
- The phrases <function>LIKE</function>, <function>ILIKE</function>,
- <function>NOT LIKE</function>, and <function>NOT ILIKE</function> are
- generally treated as operators
- in <productname>PostgreSQL</productname> syntax; for example they can
- be used in <replaceable>expression</replaceable>
- <replaceable>operator</replaceable> ANY
- (<replaceable>subquery</replaceable>) constructs, although
- an <literal>ESCAPE</literal> clause cannot be included there. In some
- obscure cases it may be necessary to use the underlying operator names
- instead.
- </para>
-
- <para>
- Also see the starts-with operator <literal>^@</literal> and the
- corresponding <function>starts_with()</function> function, which are
- useful in cases where simply matching the beginning of a string is
- needed.
- </para>
- </sect2>
-
-
- <sect2 id="functions-similarto-regexp">
- <title><function>SIMILAR TO</function> Regular Expressions</title>
-
- <indexterm>
- <primary>regular expression</primary>
- <!-- <seealso>pattern matching</seealso> breaks index build -->
- </indexterm>
-
- <indexterm>
- <primary>SIMILAR TO</primary>
- </indexterm>
- <indexterm>
- <primary>substring</primary>
- </indexterm>
-
-<synopsis>
-<replaceable>string</replaceable> SIMILAR TO <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
-<replaceable>string</replaceable> NOT SIMILAR TO <replaceable>pattern</replaceable> <optional>ESCAPE <replaceable>escape-character</replaceable></optional>
-</synopsis>
-
- <para>
- The <function>SIMILAR TO</function> operator returns true or
- false depending on whether its pattern matches the given string.
- It is similar to <function>LIKE</function>, except that it
- interprets the pattern using the SQL standard's definition of a
- regular expression. SQL regular expressions are a curious cross
- between <function>LIKE</function> notation and common (POSIX) regular
- expression notation.
- </para>
-
- <para>
- Like <function>LIKE</function>, the <function>SIMILAR TO</function>
- operator succeeds only if its pattern matches the entire string;
- this is unlike common regular expression behavior where the pattern
- can match any part of the string.
- Also like
- <function>LIKE</function>, <function>SIMILAR TO</function> uses
- <literal>_</literal> and <literal>%</literal> as wildcard characters denoting
- any single character and any string, respectively (these are
- comparable to <literal>.</literal> and <literal>.*</literal> in POSIX regular
- expressions).
- </para>
-
- <para>
- In addition to these facilities borrowed from <function>LIKE</function>,
- <function>SIMILAR TO</function> supports these pattern-matching
- metacharacters borrowed from POSIX regular expressions:
-
- <itemizedlist>
- <listitem>
- <para>
- <literal>|</literal> denotes alternation (either of two alternatives).
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>*</literal> denotes repetition of the previous item zero
- or more times.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>+</literal> denotes repetition of the previous item one
- or more times.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>?</literal> denotes repetition of the previous item zero
- or one time.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>{</literal><replaceable>m</replaceable><literal>}</literal> denotes repetition
- of the previous item exactly <replaceable>m</replaceable> times.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> denotes repetition
- of the previous item <replaceable>m</replaceable> or more times.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal>
- denotes repetition of the previous item at least <replaceable>m</replaceable> and
- not more than <replaceable>n</replaceable> times.
- </para>
- </listitem>
- <listitem>
- <para>
- Parentheses <literal>()</literal> can be used to group items into
- a single logical item.
- </para>
- </listitem>
- <listitem>
- <para>
- A bracket expression <literal>[...]</literal> specifies a character
- class, just as in POSIX regular expressions.
- </para>
- </listitem>
- </itemizedlist>
-
- Notice that the period (<literal>.</literal>) is not a metacharacter
- for <function>SIMILAR TO</function>.
- </para>
-
- <para>
- As with <function>LIKE</function>, a backslash disables the special
- meaning of any of these metacharacters. A different escape character
- can be specified with <literal>ESCAPE</literal>, or the escape
- capability can be disabled by writing <literal>ESCAPE ''</literal>.
- </para>
-
- <para>
- According to the SQL standard, omitting <literal>ESCAPE</literal>
- means there is no escape character (rather than defaulting to a
- backslash), and a zero-length <literal>ESCAPE</literal> value is
- disallowed. <productname>PostgreSQL</productname>'s behavior in
- this regard is therefore slightly nonstandard.
- </para>
-
- <para>
- Another nonstandard extension is that following the escape character
- with a letter or digit provides access to the escape sequences
- defined for POSIX regular expressions; see
- <xref linkend="posix-character-entry-escapes-table"/>,
- <xref linkend="posix-class-shorthand-escapes-table"/>, and
- <xref linkend="posix-constraint-escapes-table"/> below.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-'abc' SIMILAR TO 'abc' <lineannotation>true</lineannotation>
-'abc' SIMILAR TO 'a' <lineannotation>false</lineannotation>
-'abc' SIMILAR TO '%(b|d)%' <lineannotation>true</lineannotation>
-'abc' SIMILAR TO '(b|c)%' <lineannotation>false</lineannotation>
-'-abc-' SIMILAR TO '%\mabc\M%' <lineannotation>true</lineannotation>
-'xabcy' SIMILAR TO '%\mabc\M%' <lineannotation>false</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>substring</function> function with three parameters
- provides extraction of a substring that matches an SQL
- regular expression pattern. The function can be written according
- to standard SQL syntax:
-<synopsis>
-substring(<replaceable>string</replaceable> similar <replaceable>pattern</replaceable> escape <replaceable>escape-character</replaceable>)
-</synopsis>
- or using the now obsolete SQL:1999 syntax:
-<synopsis>
-substring(<replaceable>string</replaceable> from <replaceable>pattern</replaceable> for <replaceable>escape-character</replaceable>)
-</synopsis>
- or as a plain three-argument function:
-<synopsis>
-substring(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>, <replaceable>escape-character</replaceable>)
-</synopsis>
- As with <literal>SIMILAR TO</literal>, the
- specified pattern must match the entire data string, or else the
- function fails and returns null. To indicate the part of the
- pattern for which the matching data sub-string is of interest,
- the pattern should contain
- two occurrences of the escape character followed by a double quote
- (<literal>"</literal>). <!-- " font-lock sanity -->
- The text matching the portion of the pattern
- between these separators is returned when the match is successful.
- </para>
-
- <para>
- The escape-double-quote separators actually
- divide <function>substring</function>'s pattern into three independent
- regular expressions; for example, a vertical bar (<literal>|</literal>)
- in any of the three sections affects only that section. Also, the first
- and third of these regular expressions are defined to match the smallest
- possible amount of text, not the largest, when there is any ambiguity
- about how much of the data string matches which pattern. (In POSIX
- parlance, the first and third regular expressions are forced to be
- non-greedy.)
- </para>
-
- <para>
- As an extension to the SQL standard, <productname>PostgreSQL</productname>
- allows there to be just one escape-double-quote separator, in which case
- the third regular expression is taken as empty; or no separators, in which
- case the first and third regular expressions are taken as empty.
- </para>
-
- <para>
- Some examples, with <literal>#"</literal> delimiting the return string:
-<programlisting>
-substring('foobar' similar '%#"o_b#"%' escape '#') <lineannotation>oob</lineannotation>
-substring('foobar' similar '#"o_b#"%' escape '#') <lineannotation>NULL</lineannotation>
-</programlisting>
- </para>
- </sect2>
-
- <sect2 id="functions-posix-regexp">
- <title><acronym>POSIX</acronym> Regular Expressions</title>
-
- <indexterm zone="functions-posix-regexp">
- <primary>regular expression</primary>
- <seealso>pattern matching</seealso>
- </indexterm>
- <indexterm>
- <primary>substring</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_count</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_instr</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_like</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_match</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_matches</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_replace</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_split_to_table</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_split_to_array</primary>
- </indexterm>
- <indexterm>
- <primary>regexp_substr</primary>
- </indexterm>
-
- <para>
- <xref linkend="functions-posix-table"/> lists the available
- operators for pattern matching using POSIX regular expressions.
- </para>
-
- <table id="functions-posix-table">
- <title>Regular Expression Match Operators</title>
-
- <tgroup cols="1">
- <thead>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- Operator
- </para>
- <para>
- Description
- </para>
- <para>
- Example(s)
- </para></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>text</type> <literal>~</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- String matches regular expression, case sensitively
- </para>
- <para>
- <literal>'thomas' ~ 't.*ma'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>text</type> <literal>~*</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- String matches regular expression, case-insensitively
- </para>
- <para>
- <literal>'thomas' ~* 'T.*ma'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>text</type> <literal>!~</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- String does not match regular expression, case sensitively
- </para>
- <para>
- <literal>'thomas' !~ 't.*max'</literal>
- <returnvalue>t</returnvalue>
- </para></entry>
- </row>
-
- <row>
- <entry role="func_table_entry"><para role="func_signature">
- <type>text</type> <literal>!~*</literal> <type>text</type>
- <returnvalue>boolean</returnvalue>
- </para>
- <para>
- String does not match regular expression, case-insensitively
- </para>
- <para>
- <literal>'thomas' !~* 'T.*ma'</literal>
- <returnvalue>f</returnvalue>
- </para></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- <acronym>POSIX</acronym> regular expressions provide a more
- powerful means for pattern matching than the <function>LIKE</function> and
- <function>SIMILAR TO</function> operators.
- Many Unix tools such as <command>egrep</command>,
- <command>sed</command>, or <command>awk</command> use a pattern
- matching language that is similar to the one described here.
- </para>
-
- <para>
- A regular expression is a character sequence that is an
- abbreviated definition of a set of strings (a <firstterm>regular
- set</firstterm>). A string is said to match a regular expression
- if it is a member of the regular set described by the regular
- expression. As with <function>LIKE</function>, pattern characters
- match string characters exactly unless they are special characters
- in the regular expression language — but regular expressions use
- different special characters than <function>LIKE</function> does.
- Unlike <function>LIKE</function> patterns, a
- regular expression is allowed to match anywhere within a string, unless
- the regular expression is explicitly anchored to the beginning or
- end of the string.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-'abcd' ~ 'bc' <lineannotation>true</lineannotation>
-'abcd' ~ 'a.c' <lineannotation>true — dot matches any character</lineannotation>
-'abcd' ~ 'a.*d' <lineannotation>true — <literal>*</literal> repeats the preceding pattern item</lineannotation>
-'abcd' ~ '(b|x)' <lineannotation>true — <literal>|</literal> means OR, parentheses group</lineannotation>
-'abcd' ~ '^a' <lineannotation>true — <literal>^</literal> anchors to start of string</lineannotation>
-'abcd' ~ '^(b|c)' <lineannotation>false — would match except for anchoring</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <acronym>POSIX</acronym> pattern language is described in much
- greater detail below.
- </para>
-
- <para>
- The <function>substring</function> function with two parameters,
- <function>substring(<replaceable>string</replaceable> from
- <replaceable>pattern</replaceable>)</function>, provides extraction of a
- substring
- that matches a POSIX regular expression pattern. It returns null if
- there is no match, otherwise the first portion of the text that matched the
- pattern. But if the pattern contains any parentheses, the portion
- of the text that matched the first parenthesized subexpression (the
- one whose left parenthesis comes first) is
- returned. You can put parentheses around the whole expression
- if you want to use parentheses within it without triggering this
- exception. If you need parentheses in the pattern before the
- subexpression you want to extract, see the non-capturing parentheses
- described below.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-substring('foobar' from 'o.b') <lineannotation>oob</lineannotation>
-substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>regexp_count</function> function counts the number of
- places where a POSIX regular expression pattern matches a string.
- It has the syntax
- <function>regexp_count</function>(<replaceable>string</replaceable>,
- <replaceable>pattern</replaceable>
- <optional>, <replaceable>start</replaceable>
- <optional>, <replaceable>flags</replaceable>
- </optional></optional>).
- <replaceable>pattern</replaceable> is searched for
- in <replaceable>string</replaceable>, normally from the beginning of
- the string, but if the <replaceable>start</replaceable> parameter is
- provided then beginning from that character index.
- The <replaceable>flags</replaceable> parameter is an optional text
- string containing zero or more single-letter flags that change the
- function's behavior. For example, including <literal>i</literal> in
- <replaceable>flags</replaceable> specifies case-insensitive matching.
- Supported flags are described in
- <xref linkend="posix-embedded-options-table"/>.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-regexp_count('ABCABCAXYaxy', 'A.') <lineannotation>3</lineannotation>
-regexp_count('ABCABCAXYaxy', 'A.', 1, 'i') <lineannotation>4</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>regexp_instr</function> function returns the starting or
- ending position of the <replaceable>N</replaceable>'th match of a
- POSIX regular expression pattern to a string, or zero if there is no
- such match. It has the syntax
- <function>regexp_instr</function>(<replaceable>string</replaceable>,
- <replaceable>pattern</replaceable>
- <optional>, <replaceable>start</replaceable>
- <optional>, <replaceable>N</replaceable>
- <optional>, <replaceable>endoption</replaceable>
- <optional>, <replaceable>flags</replaceable>
- <optional>, <replaceable>subexpr</replaceable>
- </optional></optional></optional></optional></optional>).
- <replaceable>pattern</replaceable> is searched for
- in <replaceable>string</replaceable>, normally from the beginning of
- the string, but if the <replaceable>start</replaceable> parameter is
- provided then beginning from that character index.
- If <replaceable>N</replaceable> is specified
- then the <replaceable>N</replaceable>'th match of the pattern
- is located, otherwise the first match is located.
- If the <replaceable>endoption</replaceable> parameter is omitted or
- specified as zero, the function returns the position of the first
- character of the match. Otherwise, <replaceable>endoption</replaceable>
- must be one, and the function returns the position of the character
- following the match.
- The <replaceable>flags</replaceable> parameter is an optional text
- string containing zero or more single-letter flags that change the
- function's behavior. Supported flags are described
- in <xref linkend="posix-embedded-options-table"/>.
- For a pattern containing parenthesized
- subexpressions, <replaceable>subexpr</replaceable> is an integer
- indicating which subexpression is of interest: the result identifies
- the position of the substring matching that subexpression.
- Subexpressions are numbered in the order of their leading parentheses.
- When <replaceable>subexpr</replaceable> is omitted or zero, the result
- identifies the position of the whole match regardless of
- parenthesized subexpressions.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-regexp_instr('number of your street, town zip, FR', '[^,]+', 1, 2)
- <lineannotation>23</lineannotation>
-regexp_instr('ABCDEFGHI', '(c..)(...)', 1, 1, 0, 'i', 2)
- <lineannotation>6</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>regexp_like</function> function checks whether a match
- of a POSIX regular expression pattern occurs within a string,
- returning boolean true or false. It has the syntax
- <function>regexp_like</function>(<replaceable>string</replaceable>,
- <replaceable>pattern</replaceable>
- <optional>, <replaceable>flags</replaceable> </optional>).
- The <replaceable>flags</replaceable> parameter is an optional text
- string containing zero or more single-letter flags that change the
- function's behavior. Supported flags are described
- in <xref linkend="posix-embedded-options-table"/>.
- This function has the same results as the <literal>~</literal>
- operator if no flags are specified. If only the <literal>i</literal>
- flag is specified, it has the same results as
- the <literal>~*</literal> operator.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-regexp_like('Hello World', 'world') <lineannotation>false</lineannotation>
-regexp_like('Hello World', 'world', 'i') <lineannotation>true</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>regexp_match</function> function returns a text array of
- matching substring(s) within the first match of a POSIX
- regular expression pattern to a string. It has the syntax
- <function>regexp_match</function>(<replaceable>string</replaceable>,
- <replaceable>pattern</replaceable> <optional>, <replaceable>flags</replaceable> </optional>).
- If there is no match, the result is <literal>NULL</literal>.
- If a match is found, and the <replaceable>pattern</replaceable> contains no
- parenthesized subexpressions, then the result is a single-element text
- array containing the substring matching the whole pattern.
- If a match is found, and the <replaceable>pattern</replaceable> contains
- parenthesized subexpressions, then the result is a text array
- whose <replaceable>n</replaceable>'th element is the substring matching
- the <replaceable>n</replaceable>'th parenthesized subexpression of
- the <replaceable>pattern</replaceable> (not counting <quote>non-capturing</quote>
- parentheses; see below for details).
- The <replaceable>flags</replaceable> parameter is an optional text string
- containing zero or more single-letter flags that change the function's
- behavior. Supported flags are described
- in <xref linkend="posix-embedded-options-table"/>.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-SELECT regexp_match('foobarbequebaz', 'bar.*que');
- regexp_match
---------------
- {barbeque}
-(1 row)
-
-SELECT regexp_match('foobarbequebaz', '(bar)(beque)');
- regexp_match
---------------
- {bar,beque}
-(1 row)
-</programlisting>
- </para>
-
- <tip>
- <para>
- In the common case where you just want the whole matching substring
- or <literal>NULL</literal> for no match, the best solution is to
- use <function>regexp_substr()</function>.
- However, <function>regexp_substr()</function> only exists
- in <productname>PostgreSQL</productname> version 15 and up. When
- working in older versions, you can extract the first element
- of <function>regexp_match()</function>'s result, for example:
-<programlisting>
-SELECT (regexp_match('foobarbequebaz', 'bar.*que'))[1];
- regexp_match
---------------
- barbeque
-(1 row)
-</programlisting>
- </para>
- </tip>
-
- <para>
- The <function>regexp_matches</function> function returns a set of text arrays
- of matching substring(s) within matches of a POSIX regular
- expression pattern to a string. It has the same syntax as
- <function>regexp_match</function>.
- This function returns no rows if there is no match, one row if there is
- a match and the <literal>g</literal> flag is not given, or <replaceable>N</replaceable>
- rows if there are <replaceable>N</replaceable> matches and the <literal>g</literal> flag
- is given. Each returned row is a text array containing the whole
- matched substring or the substrings matching parenthesized
- subexpressions of the <replaceable>pattern</replaceable>, just as described above
- for <function>regexp_match</function>.
- <function>regexp_matches</function> accepts all the flags shown
- in <xref linkend="posix-embedded-options-table"/>, plus
- the <literal>g</literal> flag which commands it to return all matches, not
- just the first one.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-SELECT regexp_matches('foo', 'not there');
- regexp_matches
-----------------
-(0 rows)
-
-SELECT regexp_matches('foobarbequebazilbarfbonk', '(b[^b]+)(b[^b]+)', 'g');
- regexp_matches
-----------------
- {bar,beque}
- {bazil,barf}
-(2 rows)
-</programlisting>
- </para>
-
- <tip>
- <para>
- In most cases <function>regexp_matches()</function> should be used with
- the <literal>g</literal> flag, since if you only want the first match, it's
- easier and more efficient to use <function>regexp_match()</function>.
- However, <function>regexp_match()</function> only exists
- in <productname>PostgreSQL</productname> version 10 and up. When working in older
- versions, a common trick is to place a <function>regexp_matches()</function>
- call in a sub-select, for example:
-<programlisting>
-SELECT col1, (SELECT regexp_matches(col2, '(bar)(beque)')) FROM tab;
-</programlisting>
- This produces a text array if there's a match, or <literal>NULL</literal> if
- not, the same as <function>regexp_match()</function> would do. Without the
- sub-select, this query would produce no output at all for table rows
- without a match, which is typically not the desired behavior.
- </para>
- </tip>
-
- <para>
- The <function>regexp_replace</function> function provides substitution of
- new text for substrings that match POSIX regular expression patterns.
- It has the syntax
- <function>regexp_replace</function>(<replaceable>source</replaceable>,
- <replaceable>pattern</replaceable>, <replaceable>replacement</replaceable>
- <optional>, <replaceable>start</replaceable>
- <optional>, <replaceable>N</replaceable>
- </optional></optional>
- <optional>, <replaceable>flags</replaceable> </optional>).
- (Notice that <replaceable>N</replaceable> cannot be specified
- unless <replaceable>start</replaceable> is,
- but <replaceable>flags</replaceable> can be given in any case.)
- The <replaceable>source</replaceable> string is returned unchanged if
- there is no match to the <replaceable>pattern</replaceable>. If there is a
- match, the <replaceable>source</replaceable> string is returned with the
- <replaceable>replacement</replaceable> string substituted for the matching
- substring. The <replaceable>replacement</replaceable> string can contain
- <literal>\</literal><replaceable>n</replaceable>, where <replaceable>n</replaceable> is 1
- through 9, to indicate that the source substring matching the
- <replaceable>n</replaceable>'th parenthesized subexpression of the pattern should be
- inserted, and it can contain <literal>\&</literal> to indicate that the
- substring matching the entire pattern should be inserted. Write
- <literal>\\</literal> if you need to put a literal backslash in the replacement
- text.
- <replaceable>pattern</replaceable> is searched for
- in <replaceable>string</replaceable>, normally from the beginning of
- the string, but if the <replaceable>start</replaceable> parameter is
- provided then beginning from that character index.
- By default, only the first match of the pattern is replaced.
- If <replaceable>N</replaceable> is specified and is greater than zero,
- then the <replaceable>N</replaceable>'th match of the pattern
- is replaced.
- If the <literal>g</literal> flag is given, or
- if <replaceable>N</replaceable> is specified and is zero, then all
- matches at or after the <replaceable>start</replaceable> position are
- replaced. (The <literal>g</literal> flag is ignored
- when <replaceable>N</replaceable> is specified.)
- The <replaceable>flags</replaceable> parameter is an optional text
- string containing zero or more single-letter flags that change the
- function's behavior. Supported flags (though
- not <literal>g</literal>) are
- described in <xref linkend="posix-embedded-options-table"/>.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-regexp_replace('foobarbaz', 'b..', 'X')
- <lineannotation>fooXbaz</lineannotation>
-regexp_replace('foobarbaz', 'b..', 'X', 'g')
- <lineannotation>fooXX</lineannotation>
-regexp_replace('foobarbaz', 'b(..)', 'X\1Y', 'g')
- <lineannotation>fooXarYXazY</lineannotation>
-regexp_replace('A PostgreSQL function', 'a|e|i|o|u', 'X', 1, 0, 'i')
- <lineannotation>X PXstgrXSQL fXnctXXn</lineannotation>
-regexp_replace('A PostgreSQL function', 'a|e|i|o|u', 'X', 1, 3, 'i')
- <lineannotation>A PostgrXSQL function</lineannotation>
-</programlisting>
- </para>
-
- <para>
- The <function>regexp_split_to_table</function> function splits a string using a POSIX
- regular expression pattern as a delimiter. It has the syntax
- <function>regexp_split_to_table</function>(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>
- <optional>, <replaceable>flags</replaceable> </optional>).
- If there is no match to the <replaceable>pattern</replaceable>, the function returns the
- <replaceable>string</replaceable>. If there is at least one match, for each match it returns
- the text from the end of the last match (or the beginning of the string)
- to the beginning of the match. When there are no more matches, it
- returns the text from the end of the last match to the end of the string.
- The <replaceable>flags</replaceable> parameter is an optional text string containing
- zero or more single-letter flags that change the function's behavior.
- <function>regexp_split_to_table</function> supports the flags described in
- <xref linkend="posix-embedded-options-table"/>.
- </para>
-
- <para>
- The <function>regexp_split_to_array</function> function behaves the same as
- <function>regexp_split_to_table</function>, except that <function>regexp_split_to_array</function>
- returns its result as an array of <type>text</type>. It has the syntax
- <function>regexp_split_to_array</function>(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>
- <optional>, <replaceable>flags</replaceable> </optional>).
- The parameters are the same as for <function>regexp_split_to_table</function>.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-SELECT foo FROM regexp_split_to_table('the quick brown fox jumps over the lazy dog', '\s+') AS foo;
- foo
--------
- the
- quick
- brown
- fox
- jumps
- over
- the
- lazy
- dog
-(9 rows)
-
-SELECT regexp_split_to_array('the quick brown fox jumps over the lazy dog', '\s+');
- regexp_split_to_array
------------------------------------------------
- {the,quick,brown,fox,jumps,over,the,lazy,dog}
-(1 row)
-
-SELECT foo FROM regexp_split_to_table('the quick brown fox', '\s*') AS foo;
- foo
------
- t
- h
- e
- q
- u
- i
- c
- k
- b
- r
- o
- w
- n
- f
- o
- x
-(16 rows)
-</programlisting>
- </para>
-
- <para>
- As the last example demonstrates, the regexp split functions ignore
- zero-length matches that occur at the start or end of the string
- or immediately after a previous match. This is contrary to the strict
- definition of regexp matching that is implemented by
- the other regexp functions, but is usually the most convenient behavior
- in practice. Other software systems such as Perl use similar definitions.
- </para>
-
- <para>
- The <function>regexp_substr</function> function returns the substring
- that matches a POSIX regular expression pattern,
- or <literal>NULL</literal> if there is no match. It has the syntax
- <function>regexp_substr</function>(<replaceable>string</replaceable>,
- <replaceable>pattern</replaceable>
- <optional>, <replaceable>start</replaceable>
- <optional>, <replaceable>N</replaceable>
- <optional>, <replaceable>flags</replaceable>
- <optional>, <replaceable>subexpr</replaceable>
- </optional></optional></optional></optional>).
- <replaceable>pattern</replaceable> is searched for
- in <replaceable>string</replaceable>, normally from the beginning of
- the string, but if the <replaceable>start</replaceable> parameter is
- provided then beginning from that character index.
- If <replaceable>N</replaceable> is specified
- then the <replaceable>N</replaceable>'th match of the pattern
- is returned, otherwise the first match is returned.
- The <replaceable>flags</replaceable> parameter is an optional text
- string containing zero or more single-letter flags that change the
- function's behavior. Supported flags are described
- in <xref linkend="posix-embedded-options-table"/>.
- For a pattern containing parenthesized
- subexpressions, <replaceable>subexpr</replaceable> is an integer
- indicating which subexpression is of interest: the result is the
- substring matching that subexpression.
- Subexpressions are numbered in the order of their leading parentheses.
- When <replaceable>subexpr</replaceable> is omitted or zero, the result
- is the whole match regardless of parenthesized subexpressions.
- </para>
-
- <para>
- Some examples:
-<programlisting>
-regexp_substr('number of your street, town zip, FR', '[^,]+', 1, 2)
- <lineannotation> town zip</lineannotation>
-regexp_substr('ABCDEFGHI', '(c..)(...)', 1, 1, 'i', 2)
- <lineannotation>FGH</lineannotation>
-</programlisting>
- </para>
-
-<!-- derived from the re_syntax.n man page -->
-
- <sect3 id="posix-syntax-details">
- <title>Regular Expression Details</title>
-
- <para>
- <productname>PostgreSQL</productname>'s regular expressions are implemented
- using a software package written by Henry Spencer. Much of
- the description of regular expressions below is copied verbatim from his
- manual.
- </para>
-
- <para>
- Regular expressions (<acronym>RE</acronym>s), as defined in
- <acronym>POSIX</acronym> 1003.2, come in two forms:
- <firstterm>extended</firstterm> <acronym>RE</acronym>s or <acronym>ERE</acronym>s
- (roughly those of <command>egrep</command>), and
- <firstterm>basic</firstterm> <acronym>RE</acronym>s or <acronym>BRE</acronym>s
- (roughly those of <command>ed</command>).
- <productname>PostgreSQL</productname> supports both forms, and
- also implements some extensions
- that are not in the POSIX standard, but have become widely used
- due to their availability in programming languages such as Perl and Tcl.
- <acronym>RE</acronym>s using these non-POSIX extensions are called
- <firstterm>advanced</firstterm> <acronym>RE</acronym>s or <acronym>ARE</acronym>s
- in this documentation. AREs are almost an exact superset of EREs,
- but BREs have several notational incompatibilities (as well as being
- much more limited).
- We first describe the ARE and ERE forms, noting features that apply
- only to AREs, and then describe how BREs differ.
- </para>
-
- <note>
- <para>
- <productname>PostgreSQL</productname> always initially presumes that a regular
- expression follows the ARE rules. However, the more limited ERE or
- BRE rules can be chosen by prepending an <firstterm>embedded option</firstterm>
- to the RE pattern, as described in <xref linkend="posix-metasyntax"/>.
- This can be useful for compatibility with applications that expect
- exactly the <acronym>POSIX</acronym> 1003.2 rules.
- </para>
- </note>
-
- <para>
- A regular expression is defined as one or more
- <firstterm>branches</firstterm>, separated by
- <literal>|</literal>. It matches anything that matches one of the
- branches.
- </para>
-
- <para>
- A branch is zero or more <firstterm>quantified atoms</firstterm> or
- <firstterm>constraints</firstterm>, concatenated.
- It matches a match for the first, followed by a match for the second, etc.;
- an empty branch matches the empty string.
- </para>
-
- <para>
- A quantified atom is an <firstterm>atom</firstterm> possibly followed
- by a single <firstterm>quantifier</firstterm>.
- Without a quantifier, it matches a match for the atom.
- With a quantifier, it can match some number of matches of the atom.
- An <firstterm>atom</firstterm> can be any of the possibilities
- shown in <xref linkend="posix-atoms-table"/>.
- The possible quantifiers and their meanings are shown in
- <xref linkend="posix-quantifiers-table"/>.
- </para>
-
- <para>
- A <firstterm>constraint</firstterm> matches an empty string, but matches only when
- specific conditions are met. A constraint can be used where an atom
- could be used, except it cannot be followed by a quantifier.
- The simple constraints are shown in
- <xref linkend="posix-constraints-table"/>;
- some more constraints are described later.
- </para>
-
-
- <table id="posix-atoms-table">
- <title>Regular Expression Atoms</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Atom</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>(</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> (where <replaceable>re</replaceable> is any regular expression)
- matches a match for
- <replaceable>re</replaceable>, with the match noted for possible reporting </entry>
- </row>
-
- <row>
- <entry> <literal>(?:</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> as above, but the match is not noted for reporting
- (a <quote>non-capturing</quote> set of parentheses)
- (AREs only) </entry>
- </row>
-
- <row>
- <entry> <literal>.</literal> </entry>
- <entry> matches any single character </entry>
- </row>
-
- <row>
- <entry> <literal>[</literal><replaceable>chars</replaceable><literal>]</literal> </entry>
- <entry> a <firstterm>bracket expression</firstterm>,
- matching any one of the <replaceable>chars</replaceable> (see
- <xref linkend="posix-bracket-expressions"/> for more detail) </entry>
- </row>
-
- <row>
- <entry> <literal>\</literal><replaceable>k</replaceable> </entry>
- <entry> (where <replaceable>k</replaceable> is a non-alphanumeric character)
- matches that character taken as an ordinary character,
- e.g., <literal>\\</literal> matches a backslash character </entry>
- </row>
-
- <row>
- <entry> <literal>\</literal><replaceable>c</replaceable> </entry>
- <entry> where <replaceable>c</replaceable> is alphanumeric
- (possibly followed by other characters)
- is an <firstterm>escape</firstterm>, see <xref linkend="posix-escape-sequences"/>
- (AREs only; in EREs and BREs, this matches <replaceable>c</replaceable>) </entry>
- </row>
-
- <row>
- <entry> <literal>{</literal> </entry>
- <entry> when followed by a character other than a digit,
- matches the left-brace character <literal>{</literal>;
- when followed by a digit, it is the beginning of a
- <replaceable>bound</replaceable> (see below) </entry>
- </row>
-
- <row>
- <entry> <replaceable>x</replaceable> </entry>
- <entry> where <replaceable>x</replaceable> is a single character with no other
- significance, matches that character </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- An RE cannot end with a backslash (<literal>\</literal>).
- </para>
-
- <note>
- <para>
- If you have <xref linkend="guc-standard-conforming-strings"/> turned off,
- any backslashes you write in literal string constants will need to be
- doubled. See <xref linkend="sql-syntax-strings"/> for more information.
- </para>
- </note>
-
- <table id="posix-quantifiers-table">
- <title>Regular Expression Quantifiers</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Quantifier</entry>
- <entry>Matches</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>*</literal> </entry>
- <entry> a sequence of 0 or more matches of the atom </entry>
- </row>
-
- <row>
- <entry> <literal>+</literal> </entry>
- <entry> a sequence of 1 or more matches of the atom </entry>
- </row>
-
- <row>
- <entry> <literal>?</literal> </entry>
- <entry> a sequence of 0 or 1 matches of the atom </entry>
- </row>
-
- <row>
- <entry> <literal>{</literal><replaceable>m</replaceable><literal>}</literal> </entry>
- <entry> a sequence of exactly <replaceable>m</replaceable> matches of the atom </entry>
- </row>
-
- <row>
- <entry> <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> </entry>
- <entry> a sequence of <replaceable>m</replaceable> or more matches of the atom </entry>
- </row>
-
- <row>
- <entry>
- <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal> </entry>
- <entry> a sequence of <replaceable>m</replaceable> through <replaceable>n</replaceable>
- (inclusive) matches of the atom; <replaceable>m</replaceable> cannot exceed
- <replaceable>n</replaceable> </entry>
- </row>
-
- <row>
- <entry> <literal>*?</literal> </entry>
- <entry> non-greedy version of <literal>*</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>+?</literal> </entry>
- <entry> non-greedy version of <literal>+</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>??</literal> </entry>
- <entry> non-greedy version of <literal>?</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>{</literal><replaceable>m</replaceable><literal>}?</literal> </entry>
- <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>}</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>{</literal><replaceable>m</replaceable><literal>,}?</literal> </entry>
- <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>,}</literal> </entry>
- </row>
-
- <row>
- <entry>
- <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}?</literal> </entry>
- <entry> non-greedy version of <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal> </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The forms using <literal>{</literal><replaceable>...</replaceable><literal>}</literal>
- are known as <firstterm>bounds</firstterm>.
- The numbers <replaceable>m</replaceable> and <replaceable>n</replaceable> within a bound are
- unsigned decimal integers with permissible values from 0 to 255 inclusive.
- </para>
-
- <para>
- <firstterm>Non-greedy</firstterm> quantifiers (available in AREs only) match the
- same possibilities as their corresponding normal (<firstterm>greedy</firstterm>)
- counterparts, but prefer the smallest number rather than the largest
- number of matches.
- See <xref linkend="posix-matching-rules"/> for more detail.
- </para>
-
- <note>
- <para>
- A quantifier cannot immediately follow another quantifier, e.g.,
- <literal>**</literal> is invalid.
- A quantifier cannot
- begin an expression or subexpression or follow
- <literal>^</literal> or <literal>|</literal>.
- </para>
- </note>
-
- <table id="posix-constraints-table">
- <title>Regular Expression Constraints</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Constraint</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>^</literal> </entry>
- <entry> matches at the beginning of the string </entry>
- </row>
-
- <row>
- <entry> <literal>$</literal> </entry>
- <entry> matches at the end of the string </entry>
- </row>
-
- <row>
- <entry> <literal>(?=</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> <firstterm>positive lookahead</firstterm> matches at any point
- where a substring matching <replaceable>re</replaceable> begins
- (AREs only) </entry>
- </row>
-
- <row>
- <entry> <literal>(?!</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> <firstterm>negative lookahead</firstterm> matches at any point
- where no substring matching <replaceable>re</replaceable> begins
- (AREs only) </entry>
- </row>
-
- <row>
- <entry> <literal>(?<=</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> <firstterm>positive lookbehind</firstterm> matches at any point
- where a substring matching <replaceable>re</replaceable> ends
- (AREs only) </entry>
- </row>
-
- <row>
- <entry> <literal>(?<!</literal><replaceable>re</replaceable><literal>)</literal> </entry>
- <entry> <firstterm>negative lookbehind</firstterm> matches at any point
- where no substring matching <replaceable>re</replaceable> ends
- (AREs only) </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Lookahead and lookbehind constraints cannot contain <firstterm>back
- references</firstterm> (see <xref linkend="posix-escape-sequences"/>),
- and all parentheses within them are considered non-capturing.
- </para>
- </sect3>
-
- <sect3 id="posix-bracket-expressions">
- <title>Bracket Expressions</title>
-
- <para>
- A <firstterm>bracket expression</firstterm> is a list of
- characters enclosed in <literal>[]</literal>. It normally matches
- any single character from the list (but see below). If the list
- begins with <literal>^</literal>, it matches any single character
- <emphasis>not</emphasis> from the rest of the list.
- If two characters
- in the list are separated by <literal>-</literal>, this is
- shorthand for the full range of characters between those two
- (inclusive) in the collating sequence,
- e.g., <literal>[0-9]</literal> in <acronym>ASCII</acronym> matches
- any decimal digit. It is illegal for two ranges to share an
- endpoint, e.g., <literal>a-c-e</literal>. Ranges are very
- collating-sequence-dependent, so portable programs should avoid
- relying on them.
- </para>
-
- <para>
- To include a literal <literal>]</literal> in the list, make it the
- first character (after <literal>^</literal>, if that is used). To
- include a literal <literal>-</literal>, make it the first or last
- character, or the second endpoint of a range. To use a literal
- <literal>-</literal> as the first endpoint of a range, enclose it
- in <literal>[.</literal> and <literal>.]</literal> to make it a
- collating element (see below). With the exception of these characters,
- some combinations using <literal>[</literal>
- (see next paragraphs), and escapes (AREs only), all other special
- characters lose their special significance within a bracket expression.
- In particular, <literal>\</literal> is not special when following
- ERE or BRE rules, though it is special (as introducing an escape)
- in AREs.
- </para>
-
- <para>
- Within a bracket expression, a collating element (a character, a
- multiple-character sequence that collates as if it were a single
- character, or a collating-sequence name for either) enclosed in
- <literal>[.</literal> and <literal>.]</literal> stands for the
- sequence of characters of that collating element. The sequence is
- treated as a single element of the bracket expression's list. This
- allows a bracket
- expression containing a multiple-character collating element to
- match more than one character, e.g., if the collating sequence
- includes a <literal>ch</literal> collating element, then the RE
- <literal>[[.ch.]]*c</literal> matches the first five characters of
- <literal>chchcc</literal>.
- </para>
-
- <note>
- <para>
- <productname>PostgreSQL</productname> currently does not support multi-character collating
- elements. This information describes possible future behavior.
- </para>
- </note>
-
- <para>
- Within a bracket expression, a collating element enclosed in
- <literal>[=</literal> and <literal>=]</literal> is an <firstterm>equivalence
- class</firstterm>, standing for the sequences of characters of all collating
- elements equivalent to that one, including itself. (If there are
- no other equivalent collating elements, the treatment is as if the
- enclosing delimiters were <literal>[.</literal> and
- <literal>.]</literal>.) For example, if <literal>o</literal> and
- <literal>^</literal> are the members of an equivalence class, then
- <literal>[[=o=]]</literal>, <literal>[[=^=]]</literal>, and
- <literal>[o^]</literal> are all synonymous. An equivalence class
- cannot be an endpoint of a range.
- </para>
-
- <para>
- Within a bracket expression, the name of a character class
- enclosed in <literal>[:</literal> and <literal>:]</literal> stands
- for the list of all characters belonging to that class. A character
- class cannot be used as an endpoint of a range.
- The <acronym>POSIX</acronym> standard defines these character class
- names:
- <literal>alnum</literal> (letters and numeric digits),
- <literal>alpha</literal> (letters),
- <literal>blank</literal> (space and tab),
- <literal>cntrl</literal> (control characters),
- <literal>digit</literal> (numeric digits),
- <literal>graph</literal> (printable characters except space),
- <literal>lower</literal> (lower-case letters),
- <literal>print</literal> (printable characters including space),
- <literal>punct</literal> (punctuation),
- <literal>space</literal> (any white space),
- <literal>upper</literal> (upper-case letters),
- and <literal>xdigit</literal> (hexadecimal digits).
- The behavior of these standard character classes is generally
- consistent across platforms for characters in the 7-bit ASCII set.
- Whether a given non-ASCII character is considered to belong to one
- of these classes depends on the <firstterm>collation</firstterm>
- that is used for the regular-expression function or operator
- (see <xref linkend="collation"/>), or by default on the
- database's <envar>LC_CTYPE</envar> locale setting (see
- <xref linkend="locale"/>). The classification of non-ASCII
- characters can vary across platforms even in similarly-named
- locales. (But the <literal>C</literal> locale never considers any
- non-ASCII characters to belong to any of these classes.)
- In addition to these standard character
- classes, <productname>PostgreSQL</productname> defines
- the <literal>word</literal> character class, which is the same as
- <literal>alnum</literal> plus the underscore (<literal>_</literal>)
- character, and
- the <literal>ascii</literal> character class, which contains exactly
- the 7-bit ASCII set.
- </para>
-
- <para>
- There are two special cases of bracket expressions: the bracket
- expressions <literal>[[:<:]]</literal> and
- <literal>[[:>:]]</literal> are constraints,
- matching empty strings at the beginning
- and end of a word respectively. A word is defined as a sequence
- of word characters that is neither preceded nor followed by word
- characters. A word character is any character belonging to the
- <literal>word</literal> character class, that is, any letter, digit,
- or underscore. This is an extension, compatible with but not
- specified by <acronym>POSIX</acronym> 1003.2, and should be used with
- caution in software intended to be portable to other systems.
- The constraint escapes described below are usually preferable; they
- are no more standard, but are easier to type.
- </para>
- </sect3>
-
- <sect3 id="posix-escape-sequences">
- <title>Regular Expression Escapes</title>
-
- <para>
- <firstterm>Escapes</firstterm> are special sequences beginning with <literal>\</literal>
- followed by an alphanumeric character. Escapes come in several varieties:
- character entry, class shorthands, constraint escapes, and back references.
- A <literal>\</literal> followed by an alphanumeric character but not constituting
- a valid escape is illegal in AREs.
- In EREs, there are no escapes: outside a bracket expression,
- a <literal>\</literal> followed by an alphanumeric character merely stands for
- that character as an ordinary character, and inside a bracket expression,
- <literal>\</literal> is an ordinary character.
- (The latter is the one actual incompatibility between EREs and AREs.)
- </para>
-
- <para>
- <firstterm>Character-entry escapes</firstterm> exist to make it easier to specify
- non-printing and other inconvenient characters in REs. They are
- shown in <xref linkend="posix-character-entry-escapes-table"/>.
- </para>
-
- <para>
- <firstterm>Class-shorthand escapes</firstterm> provide shorthands for certain
- commonly-used character classes. They are
- shown in <xref linkend="posix-class-shorthand-escapes-table"/>.
- </para>
-
- <para>
- A <firstterm>constraint escape</firstterm> is a constraint,
- matching the empty string if specific conditions are met,
- written as an escape. They are
- shown in <xref linkend="posix-constraint-escapes-table"/>.
- </para>
-
- <para>
- A <firstterm>back reference</firstterm> (<literal>\</literal><replaceable>n</replaceable>) matches the
- same string matched by the previous parenthesized subexpression specified
- by the number <replaceable>n</replaceable>
- (see <xref linkend="posix-constraint-backref-table"/>). For example,
- <literal>([bc])\1</literal> matches <literal>bb</literal> or <literal>cc</literal>
- but not <literal>bc</literal> or <literal>cb</literal>.
- The subexpression must entirely precede the back reference in the RE.
- Subexpressions are numbered in the order of their leading parentheses.
- Non-capturing parentheses do not define subexpressions.
- The back reference considers only the string characters matched by the
- referenced subexpression, not any constraints contained in it. For
- example, <literal>(^\d)\1</literal> will match <literal>22</literal>.
- </para>
-
- <table id="posix-character-entry-escapes-table">
- <title>Regular Expression Character-Entry Escapes</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Escape</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>\a</literal> </entry>
- <entry> alert (bell) character, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\b</literal> </entry>
- <entry> backspace, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\B</literal> </entry>
- <entry> synonym for backslash (<literal>\</literal>) to help reduce the need for backslash
- doubling </entry>
- </row>
-
- <row>
- <entry> <literal>\c</literal><replaceable>X</replaceable> </entry>
- <entry> (where <replaceable>X</replaceable> is any character) the character whose
- low-order 5 bits are the same as those of
- <replaceable>X</replaceable>, and whose other bits are all zero </entry>
- </row>
-
- <row>
- <entry> <literal>\e</literal> </entry>
- <entry> the character whose collating-sequence name
- is <literal>ESC</literal>,
- or failing that, the character with octal value <literal>033</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\f</literal> </entry>
- <entry> form feed, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\n</literal> </entry>
- <entry> newline, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\r</literal> </entry>
- <entry> carriage return, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\t</literal> </entry>
- <entry> horizontal tab, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\u</literal><replaceable>wxyz</replaceable> </entry>
- <entry> (where <replaceable>wxyz</replaceable> is exactly four hexadecimal digits)
- the character whose hexadecimal value is
- <literal>0x</literal><replaceable>wxyz</replaceable>
- </entry>
- </row>
-
- <row>
- <entry> <literal>\U</literal><replaceable>stuvwxyz</replaceable> </entry>
- <entry> (where <replaceable>stuvwxyz</replaceable> is exactly eight hexadecimal
- digits)
- the character whose hexadecimal value is
- <literal>0x</literal><replaceable>stuvwxyz</replaceable>
- </entry>
- </row>
-
- <row>
- <entry> <literal>\v</literal> </entry>
- <entry> vertical tab, as in C </entry>
- </row>
-
- <row>
- <entry> <literal>\x</literal><replaceable>hhh</replaceable> </entry>
- <entry> (where <replaceable>hhh</replaceable> is any sequence of hexadecimal
- digits)
- the character whose hexadecimal value is
- <literal>0x</literal><replaceable>hhh</replaceable>
- (a single character no matter how many hexadecimal digits are used)
- </entry>
- </row>
-
- <row>
- <entry> <literal>\0</literal> </entry>
- <entry> the character whose value is <literal>0</literal> (the null byte)</entry>
- </row>
-
- <row>
- <entry> <literal>\</literal><replaceable>xy</replaceable> </entry>
- <entry> (where <replaceable>xy</replaceable> is exactly two octal digits,
- and is not a <firstterm>back reference</firstterm>)
- the character whose octal value is
- <literal>0</literal><replaceable>xy</replaceable> </entry>
- </row>
-
- <row>
- <entry> <literal>\</literal><replaceable>xyz</replaceable> </entry>
- <entry> (where <replaceable>xyz</replaceable> is exactly three octal digits,
- and is not a <firstterm>back reference</firstterm>)
- the character whose octal value is
- <literal>0</literal><replaceable>xyz</replaceable> </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Hexadecimal digits are <literal>0</literal>-<literal>9</literal>,
- <literal>a</literal>-<literal>f</literal>, and <literal>A</literal>-<literal>F</literal>.
- Octal digits are <literal>0</literal>-<literal>7</literal>.
- </para>
-
- <para>
- Numeric character-entry escapes specifying values outside the ASCII range
- (0–127) have meanings dependent on the database encoding. When the
- encoding is UTF-8, escape values are equivalent to Unicode code points,
- for example <literal>\u1234</literal> means the character <literal>U+1234</literal>.
- For other multibyte encodings, character-entry escapes usually just
- specify the concatenation of the byte values for the character. If the
- escape value does not correspond to any legal character in the database
- encoding, no error will be raised, but it will never match any data.
- </para>
-
- <para>
- The character-entry escapes are always taken as ordinary characters.
- For example, <literal>\135</literal> is <literal>]</literal> in ASCII, but
- <literal>\135</literal> does not terminate a bracket expression.
- </para>
-
- <table id="posix-class-shorthand-escapes-table">
- <title>Regular Expression Class-Shorthand Escapes</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Escape</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>\d</literal> </entry>
- <entry> matches any digit, like
- <literal>[[:digit:]]</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\s</literal> </entry>
- <entry> matches any whitespace character, like
- <literal>[[:space:]]</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\w</literal> </entry>
- <entry> matches any word character, like
- <literal>[[:word:]]</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\D</literal> </entry>
- <entry> matches any non-digit, like
- <literal>[^[:digit:]]</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\S</literal> </entry>
- <entry> matches any non-whitespace character, like
- <literal>[^[:space:]]</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>\W</literal> </entry>
- <entry> matches any non-word character, like
- <literal>[^[:word:]]</literal> </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The class-shorthand escapes also work within bracket expressions,
- although the definitions shown above are not quite syntactically
- valid in that context.
- For example, <literal>[a-c\d]</literal> is equivalent to
- <literal>[a-c[:digit:]]</literal>.
- </para>
-
- <table id="posix-constraint-escapes-table">
- <title>Regular Expression Constraint Escapes</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Escape</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>\A</literal> </entry>
- <entry> matches only at the beginning of the string
- (see <xref linkend="posix-matching-rules"/> for how this differs from
- <literal>^</literal>) </entry>
- </row>
-
- <row>
- <entry> <literal>\m</literal> </entry>
- <entry> matches only at the beginning of a word </entry>
- </row>
-
- <row>
- <entry> <literal>\M</literal> </entry>
- <entry> matches only at the end of a word </entry>
- </row>
-
- <row>
- <entry> <literal>\y</literal> </entry>
- <entry> matches only at the beginning or end of a word </entry>
- </row>
-
- <row>
- <entry> <literal>\Y</literal> </entry>
- <entry> matches only at a point that is not the beginning or end of a
- word </entry>
- </row>
-
- <row>
- <entry> <literal>\Z</literal> </entry>
- <entry> matches only at the end of the string
- (see <xref linkend="posix-matching-rules"/> for how this differs from
- <literal>$</literal>) </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- A word is defined as in the specification of
- <literal>[[:<:]]</literal> and <literal>[[:>:]]</literal> above.
- Constraint escapes are illegal within bracket expressions.
- </para>
-
- <table id="posix-constraint-backref-table">
- <title>Regular Expression Back References</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Escape</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>\</literal><replaceable>m</replaceable> </entry>
- <entry> (where <replaceable>m</replaceable> is a nonzero digit)
- a back reference to the <replaceable>m</replaceable>'th subexpression </entry>
- </row>
-
- <row>
- <entry> <literal>\</literal><replaceable>mnn</replaceable> </entry>
- <entry> (where <replaceable>m</replaceable> is a nonzero digit, and
- <replaceable>nn</replaceable> is some more digits, and the decimal value
- <replaceable>mnn</replaceable> is not greater than the number of closing capturing
- parentheses seen so far)
- a back reference to the <replaceable>mnn</replaceable>'th subexpression </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <note>
- <para>
- There is an inherent ambiguity between octal character-entry
- escapes and back references, which is resolved by the following heuristics,
- as hinted at above.
- A leading zero always indicates an octal escape.
- A single non-zero digit, not followed by another digit,
- is always taken as a back reference.
- A multi-digit sequence not starting with a zero is taken as a back
- reference if it comes after a suitable subexpression
- (i.e., the number is in the legal range for a back reference),
- and otherwise is taken as octal.
- </para>
- </note>
- </sect3>
-
- <sect3 id="posix-metasyntax">
- <title>Regular Expression Metasyntax</title>
-
- <para>
- In addition to the main syntax described above, there are some special
- forms and miscellaneous syntactic facilities available.
- </para>
-
- <para>
- An RE can begin with one of two special <firstterm>director</firstterm> prefixes.
- If an RE begins with <literal>***:</literal>,
- the rest of the RE is taken as an ARE. (This normally has no effect in
- <productname>PostgreSQL</productname>, since REs are assumed to be AREs;
- but it does have an effect if ERE or BRE mode had been specified by
- the <replaceable>flags</replaceable> parameter to a regex function.)
- If an RE begins with <literal>***=</literal>,
- the rest of the RE is taken to be a literal string,
- with all characters considered ordinary characters.
- </para>
-
- <para>
- An ARE can begin with <firstterm>embedded options</firstterm>:
- a sequence <literal>(?</literal><replaceable>xyz</replaceable><literal>)</literal>
- (where <replaceable>xyz</replaceable> is one or more alphabetic characters)
- specifies options affecting the rest of the RE.
- These options override any previously determined options —
- in particular, they can override the case-sensitivity behavior implied by
- a regex operator, or the <replaceable>flags</replaceable> parameter to a regex
- function.
- The available option letters are
- shown in <xref linkend="posix-embedded-options-table"/>.
- Note that these same option letters are used in the <replaceable>flags</replaceable>
- parameters of regex functions.
- </para>
-
- <table id="posix-embedded-options-table">
- <title>ARE Embedded-Option Letters</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>Option</entry>
- <entry>Description</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry> <literal>b</literal> </entry>
- <entry> rest of RE is a BRE </entry>
- </row>
-
- <row>
- <entry> <literal>c</literal> </entry>
- <entry> case-sensitive matching (overrides operator type) </entry>
- </row>
-
- <row>
- <entry> <literal>e</literal> </entry>
- <entry> rest of RE is an ERE </entry>
- </row>
-
- <row>
- <entry> <literal>i</literal> </entry>
- <entry> case-insensitive matching (see
- <xref linkend="posix-matching-rules"/>) (overrides operator type) </entry>
- </row>
-
- <row>
- <entry> <literal>m</literal> </entry>
- <entry> historical synonym for <literal>n</literal> </entry>
- </row>
-
- <row>
- <entry> <literal>n</literal> </entry>
- <entry> newline-sensitive matching (see
- <xref linkend="posix-matching-rules"/>) </entry>
- </row>
-
- <row>
- <entry> <literal>p</literal> </entry>
- <entry> partial newline-sensitive matching (see
- <xref linkend="posix-matching-rules"/>) </entry>
- </row>
-
- <row>
- <entry> <literal>q</literal> </entry>
- <entry> rest of RE is a literal (<quote>quoted</quote>) string, all ordinary
- characters </entry>
- </row>
-
- <row>
- <entry> <literal>s</literal> </entry>
- <entry> non-newline-sensitive matching (default) </entry>
- </row>
-
- <row>
- <entry> <literal>t</literal> </entry>
- <entry> tight syntax (default; see below) </entry>
- </row>
-
- <row>
- <entry> <literal>w</literal> </entry>
- <entry> inverse partial newline-sensitive (<quote>weird</quote>) matching
- (see <xref linkend="posix-matching-rules"/>) </entry>
- </row>
-
- <row>
- <entry> <literal>x</literal> </entry>
- <entry> expanded syntax (see below) </entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Embedded options take effect at the <literal>)</literal> terminating the sequence.
- They can appear only at the start of an ARE (after the
- <literal>***:</literal> director if any).
- </para>
-
- <para>
- In addition to the usual (<firstterm>tight</firstterm>) RE syntax, in which all
- characters are significant, there is an <firstterm>expanded</firstterm> syntax,
- available by specifying the embedded <literal>x</literal> option.
- In the expanded syntax,
- white-space characters in the RE are ignored, as are
- all characters between a <literal>#</literal>
- and the following newline (or the end of the RE). This
- permits paragraphing and commenting a complex RE.
- There are three exceptions to that basic rule:
-
- <itemizedlist>
- <listitem>
- <para>
- a white-space character or <literal>#</literal> preceded by <literal>\</literal> is
- retained
- </para>
- </listitem>
- <listitem>
- <para>
- white space or <literal>#</literal> within a bracket expression is retained
- </para>
- </listitem>
- <listitem>
- <para>
- white space and comments cannot appear within multi-character symbols,
- such as <literal>(?:</literal>
- </para>
- </listitem>
- </itemizedlist>
-
- For this purpose, white-space characters are blank, tab, newline, and
- any character that belongs to the <replaceable>space</replaceable> character class.
- </para>
-
- <para>
- Finally, in an ARE, outside bracket expressions, the sequence
- <literal>(?#</literal><replaceable>ttt</replaceable><literal>)</literal>
- (where <replaceable>ttt</replaceable> is any text not containing a <literal>)</literal>)
- is a comment, completely ignored.
- Again, this is not allowed between the characters of
- multi-character symbols, like <literal>(?:</literal>.
- Such comments are more a historical artifact than a useful facility,
- and their use is deprecated; use the expanded syntax instead.
- </para>
-
- <para>
- <emphasis>None</emphasis> of these metasyntax extensions is available if
- an initial <literal>***=</literal> director
- has specified that the user's input be treated as a literal string
- rather than as an RE.
- </para>
- </sect3>
-
- <sect3 id="posix-matching-rules">
- <title>Regular Expression Matching Rules</title>
-
- <para>
- In the event that an RE could match more than one substring of a given
- string, the RE matches the one starting earliest in the string.
- If the RE could match more than one substring starting at that point,
- either the longest possible match or the shortest possible match will
- be taken, depending on whether the RE is <firstterm>greedy</firstterm> or
- <firstterm>non-greedy</firstterm>.
- </para>
-
- <para>
- Whether an RE is greedy or not is determined by the following rules:
- <itemizedlist>
- <listitem>
- <para>
- Most atoms, and all constraints, have no greediness attribute (because
- they cannot match variable amounts of text anyway).
- </para>
- </listitem>
- <listitem>
- <para>
- Adding parentheses around an RE does not change its greediness.
- </para>
- </listitem>
- <listitem>
- <para>
- A quantified atom with a fixed-repetition quantifier
- (<literal>{</literal><replaceable>m</replaceable><literal>}</literal>
- or
- <literal>{</literal><replaceable>m</replaceable><literal>}?</literal>)
- has the same greediness (possibly none) as the atom itself.
- </para>
- </listitem>
- <listitem>
- <para>
- A quantified atom with other normal quantifiers (including
- <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}</literal>
- with <replaceable>m</replaceable> equal to <replaceable>n</replaceable>)
- is greedy (prefers longest match).
- </para>
- </listitem>
- <listitem>
- <para>
- A quantified atom with a non-greedy quantifier (including
- <literal>{</literal><replaceable>m</replaceable><literal>,</literal><replaceable>n</replaceable><literal>}?</literal>
- with <replaceable>m</replaceable> equal to <replaceable>n</replaceable>)
- is non-greedy (prefers shortest match).
- </para>
- </listitem>
- <listitem>
- <para>
- A branch — that is, an RE that has no top-level
- <literal>|</literal> operator — has the same greediness as the first
- quantified atom in it that has a greediness attribute.
- </para>
- </listitem>
- <listitem>
- <para>
- An RE consisting of two or more branches connected by the
- <literal>|</literal> operator is always greedy.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- The above rules associate greediness attributes not only with individual
- quantified atoms, but with branches and entire REs that contain quantified
- atoms. What that means is that the matching is done in such a way that
- the branch, or whole RE, matches the longest or shortest possible
- substring <emphasis>as a whole</emphasis>. Once the length of the entire match
- is determined, the part of it that matches any particular subexpression
- is determined on the basis of the greediness attribute of that
- subexpression, with subexpressions starting earlier in the RE taking
- priority over ones starting later.
- </para>
-
- <para>
- An example of what this means:
-<screen>
-SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
-<lineannotation>Result: </lineannotation><computeroutput>123</computeroutput>
-SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
-<lineannotation>Result: </lineannotation><computeroutput>1</computeroutput>
-</screen>
- In the first case, the RE as a whole is greedy because <literal>Y*</literal>
- is greedy. It can match beginning at the <literal>Y</literal>, and it matches
- the longest possible string starting there, i.e., <literal>Y123</literal>.
- The output is the parenthesized part of that, or <literal>123</literal>.
- In the second case, the RE as a whole is non-greedy because <literal>Y*?</literal>
- is non-greedy. It can match beginning at the <literal>Y</literal>, and it matches
- the shortest possible string starting there, i.e., <literal>Y1</literal>.
- The subexpression <literal>[0-9]{1,3}</literal> is greedy but it cannot change
- the decision as to the overall match length; so it is forced to match
- just <literal>1</literal>.
- </para>
-
- <para>
- In short, when an RE contains both greedy and non-greedy subexpressions,
- the total match length is either as long as possible or as short as
- possible, according to the attribute assigned to the whole RE. The
- attributes assigned to the subexpressions only affect how much of that
- match they are allowed to <quote>eat</quote> relative to each other.
- </para>
-
- <para>
- The quantifiers <literal>{1,1}</literal> and <literal>{1,1}?</literal>
- can be used to force greediness or non-greediness, respectively,
- on a subexpression or a whole RE.
- This is useful when you need the whole RE to have a greediness attribute
- different from what's deduced from its elements. As an example,
- suppose that we are trying to separate a string containing some digits
- into the digits and the parts before and after them. We might try to
- do that like this:
-<screen>
-SELECT regexp_match('abc01234xyz', '(.*)(\d+)(.*)');
-<lineannotation>Result: </lineannotation><computeroutput>{abc0123,4,xyz}</computeroutput>
-</screen>
- That didn't work: the first <literal>.*</literal> is greedy so
- it <quote>eats</quote> as much as it can, leaving the <literal>\d+</literal> to
- match at the last possible place, the last digit. We might try to fix
- that by making it non-greedy:
-<screen>
-SELECT regexp_match('abc01234xyz', '(.*?)(\d+)(.*)');
-<lineannotation>Result: </lineannotation><computeroutput>{abc,0,""}</computeroutput>
-</screen>
- That didn't work either, because now the RE as a whole is non-greedy
- and so it ends the overall match as soon as possible. We can get what
- we want by forcing the RE as a whole to be greedy:
-<screen>
-SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
-<lineannotation>Result: </lineannotation><computeroutput>{abc,01234,xyz}</computeroutput>
-</screen>
- Controlling the RE's overall greediness separately from its components'
- greediness allows great flexibility in handling variable-length patterns.
- </para>
-
- <para>
- When deciding what is a longer or shorter match,
- match lengths are measured in characters, not collating elements.
- An empty string is considered longer than no match at all.
- For example:
- <literal>bb*</literal>
- matches the three middle characters of <literal>abbbc</literal>;
- <literal>(week|wee)(night|knights)</literal>
- matches all ten characters of <literal>weeknights</literal>;
- when <literal>(.*).*</literal>
- is matched against <literal>abc</literal> the parenthesized subexpression
- matches all three characters; and when
- <literal>(a*)*</literal> is matched against <literal>bc</literal>
- both the whole RE and the parenthesized
- subexpression match an empty string.
- </para>
-
- <para>
- If case-independent matching is specified,
- the effect is much as if all case distinctions had vanished from the
- alphabet.
- When an alphabetic that exists in multiple cases appears as an
- ordinary character outside a bracket expression, it is effectively
- transformed into a bracket expression containing both cases,
- e.g., <literal>x</literal> becomes <literal>[xX]</literal>.
- When it appears inside a bracket expression, all case counterparts
- of it are added to the bracket expression, e.g.,
- <literal>[x]</literal> becomes <literal>[xX]</literal>
- and <literal>[^x]</literal> becomes <literal>[^xX]</literal>.
- </para>
-
- <para>
- If newline-sensitive matching is specified, <literal>.</literal>
- and bracket expressions using <literal>^</literal>
- will never match the newline character
- (so that matches will not cross lines unless the RE
- explicitly includes a newline)
- and <literal>^</literal> and <literal>$</literal>
- will match the empty string after and before a newline
- respectively, in addition to matching at beginning and end of string
- respectively.
- But the ARE escapes <literal>\A</literal> and <literal>\Z</literal>
- continue to match beginning or end of string <emphasis>only</emphasis>.
- Also, the character class shorthands <literal>\D</literal>
- and <literal>\W</literal> will match a newline regardless of this mode.
- (Before <productname>PostgreSQL</productname> 14, they did not match
- newlines when in newline-sensitive mode.
- Write <literal>[^[:digit:]]</literal>
- or <literal>[^[:word:]]</literal> to get the old behavior.)
- </para>
-
- <para>
- If partial newline-sensitive matching is specified,
- this affects <literal>.</literal> and bracket expressions
- as with newline-sensitive matching, but not <literal>^</literal>
- and <literal>$</literal>.
- </para>
-
- <para>
- If inverse partial newline-sensitive matching is specified,
- this affects <literal>^</literal> and <literal>$</literal>
- as with newline-sensitive matching, but not <literal>.</literal>
- and bracket expressions.
- This isn't very useful but is provided for symmetry.
- </para>
- </sect3>
-
- <sect3 id="posix-limits-compatibility">
- <title>Limits and Compatibility</title>
-
- <para>
- No particular limit is imposed on the length of REs in this
- implementation. However,
- programs intended to be highly portable should not employ REs longer
- than 256 bytes,
- as a POSIX-compliant implementation can refuse to accept such REs.
- </para>
-
- <para>
- The only feature of AREs that is actually incompatible with
- POSIX EREs is that <literal>\</literal> does not lose its special
- significance inside bracket expressions.
- All other ARE features use syntax which is illegal or has
- undefined or unspecified effects in POSIX EREs;
- the <literal>***</literal> syntax of directors likewise is outside the POSIX
- syntax for both BREs and EREs.
- </para>
-
- <para>
- Many of the ARE extensions are borrowed from Perl, but some have
- been changed to clean them up, and a few Perl extensions are not present.
- Incompatibilities of note include <literal>\b</literal>, <literal>\B</literal>,
- the lack of special treatment for a trailing newline,
- the addition of complemented bracket expressions to the things
- affected by newline-sensitive matching,
- the restrictions on parentheses and back references in lookahead/lookbehind
- constraints, and the longest/shortest-match (rather than first-match)
- matching semantics.
- </para>
- </sect3>
-
- <sect3 id="posix-basic-regexes">
- <title>Basic Regular Expressions</title>
-
- <para>
- BREs differ from EREs in several respects.
- In BREs, <literal>|</literal>, <literal>+</literal>, and <literal>?</literal>
- are ordinary characters and there is no equivalent
- for their functionality.
- The delimiters for bounds are
- <literal>\{</literal> and <literal>\}</literal>,
- with <literal>{</literal> and <literal>}</literal>
- by themselves ordinary characters.
- The parentheses for nested subexpressions are
- <literal>\(</literal> and <literal>\)</literal>,
- with <literal>(</literal> and <literal>)</literal> by themselves ordinary characters.
- <literal>^</literal> is an ordinary character except at the beginning of the
- RE or the beginning of a parenthesized subexpression,
- <literal>$</literal> is an ordinary character except at the end of the
- RE or the end of a parenthesized subexpression,
- and <literal>*</literal> is an ordinary character if it appears at the beginning
- of the RE or the beginning of a parenthesized subexpression
- (after a possible leading <literal>^</literal>).
- Finally, single-digit back references are available, and
- <literal>\<</literal> and <literal>\></literal>
- are synonyms for
- <literal>[[:<:]]</literal> and <literal>[[:>:]]</literal>
- respectively; no other escapes are available in BREs.
- </para>
- </sect3>
-
-<!-- end re_syntax.n man page -->
-
- <sect3 id="posix-vs-xquery">
- <title>Differences from SQL Standard and XQuery</title>
-
- <indexterm zone="posix-vs-xquery">
- <primary>LIKE_REGEX</primary>
- </indexterm>
-
- <indexterm zone="posix-vs-xquery">
- <primary>OCCURRENCES_REGEX</primary>
- </indexterm>
-
- <indexterm zone="posix-vs-xquery">
- <primary>POSITION_REGEX</primary>
- </indexterm>
-
- <indexterm zone="posix-vs-xquery">
- <primary>SUBSTRING_REGEX</primary>
- </indexterm>
-
- <indexterm zone="posix-vs-xquery">
- <primary>TRANSLATE_REGEX</primary>
- </indexterm>
-
- <indexterm zone="posix-vs-xquery">
- <primary>XQuery regular expressions</primary>
- </indexterm>
-
- <para>
- Since SQL:2008, the SQL standard includes regular expression operators
- and functions that performs pattern
- matching according to the XQuery regular expression
- standard:
- <itemizedlist>
- <listitem><para><literal>LIKE_REGEX</literal></para></listitem>
- <listitem><para><literal>OCCURRENCES_REGEX</literal></para></listitem>
- <listitem><para><literal>POSITION_REGEX</literal></para></listitem>
- <listitem><para><literal>SUBSTRING_REGEX</literal></para></listitem>
- <listitem><para><literal>TRANSLATE_REGEX</literal></para></listitem>
- </itemizedlist>
- <productname>PostgreSQL</productname> does not currently implement these
- operators and functions. You can get approximately equivalent
- functionality in each case as shown in <xref
- linkend="functions-regexp-sql-table"/>. (Various optional clauses on
- both sides have been omitted in this table.)
- </para>
-
- <table id="functions-regexp-sql-table">
- <title>Regular Expression Functions Equivalencies</title>
-
- <tgroup cols="2">
- <thead>
- <row>
- <entry>SQL standard</entry>
- <entry><productname>PostgreSQL</productname></entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><literal><replaceable>string</replaceable> LIKE_REGEX <replaceable>pattern</replaceable></literal></entry>
- <entry><literal>regexp_like(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal> or <literal><replaceable>string</replaceable> ~ <replaceable>pattern</replaceable></literal></entry>
- </row>
-
- <row>
- <entry><literal>OCCURRENCES_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
- <entry><literal>regexp_count(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
- </row>
-
- <row>
- <entry><literal>POSITION_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
- <entry><literal>regexp_instr(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
- </row>
-
- <row>
- <entry><literal>SUBSTRING_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable>)</literal></entry>
- <entry><literal>regexp_substr(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>)</literal></entry>
- </row>
-
- <row>
- <entry><literal>TRANSLATE_REGEX(<replaceable>pattern</replaceable> IN <replaceable>string</replaceable> WITH <replaceable>replacement</replaceable>)</literal></entry>
- <entry><literal>regexp_replace(<replaceable>string</replaceable>, <replaceable>pattern</replaceable>, <replaceable>replacement</replaceable>)</literal></entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Regular expression functions similar to those provided by PostgreSQL are
- also available in a number of other SQL implementations, whereas the
- SQL-standard functions are not as widely implemented. Some of the
- details of the regular expression syntax will likely differ in each
- implementation.
- </para>
-
- <para>
- The SQL-standard operators and functions use XQuery regular expressions,
- which are quite close to the ARE syntax described above.
- Notable differences between the existing POSIX-based
- regular-expression feature and XQuery regular expressions include:
-
- <itemizedlist>
- <listitem>
- <para>
- XQuery character class subtraction is not supported. An example of
- this feature is using the following to match only English
- consonants: <literal>[a-z-[aeiou]]</literal>.
- </para>
- </listitem>
- <listitem>
- <para>
- XQuery character class shorthands <literal>\c</literal>,
- <literal>\C</literal>, <literal>\i</literal>,
- and <literal>\I</literal> are not supported.
- </para>
- </listitem>
- <listitem>
- <para>
- XQuery character class elements
- using <literal>\p{UnicodeProperty}</literal> or the
- inverse <literal>\P{UnicodeProperty}</literal> are not supported.
- </para>
- </listitem>
- <listitem>
- <para>
- POSIX interprets character classes such as <literal>\w</literal>
- (see <xref linkend="posix-class-shorthand-escapes-table"/>)
- according to the prevailing locale (which you can control by
- attaching a <literal>COLLATE</literal> clause to the operator or
- function). XQuery specifies these classes by reference to Unicode
- character properties, so equivalent behavior is obtained only with
- a locale that follows the Unicode rules.
- </para>
- </listitem>
- <listitem>
- <para>
- The SQL standard (not XQuery itself) attempts to cater for more
- variants of <quote>newline</quote> than POSIX does. The
- newline-sensitive matching options described above consider only
- ASCII NL (<literal>\n</literal>) to be a newline, but SQL would have
- us treat CR (<literal>\r</literal>), CRLF (<literal>\r\n</literal>)
- (a Windows-style newline), and some Unicode-only characters like
- LINE SEPARATOR (U+2028) as newlines as well.
- Notably, <literal>.</literal> and <literal>\s</literal> should
- count <literal>\r\n</literal> as one character not two according to
- SQL.
- </para>
- </listitem>
- <listitem>
- <para>
- Of the character-entry escapes described in
- <xref linkend="posix-character-entry-escapes-table"/>,
- XQuery supports only <literal>\n</literal>, <literal>\r</literal>,
- and <literal>\t</literal>.
- </para>
- </listitem>
- <listitem>
- <para>
- XQuery does not support
- the <literal>[:<replaceable>name</replaceable>:]</literal> syntax
- for character classes within bracket expressions.
- </para>
- </listitem>
- <listitem>
- <para>
- XQuery does not have lookahead or lookbehind constraints,
- nor any of the constraint escapes described in
- <xref linkend="posix-constraint-escapes-table"/>.
- </para>
- </listitem>
- <listitem>
- <para>
- The metasyntax forms described in <xref linkend="posix-metasyntax"/>
- do not exist in XQuery.
- </para>
- </listitem>
- <listitem>
- <para>
- The regular expression flag letters defined by XQuery are
- related to but not the same as the option letters for POSIX
- (<xref linkend="posix-embedded-options-table"/>). While the
- <literal>i</literal> and <literal>q</literal> options behave the
- same, others do not:
- <itemizedlist>
- <listitem>
- <para>
- XQuery's <literal>s</literal> (allow dot to match newline)
- and <literal>m</literal> (allow <literal>^</literal>
- and <literal>$</literal> to match at newlines) flags provide
- access to the same behaviors as
- POSIX's <literal>n</literal>, <literal>p</literal>
- and <literal>w</literal> flags, but they
- do <emphasis>not</emphasis> match the behavior of
- POSIX's <literal>s</literal> and <literal>m</literal> flags.
- Note in particular that dot-matches-newline is the default
- behavior in POSIX but not XQuery.
- </para>
- </listitem>
- <listitem>
- <para>
- XQuery's <literal>x</literal> (ignore whitespace in pattern) flag
- is noticeably different from POSIX's expanded-mode flag.
- POSIX's <literal>x</literal> flag also
- allows <literal>#</literal> to begin a comment in the pattern,
- and POSIX will not ignore a whitespace character after a
- backslash.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- </sect3>
- </sect2>
- </sect1>
-
+&func-matching;
<sect1 id="functions-formatting">
<title>Data Type Formatting Functions</title>
--
2.34.1
Re: documentation structure
I've splitted it to7 patches.
each patch split one <sect1> into separate new files.
Seems like a good start. Looking at the diffs of these, I wonder if we
would be better off with a func/ directory, each function gets its own file
in that dir, and either these files above include the individual files, or
the original func.sgml just becomes the organizer of all the functions.
That would allow us to do future reorganizations with minimal churn, make
validation of this patch a bit more straightforward, and make it easier for
future editors to find the function they need to edit.
Re: documentation structure
On Mon, Apr 29, 2024 at 1:17 PM Corey Huinker <corey.huinker@gmail.com> wrote:
I've splitted it to7 patches.
each patch split one <sect1> into separate new files.Seems like a good start. Looking at the diffs of these, I wonder if we would be better off with a func/ directory, each function gets its own file in that dir, and either these files above include the individual files, or the original func.sgml just becomes the organizer of all the functions. That would allow us to do future reorganizations with minimal churn, make validation of this patch a bit more straightforward, and make it easier for future editors to find the function they need to edit.
looking back.
The patch is big. no convenient way to review/validate it.
so I created a python script to automate it.
we can review the python script.
(just googling around, I know little about python).
* create new files for holding the content.
func-string.sgml
func-matching.sgml
func-datetime.sgml
func-json.sgml
func-aggregate.sgml
func-info.sgml
func-admin.sgml
* locate parts that need to copy paste to a newly created file, based
on line number.
line number pattern is mentioned here:
/messages/by-id/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd=xt6k-jDizBVUKK6O4KQ@mail.gmail.com
* insert placeholder string in func.sgml:
&func-string;
&func-matching;
&func-datetime;
&func-json;
&func-aggregate;
&func-info;
&func-admin;
* copy the parts to new files.
* validate newly created file. (must only have 2 occurrences of "sect1").
* delete the parts from func.sgml files, since they already copy to new files.
sed --in-place "2408,4180d ; 5330,7760d ; 8942,11127d ; 15502,19436d ;
21567,22985d ; 24346,28017d ; 28020,30714d " func.sgml
* manually change doc/src/sgml/filelist.sgml
<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">2 requirements.
1. manual change doc/src/sgml/filelist.sgml as mentioned before;
2. in python script, at line 35, i use
"os.chdir("/home/jian/Desktop/pg_src/src7/postgres/doc/src/sgml")"
you need to change to your "doc/src/sgml" directory accordingly.
Attachments:
Re: documentation structure
looking back.
The patch is big. no convenient way to review/validate it.
Perhaps we can break up the patches as follows:
1. create the filelist.sgml entries, and create new files as you detailed,
empty with func.sgml still managing the sections, but each section now has
it's corresponding &func-something; The files are included, but they're
completely empty.
2 to 999+. one commit per function moved from func.sgml to it's
corresponding func-something.sgml.
It'll be a ton of commits, but each one will be very easy to review.
Alternately, if we put each function in its own file, there would be a
series of commits, one per function like such:
1. create the new func-my-function.sgml, copying the definition of the same
name
2. delete the definition in func.sgml, replaced with the &func-include;
3. new entry in the filelist.
This approach looks (and IS) tedious, but it has several key advantages:
1. Each one is very easy to review.
2. Big reduction in future merge conflicts on func.sgml.
3. location of a given functions docs is now trivial.
4. separation of concerns with regard to content of function def vs
placement of same.
5. Easy to ensure that all functions have an anchor.
6. The effort can stall and be resumed at our own pace.
Perhaps your python script can be adapted to this approach? I'm willing to
review, or collaborate, or both.
Re: documentation structure
On 2024-07-18 Th 4:16 PM, Corey Huinker wrote:
looking back.
The patch is big. no convenient way to review/validate it.Perhaps we can break up the patches as follows:
1. create the filelist.sgml entries, and create new files as you
detailed, empty with func.sgml still managing the sections, but each
section now has it's corresponding &func-something; The files are
included, but they're completely empty.2 to 999+. one commit per function moved from func.sgml to it's
corresponding func-something.sgml.It'll be a ton of commits, but each one will be very easy to review.
Alternately, if we put each function in its own file, there would be a
series of commits, one per function like such:1. create the new func-my-function.sgml, copying the definition of the
same name
2. delete the definition in func.sgml, replaced with the &func-include;
3. new entry in the filelist.This approach looks (and IS) tedious, but it has several key advantages:
1. Each one is very easy to review.
2. Big reduction in future merge conflicts on func.sgml.
3. location of a given functions docs is now trivial.
4. separation of concerns with regard to content of function def vs
placement of same.
5. Easy to ensure that all functions have an anchor.
6. The effort can stall and be resumed at our own pace.Perhaps your python script can be adapted to this approach? I'm
willing to review, or collaborate, or both.
I'm opposed to having a separate file for every function. I think
breaking up func.sgml into one piece per sect1 is about right. If that
proves cumbersome still we can look at breaking it up further, but let's
start with that.
More concretely, sometimes the bits that relate to a particular function
are not contiguous. e.g. you might have an entry in a table for a
function and then at the end Notes relating to that function. That make
doing a file per function not very practical.
Also, being able to view the context for your function documentation is
useful when editing.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Re: documentation structure
Andrew Dunstan <andrew@dunslane.net> writes:
I'm opposed to having a separate file for every function.
I also think that would be a disaster. It would result in a huge
number of files which would make global editing (eg markup changes)
really painful, and it by no means flattens the document structure.
Somewhere there will still need to be decisions that functions
A, B, C go into one documentation section while D, E, F go somewhere
else.
I think
breaking up func.sgml into one piece per sect1 is about right. If that
proves cumbersome still we can look at breaking it up further, but let's
start with that.
+1
regards, tom lane
Re: documentation structure
I'm opposed to having a separate file for every function. I think
breaking up func.sgml into one piece per sect1 is about right. If that
proves cumbersome still we can look at breaking it up further, but
let's start with that.
That will create at least 30 func-xx.sgml files.
t-ishii$ grep '<sect1' func.sgml|wc -l
30
I am afraid that's too many?
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Re: documentation structure
On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii <ishii@postgresql.org> wrote:
I'm opposed to having a separate file for every function. I think
breaking up func.sgml into one piece per sect1 is about right. If that
proves cumbersome still we can look at breaking it up further, but
let's start with that.That will create at least 30 func-xx.sgml files.
t-ishii$ grep '<sect1' func.sgml|wc -l
30I am afraid that's too many?
The premise and the resultant number of files both seem reasonable to me.
I could get that number down to maybe 20 if pressed but I don't see any
benefit to doing so. I look at a page on the website that needs updating
then go open its source file. Nice and tidy.
David J.
Re: documentation structure
On Fri, Jul 19, 2024 at 12:07 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii <ishii@postgresql.org> wrote:
I'm opposed to having a separate file for every function. I think
breaking up func.sgml into one piece per sect1 is about right. If that
proves cumbersome still we can look at breaking it up further, but
let's start with that.That will create at least 30 func-xx.sgml files.
t-ishii$ grep '<sect1' func.sgml|wc -l
30I am afraid that's too many?
The premise and the resultant number of files both seem reasonable to me. I could get that number down to maybe 20 if pressed but I don't see any benefit to doing so. I look at a page on the website that needs updating then go open its source file. Nice and tidy.
hi. my python test.py script in [1]/messages/by-id/CACJufxH+Yi521QrncwnW4sFGOhPmJQpsmoJ+Ynj+VpHu5wAahQ@mail.gmail.com%5C cut func.sgml from 31k lines to
13k lines by putting some contents to these 7 new files.
new file: func-admin.sgml
new file: func-aggregate.sgml
new file: func-datetime.sgml
new file: func-info.sgml
new file: func-json.sgml
new file: func-matching.sgml
new file: func-string.sgml
doc/src/sgml/filelist.sgml changes are addressed in the attached patch.
cutting func.sgml into half is ok for me.
in test.py , at line 35, i use
"os.chdir("/home/jian/Desktop/pg_src/src7/postgres/doc/src/sgml")"
you need to change to your corresponding "doc/src/sgml" directory.
overall, you need apply the attached patch, change test.py line 35.
main gotcha is based on pattern mentioned in [2]/messages/by-id/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd=xt6k-jDizBVUKK6O4KQ@mail.gmail.com and
index layout from https://www.postgresql.org/docs/devel/functions.html
[1]: /messages/by-id/CACJufxH+Yi521QrncwnW4sFGOhPmJQpsmoJ+Ynj+VpHu5wAahQ@mail.gmail.com%5C
[2]: /messages/by-id/CACJufxEcMjjn-m6fpC2wXHsQbE5nyd=xt6k-jDizBVUKK6O4KQ@mail.gmail.com
Attachments:
v1-0001-filelist.sgml-add-new-file-entries.patchtext/x-patch; charset=US-ASCII; name=v1-0001-filelist.sgml-add-new-file-entries.patchDownload
From cf98a802a7823bf3960b6e08aa1d06f6f944b3fe Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Fri, 19 Jul 2024 14:31:58 +0800
Subject: [PATCH v1 1/1] filelist.sgml add new file entries
---
doc/src/sgml/filelist.sgml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index a7ff5f82..96f81cdc 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -18,6 +18,13 @@
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
--
2.34.1
Re: documentation structure
"David G. Johnston" <david.g.johnston@gmail.com> writes:
On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii <ishii@postgresql.org> wrote:
I'm opposed to having a separate file for every function. I think
breaking up func.sgml into one piece per sect1 is about right.
That will create at least 30 func-xx.sgml files.
I am afraid that's too many?
The premise and the resultant number of files both seem reasonable to me.
I agree. The hundreds that would result from file-per-function, or
anything close to that, would be too many. But I can deal with
file-per-sect1. For context, I count currently 167 sgml/*.sgml files
plus 219 ref/*.sgml, so adding 30 more would be an 8% increase.
Do we want to use a "func-" prefix on the file names? I could
imagine dispensing with that as unnecessary; or another idea
could be to make a new subdirectory func/ for these.
regards, tom lane
Re: documentation structure
Do we want to use a "func-" prefix on the file names? I could
imagine dispensing with that as unnecessary;
If we don't use the prefix and we generate new file names from sect1
tag, we could have file name collision: for example, json.sgml because
there's sect1 tag "functions-json".
or another idea
could be to make a new subdirectory func/ for these.
+1. Looks better than adding +30 files right under sgml directory.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Re: documentation structure
On Fri, Jul 19, 2024 at 1:01 PM Tatsuo Ishii <ishii@postgresql.org> wrote:
Do we want to use a "func-" prefix on the file names? I could
imagine dispensing with that as unnecessary;If we don't use the prefix and we generate new file names from sect1
tag, we could have file name collision: for example, json.sgml because
there's sect1 tag "functions-json".or another idea
could be to make a new subdirectory func/ for these.+1. Looks better than adding +30 files right under sgml directory.
+many for placing these under a subdirectory.
IMO the file name should match the ID of the sect1 element with the leading
"functions-" removed, naming the directory "functions". Thus when viewing
the web page the corresponding sgml file is determinable.
David J.
Re: documentation structure
"David G. Johnston" <david.g.johnston@gmail.com> writes:
+many for placing these under a subdirectory.
IMO the file name should match the ID of the sect1 element with the leading
"functions-" removed, naming the directory "functions". Thus when viewing
the web page the corresponding sgml file is determinable.
I'd go for shorter myself (ie "func/"), mainly due to the precedent
of the existing subdirectory which is "ref/" not "reference/".
It's hardly a big deal though.
regards, tom lane
Re: documentation structure
IMO the file name should match the ID of the sect1 element with the leading
"functions-" removed, naming the directory "functions". Thus when viewing
the web page the corresponding sgml file is determinable.I'd go for shorter myself (ie "func/"), mainly due to the precedent
of the existing subdirectory which is "ref/" not "reference/".
It's hardly a big deal though.
I don't have strong preference neither but I agree that "func/" is
more consistent with existing subdirectory names.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Re: documentation structure
On Fri, Jul 19, 2024 at 5:47 PM Tatsuo Ishii <ishii@postgresql.org> wrote:
IMO the file name should match the ID of the sect1 element with the
leading
"functions-" removed, naming the directory "functions". Thus when
viewing
the web page the corresponding sgml file is determinable.
I'd go for shorter myself (ie "func/"), mainly due to the precedent
of the existing subdirectory which is "ref/" not "reference/".
It's hardly a big deal though.I don't have strong preference neither but I agree that "func/" is
more consistent with existing subdirectory names.
Works for me. I was definitely on the fence between the two.
David J.
Re: documentation structure
1. manually change line 4 in split_func_sgml.py and run the script.
2. git apply v6-0001-all-filelist-for-directory-doc-src-sgml-func.patch
now you can "ninja doc/src/sgml/html"
The logic is simple, but I am using verbose variable names, that's why
split_func_sgml.py size is large.
adding a new directory: doc/src/sgml/func
new directory files: doc/src/sgml/func/allfiles.sgml and others.
For filenames, we can use "func-pattern" or just "pattern". right now,
I use the prefix "func".
each newly created file validates by: only 2 "sect1" exists, each file
has only "<sect1 id=" pattern.
the following ar content of doc/src/sgml/func/allfiles.sgml
<!--
doc/src/sgml/func/allfiles.sgml
PostgreSQL documentation
Complete list of usable sgml source files in this directory.
-->
<!-- function references -->
<!ENTITY func SYSTEM "func.sgml">
<!ENTITY func-logical SYSTEM "func-logical.sgml">
<!ENTITY func-comparison SYSTEM "func-comparison.sgml">
<!ENTITY func-math SYSTEM "func-math.sgml">
<!ENTITY func-string SYSTEM "func-string.sgml">
<!ENTITY func-binarystring SYSTEM "func-binarystring.sgml">
<!ENTITY func-bitstring SYSTEM "func-bitstring.sgml">
<!ENTITY func-matching SYSTEM "func-matching.sgml">
<!ENTITY func-formatting SYSTEM "func-formatting.sgml">
<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
<!ENTITY func-enum SYSTEM "func-enum.sgml">
<!ENTITY func-geometry SYSTEM "func-geometry.sgml">
<!ENTITY func-net SYSTEM "func-net.sgml">
<!ENTITY func-textsearch SYSTEM "func-textsearch.sgml">
<!ENTITY func-uuid SYSTEM "func-uuid.sgml">
<!ENTITY func-xml SYSTEM "func-xml.sgml">
<!ENTITY func-json SYSTEM "func-json.sgml">
<!ENTITY func-sequence SYSTEM "func-sequence.sgml">
<!ENTITY func-conditional SYSTEM "func-conditional.sgml">
<!ENTITY func-array SYSTEM "func-array.sgml">
<!ENTITY func-range SYSTEM "func-range.sgml">
<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
<!ENTITY func-window SYSTEM "func-window.sgml">
<!ENTITY func-merge-support SYSTEM "func-merge-support.sgml">
<!ENTITY func-subquery SYSTEM "func-subquery.sgml">
<!ENTITY func-comparisons SYSTEM "func-comparisons.sgml">
<!ENTITY func-srf SYSTEM "func-srf.sgml">
<!ENTITY func-info SYSTEM "func-info.sgml">
<!ENTITY func-admin SYSTEM "func-admin.sgml">
<!ENTITY func-trigger SYSTEM "func-trigger.sgml">
<!ENTITY func-event-triggers SYSTEM "func-event-triggers.sgml">
<!ENTITY func-statistics SYSTEM "func-statistics.sgml">
Attachments:
v6-0001-all-filelist-for-directory-doc-src-sgml-func.patchtext/x-patch; charset=US-ASCII; name=v6-0001-all-filelist-for-directory-doc-src-sgml-func.patchDownload
From d123a7c9ef6ad45e3b697aa20bcfc831f594b45d Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Sun, 21 Jul 2024 20:43:45 +0800
Subject: [PATCH v6 1/1] all filelist for directory doc/src/sgml/func
---
doc/src/sgml/filelist.sgml | 5 ++++-
doc/src/sgml/func/allfiles.sgml | 40 +++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 doc/src/sgml/func/allfiles.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index a7ff5f82..d9f36933 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -17,7 +17,10 @@
<!ENTITY datatype SYSTEM "datatype.sgml">
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
-<!ENTITY func SYSTEM "func.sgml">
+
+<!ENTITY % allfiles_func SYSTEM "func/allfiles.sgml">
+%allfiles_func;
+
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func/allfiles.sgml b/doc/src/sgml/func/allfiles.sgml
new file mode 100644
index 00000000..34eec608
--- /dev/null
+++ b/doc/src/sgml/func/allfiles.sgml
@@ -0,0 +1,40 @@
+<!--
+doc/src/sgml/func/allfiles.sgml
+PostgreSQL documentation
+Complete list of usable sgml source files in this directory.
+-->
+
+<!-- function references -->
+
+<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-logical SYSTEM "func-logical.sgml">
+<!ENTITY func-comparison SYSTEM "func-comparison.sgml">
+<!ENTITY func-math SYSTEM "func-math.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-binarystring SYSTEM "func-binarystring.sgml">
+<!ENTITY func-bitstring SYSTEM "func-bitstring.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-formatting SYSTEM "func-formatting.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-enum SYSTEM "func-enum.sgml">
+<!ENTITY func-geometry SYSTEM "func-geometry.sgml">
+<!ENTITY func-net SYSTEM "func-net.sgml">
+<!ENTITY func-textsearch SYSTEM "func-textsearch.sgml">
+<!ENTITY func-uuid SYSTEM "func-uuid.sgml">
+<!ENTITY func-xml SYSTEM "func-xml.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-sequence SYSTEM "func-sequence.sgml">
+<!ENTITY func-conditional SYSTEM "func-conditional.sgml">
+<!ENTITY func-array SYSTEM "func-array.sgml">
+<!ENTITY func-range SYSTEM "func-range.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-window SYSTEM "func-window.sgml">
+<!ENTITY func-merge-support SYSTEM "func-merge-support.sgml">
+<!ENTITY func-subquery SYSTEM "func-subquery.sgml">
+<!ENTITY func-comparisons SYSTEM "func-comparisons.sgml">
+<!ENTITY func-srf SYSTEM "func-srf.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
+<!ENTITY func-trigger SYSTEM "func-trigger.sgml">
+<!ENTITY func-event-triggers SYSTEM "func-event-triggers.sgml">
+<!ENTITY func-statistics SYSTEM "func-statistics.sgml">
\ No newline at end of file
--
2.34.1
Re: documentation structure
On Mon, Jul 22, 2024 at 10:42 AM jian he <jian.universality@gmail.com> wrote:
hi. this time everything should be ok!
step1. python3 split_func_sgml.py
step2. git apply
v6-0001-all-filelist-for-directory-doc-src-sgml-func.patch (step2,
cannot use "git am").
what v7_split_func_sgml.py did:
1. The new file only has 2 occurrences of "sect1"
2. Each new sgml file has its own unique identifier, e.g. for
func-logical.sgml unique string is "<sect1 id="functions-logical">"
3. sed copy, inplace delete command string will be printed out.
you can check the line number in func.sgml to verify the sed command.
Attachments:
v7-0001-all-filelist-for-directory-doc-src-sgml-func.patchtext/x-patch; charset=US-ASCII; name=v7-0001-all-filelist-for-directory-doc-src-sgml-func.patchDownload
From d123a7c9ef6ad45e3b697aa20bcfc831f594b45d Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Sun, 21 Jul 2024 20:43:45 +0800
Subject: [PATCH v6 1/1] all filelist for directory doc/src/sgml/func
---
doc/src/sgml/filelist.sgml | 5 ++++-
doc/src/sgml/func/allfiles.sgml | 40 +++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 doc/src/sgml/func/allfiles.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index a7ff5f82..d9f36933 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -17,7 +17,10 @@
<!ENTITY datatype SYSTEM "datatype.sgml">
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
-<!ENTITY func SYSTEM "func.sgml">
+
+<!ENTITY % allfiles_func SYSTEM "func/allfiles.sgml">
+%allfiles_func;
+
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func/allfiles.sgml b/doc/src/sgml/func/allfiles.sgml
new file mode 100644
index 00000000..34eec608
--- /dev/null
+++ b/doc/src/sgml/func/allfiles.sgml
@@ -0,0 +1,40 @@
+<!--
+doc/src/sgml/func/allfiles.sgml
+PostgreSQL documentation
+Complete list of usable sgml source files in this directory.
+-->
+
+<!-- function references -->
+
+<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-logical SYSTEM "func-logical.sgml">
+<!ENTITY func-comparison SYSTEM "func-comparison.sgml">
+<!ENTITY func-math SYSTEM "func-math.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-binarystring SYSTEM "func-binarystring.sgml">
+<!ENTITY func-bitstring SYSTEM "func-bitstring.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-formatting SYSTEM "func-formatting.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-enum SYSTEM "func-enum.sgml">
+<!ENTITY func-geometry SYSTEM "func-geometry.sgml">
+<!ENTITY func-net SYSTEM "func-net.sgml">
+<!ENTITY func-textsearch SYSTEM "func-textsearch.sgml">
+<!ENTITY func-uuid SYSTEM "func-uuid.sgml">
+<!ENTITY func-xml SYSTEM "func-xml.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-sequence SYSTEM "func-sequence.sgml">
+<!ENTITY func-conditional SYSTEM "func-conditional.sgml">
+<!ENTITY func-array SYSTEM "func-array.sgml">
+<!ENTITY func-range SYSTEM "func-range.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-window SYSTEM "func-window.sgml">
+<!ENTITY func-merge-support SYSTEM "func-merge-support.sgml">
+<!ENTITY func-subquery SYSTEM "func-subquery.sgml">
+<!ENTITY func-comparisons SYSTEM "func-comparisons.sgml">
+<!ENTITY func-srf SYSTEM "func-srf.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
+<!ENTITY func-trigger SYSTEM "func-trigger.sgml">
+<!ENTITY func-event-triggers SYSTEM "func-event-triggers.sgml">
+<!ENTITY func-statistics SYSTEM "func-statistics.sgml">
\ No newline at end of file
--
2.34.1
Re: documentation structure
On Tue, Aug 20, 2024 at 11:18 AM jian he <jian.universality@gmail.com> wrote:
On Mon, Jul 22, 2024 at 10:42 AM jian he <jian.universality@gmail.com> wrote:
hi. this time everything should be ok!
step1. python3 split_func_sgml.py
step2. git apply
v6-0001-all-filelist-for-directory-doc-src-sgml-func.patch (step2,
cannot use "git am").
sorry. I mean the file attached in the previous mail.
step1. python3 v7_split_func_sgml.py
step2. git apply v7-0001-all-filelist-for-directory-doc-src-sgml-func.patch
(step2, cannot use "git am").
Re: documentation structure
turns out I hardcoded some line number information,
which makes the script v7_split_func_sgml.py cannot apply anymore.
this time, it should be bullet-proof.
same as before:
step1. python3 v8_split_func_sgml.py
step2. git apply v8-0001-all-filelist-for-directory-doc-src-sgml-func.patch
(step2, cannot use "git am").
I don't know perl, but written in perl, I guess the logic will be the
same, based on line number, do the copy, delete on func.sgml.
Attachments:
v8-0001-all-filelist-for-directory-doc-src-sgml-func.patchtext/x-patch; charset=US-ASCII; name=v8-0001-all-filelist-for-directory-doc-src-sgml-func.patchDownload
From d123a7c9ef6ad45e3b697aa20bcfc831f594b45d Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Sun, 21 Jul 2024 20:43:45 +0800
Subject: [PATCH v6 1/1] all filelist for directory doc/src/sgml/func
---
doc/src/sgml/filelist.sgml | 5 ++++-
doc/src/sgml/func/allfiles.sgml | 40 +++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 doc/src/sgml/func/allfiles.sgml
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index a7ff5f82..d9f36933 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -17,7 +17,10 @@
<!ENTITY datatype SYSTEM "datatype.sgml">
<!ENTITY ddl SYSTEM "ddl.sgml">
<!ENTITY dml SYSTEM "dml.sgml">
-<!ENTITY func SYSTEM "func.sgml">
+
+<!ENTITY % allfiles_func SYSTEM "func/allfiles.sgml">
+%allfiles_func;
+
<!ENTITY indices SYSTEM "indices.sgml">
<!ENTITY json SYSTEM "json.sgml">
<!ENTITY mvcc SYSTEM "mvcc.sgml">
diff --git a/doc/src/sgml/func/allfiles.sgml b/doc/src/sgml/func/allfiles.sgml
new file mode 100644
index 00000000..34eec608
--- /dev/null
+++ b/doc/src/sgml/func/allfiles.sgml
@@ -0,0 +1,40 @@
+<!--
+doc/src/sgml/func/allfiles.sgml
+PostgreSQL documentation
+Complete list of usable sgml source files in this directory.
+-->
+
+<!-- function references -->
+
+<!ENTITY func SYSTEM "func.sgml">
+<!ENTITY func-logical SYSTEM "func-logical.sgml">
+<!ENTITY func-comparison SYSTEM "func-comparison.sgml">
+<!ENTITY func-math SYSTEM "func-math.sgml">
+<!ENTITY func-string SYSTEM "func-string.sgml">
+<!ENTITY func-binarystring SYSTEM "func-binarystring.sgml">
+<!ENTITY func-bitstring SYSTEM "func-bitstring.sgml">
+<!ENTITY func-matching SYSTEM "func-matching.sgml">
+<!ENTITY func-formatting SYSTEM "func-formatting.sgml">
+<!ENTITY func-datetime SYSTEM "func-datetime.sgml">
+<!ENTITY func-enum SYSTEM "func-enum.sgml">
+<!ENTITY func-geometry SYSTEM "func-geometry.sgml">
+<!ENTITY func-net SYSTEM "func-net.sgml">
+<!ENTITY func-textsearch SYSTEM "func-textsearch.sgml">
+<!ENTITY func-uuid SYSTEM "func-uuid.sgml">
+<!ENTITY func-xml SYSTEM "func-xml.sgml">
+<!ENTITY func-json SYSTEM "func-json.sgml">
+<!ENTITY func-sequence SYSTEM "func-sequence.sgml">
+<!ENTITY func-conditional SYSTEM "func-conditional.sgml">
+<!ENTITY func-array SYSTEM "func-array.sgml">
+<!ENTITY func-range SYSTEM "func-range.sgml">
+<!ENTITY func-aggregate SYSTEM "func-aggregate.sgml">
+<!ENTITY func-window SYSTEM "func-window.sgml">
+<!ENTITY func-merge-support SYSTEM "func-merge-support.sgml">
+<!ENTITY func-subquery SYSTEM "func-subquery.sgml">
+<!ENTITY func-comparisons SYSTEM "func-comparisons.sgml">
+<!ENTITY func-srf SYSTEM "func-srf.sgml">
+<!ENTITY func-info SYSTEM "func-info.sgml">
+<!ENTITY func-admin SYSTEM "func-admin.sgml">
+<!ENTITY func-trigger SYSTEM "func-trigger.sgml">
+<!ENTITY func-event-triggers SYSTEM "func-event-triggers.sgml">
+<!ENTITY func-statistics SYSTEM "func-statistics.sgml">
\ No newline at end of file
--
2.34.1
Re: documentation structure
In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch
-<function>format</function>(<parameter>formatstr</parameter>
<type>text</type> [, <parameter>formatarg</parameter>
<type>"any"</type> [, ...] ])
+<function>format</function>(<parameter>formatstr</parameter>
<type>text</type> <optional>, <parameter>formatarg</parameter>
<type>"any"</type> [, ...] </optional>)i change it further to
+<function>format</function>(<parameter>formatstr</parameter>
<type>text</type> <optional>, <parameter>formatarg</parameter>
<type>"any"</type> <optional>, ...</optional> </optional>)
i did these kind of change to <function>format</function>,
<function>concat_ws</function>, <function>concat</function>
I've rebased your patch,
added a commitfest entry: https://commitfest.postgresql.org/50/5278/
it seems I cannot mark you as the author in commitfest.
anyway, you ( Dagfinn Ilmari Mannsåker ) are the author of it.
Attachments:
v2-0001-func.sgml-Consistently-use-optional-to-indicate-o.patchapplication/x-patch; name=v2-0001-func.sgml-Consistently-use-optional-to-indicate-o.patchDownload
From bc4d0b217da13fc212cb9eddf5a958887d5c7dc6 Mon Sep 17 00:00:00 2001
From: jian he <jian.universality@gmail.com>
Date: Mon, 30 Sep 2024 15:54:57 +0800
Subject: [PATCH v2 1/1] func.sgml: Consistently use <optional> to indicate
optional parameters
Some functions were using square brackets instead, replace them all with <optional>.
discussion: https://www.postgresql.org/message-id/87sezjj0ny.fsf%40wibble.ilmari.org
---
doc/src/sgml/func.sgml | 48 +++++++++++++++++++++---------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d6acdd3059..5bfd73951d 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -3036,7 +3036,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>concat</primary>
</indexterm>
<function>concat</function> ( <parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>val2</parameter> <type>"any"</type> <optional>, ...</optional> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3056,7 +3056,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
</indexterm>
<function>concat_ws</function> ( <parameter>sep</parameter> <type>text</type>,
<parameter>val1</parameter> <type>"any"</type>
- [, <parameter>val2</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>val2</parameter> <type>"any"</type> <optional>, ...</optional> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3076,7 +3076,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>format</primary>
</indexterm>
<function>format</function> ( <parameter>formatstr</parameter> <type>text</type>
- [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ] )
+ <optional>, <parameter>formatarg</parameter> <type>"any"</type> <optional>, ...</optional> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3170,7 +3170,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>parse_ident</primary>
</indexterm>
<function>parse_ident</function> ( <parameter>qualified_identifier</parameter> <type>text</type>
- [, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> ] )
+ <optional>, <parameter>strict_mode</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>true</literal> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3309,8 +3309,8 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>regexp_count</primary>
</indexterm>
<function>regexp_count</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type> ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> </optional> )
<returnvalue>integer</returnvalue>
</para>
<para>
@@ -3331,11 +3331,11 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>regexp_instr</primary>
</indexterm>
<function>regexp_instr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>endoption</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>N</parameter> <type>integer</type>
+ <optional>, <parameter>endoption</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type>
+ <optional>, <parameter>subexpr</parameter> <type>integer</type> </optional> </optional> </optional> </optional> </optional> )
<returnvalue>integer</returnvalue>
</para>
<para>
@@ -3360,7 +3360,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>regexp_like</primary>
</indexterm>
<function>regexp_like</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>flags</parameter> <type>text</type> ] )
+ <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>boolean</returnvalue>
</para>
<para>
@@ -3380,7 +3380,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<indexterm>
<primary>regexp_match</primary>
</indexterm>
- <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_match</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3400,7 +3400,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<indexterm>
<primary>regexp_matches</primary>
</indexterm>
- <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_matches</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>setof text[]</returnvalue>
</para>
<para>
@@ -3473,7 +3473,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<indexterm>
<primary>regexp_split_to_array</primary>
</indexterm>
- <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_split_to_array</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>text[]</returnvalue>
</para>
<para>
@@ -3492,7 +3492,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<indexterm>
<primary>regexp_split_to_table</primary>
</indexterm>
- <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> [, <parameter>flags</parameter> <type>text</type> ] )
+ <function>regexp_split_to_table</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type> <optional>, <parameter>flags</parameter> <type>text</type> </optional> )
<returnvalue>setof text</returnvalue>
</para>
<para>
@@ -3516,10 +3516,10 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<primary>regexp_substr</primary>
</indexterm>
<function>regexp_substr</function> ( <parameter>string</parameter> <type>text</type>, <parameter>pattern</parameter> <type>text</type>
- [, <parameter>start</parameter> <type>integer</type>
- [, <parameter>N</parameter> <type>integer</type>
- [, <parameter>flags</parameter> <type>text</type>
- [, <parameter>subexpr</parameter> <type>integer</type> ] ] ] ] )
+ <optional>, <parameter>start</parameter> <type>integer</type>
+ <optional>, <parameter>N</parameter> <type>integer</type>
+ <optional>, <parameter>flags</parameter> <type>text</type>
+ <optional>, <parameter>subexpr</parameter> <type>integer</type> </optional> </optional> </optional> </optional> )
<returnvalue>text</returnvalue>
</para>
<para>
@@ -3986,7 +3986,7 @@ SELECT NOT(ROW(table.*) IS NOT NULL) FROM TABLE; -- detect at least one null in
<para>
<synopsis>
-<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ])
+<function>format</function>(<parameter>formatstr</parameter> <type>text</type> <optional>, <parameter>formatarg</parameter> <type>"any"</type> <optional>, ...</optional> </optional>)
</synopsis>
<parameter>formatstr</parameter> is a format string that specifies how the
result should be formatted. Text in the format string is copied
@@ -10621,7 +10621,7 @@ SELECT date_part('hour', INTERVAL '4 hours 3 minutes');
<para>
<synopsis>
-date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> [, <replaceable>time_zone</replaceable> ])
+date_trunc(<replaceable>field</replaceable>, <replaceable>source</replaceable> <optional>, <replaceable>time_zone</replaceable> </optional>)
</synopsis>
<replaceable>source</replaceable> is a value expression of type
<type>timestamp</type>, <type>timestamp with time zone</type>,
@@ -29647,11 +29647,11 @@ DETAIL: Make sure pg_wal_replay_wait() isn't called within a transaction with a
<indexterm>
<primary>pg_logical_emit_message</primary>
</indexterm>
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>text</type> <optional>, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal></optional> )
<returnvalue>pg_lsn</returnvalue>
</para>
<para role="func_signature">
- <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> [, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal>] )
+ <function>pg_logical_emit_message</function> ( <parameter>transactional</parameter> <type>boolean</type>, <parameter>prefix</parameter> <type>text</type>, <parameter>content</parameter> <type>bytea</type> <optional>, <parameter>flush</parameter> <type>boolean</type> <literal>DEFAULT</literal> <literal>false</literal></optional> )
<returnvalue>pg_lsn</returnvalue>
</para>
<para>
--
2.34.1
Re: documentation structure
On 30/09/2024 11:15, jian he wrote:
In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch
-<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ]) +<function>format</function>(<parameter>formatstr</parameter> <type>text</type> <optional>, <parameter>formatarg</parameter> <type>"any"</type> [, ...] </optional>)i change it further to
+<function>format</function>(<parameter>formatstr</parameter>
<type>text</type> <optional>, <parameter>formatarg</parameter>
<type>"any"</type> <optional>, ...</optional> </optional>)i did these kind of change to <function>format</function>,
<function>concat_ws</function>, <function>concat</function>I've rebased your patch,
added a commitfest entry: https://commitfest.postgresql.org/50/5278/
it seems I cannot mark you as the author in commitfest.
anyway, you ( Dagfinn Ilmari Mannsåker ) are the author of it.
Committed, thanks!
One funny case remains:
<entry role="func_table_entry"><para role="func_signature">
<function>unnest</function> ( <type>anyarray</type>,
<type>anyarray</type> <optional>, ... </optional> )
<returnvalue>setof anyelement, anyelement [, ... ]</returnvalue>
</para>
<para>
The returnvalue contains brackets. I tried to change that to use
"<optional>" tag too, but it's not valid:
postgres.sgml:20552: element returnvalue: validity error : Element
optional is not declared in returnvalue list of possible children
--
Heikki Linnakangas
Neon (https://neon.tech)
Re: documentation structure
Heikki Linnakangas <hlinnaka@iki.fi> writes:
On 30/09/2024 11:15, jian he wrote:
In, 0001-func.sgml-Consistently-use-optional-to-indicate-opti.patch -<function>format</function>(<parameter>formatstr</parameter> <type>text</type> [, <parameter>formatarg</parameter> <type>"any"</type> [, ...] ]) +<function>format</function>(<parameter>formatstr</parameter> <type>text</type> <optional>, <parameter>formatarg</parameter> <type>"any"</type> [, ...] </optional>) i change it further to +<function>format</function>(<parameter>formatstr</parameter> <type>text</type> <optional>, <parameter>formatarg</parameter> <type>"any"</type> <optional>, ...</optional> </optional>) i did these kind of change to <function>format</function>, <function>concat_ws</function>, <function>concat</function> I've rebased your patch, added a commitfest entry: https://commitfest.postgresql.org/50/5278/ it seems I cannot mark you as the author in commitfest. anyway, you ( Dagfinn Ilmari Mannsåker ) are the author of it.Committed, thanks!
Thanks!
One funny case remains:
<entry role="func_table_entry"><para role="func_signature">
<function>unnest</function> ( <type>anyarray</type>,
<type>anyarray</type> <optional>, ... </optional> )
<returnvalue>setof anyelement, anyelement [, ... ]</returnvalue>
</para>
<para>The returnvalue contains brackets. I tried to change that to use
"<optional>" tag too, but it's not valid:postgres.sgml:20552: element returnvalue: validity error : Element
optional is not declared in returnvalue list of possible children
Yeah, I remember running into that, and deciding I couldn't be bothered
to try to learn enough about docbook to figure out if a solution was
possible.
- ilmari