aboutsummaryrefslogtreecommitdiff
path: root/src/bin/psql
Commit message (Collapse)AuthorAge
* Improve tab completion of ALTER TYPE in psqlMichael Paquier2022-08-15
| | | | | | | | | | This commit adds support for more tab completion in this command as of "ALTER TYPE .. SET". The completion of "RENAME VALUE" was separated from the rest of the completions done for this command, so group everything together. Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm1u83jtD2wysdw9XwokEacSXEyUpELajEvOMgJTc3pQ7g@mail.gmail.com
* Add xheader_width pset option to psqlAndrew Dunstan2022-07-25
| | | | | | | | | | | | | | | | The setting controls tha maximum length of the header line in expanded format output. Possible settings are full, column, page, or an integer. the default is full, the current behaviour, and in this case the header line is the length of the widest line of output. column causes the header to be truncated to the width of the first column, page causes it to be truncated to the width of the terminal page, and an integer causes it to be truncated to that value. If the full value is less than the page or integer value no truncation occurs. If given without an argument this option prints its current setting. Platon Pronko, somewhat modified by me. Discussion: https://postgr.es/m/f03d38a3-db96-a56e-d1bc-dbbc80bbde4d@gmail.com
* Remove dead handling for pre-POSIX sigwait().Thomas Munro2022-07-24
| | | | | | | | | | | sigwait() is in SUSv2 and all targeted Unix systems have it. An earlier pre-standard function prototype existed on some older systems, but we no longer need a workaround for that. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Greg Stark <stark@mit.edu> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/CA+hUKGJ3LHeP9w5Fgzdr4G8AnEtJ=z=p6hGDEm4qYGEUX5B6fQ@mail.gmail.com
* Fix minor memory leaks in psql's tab completion.Tom Lane2022-07-22
| | | | | | Tang Haiying and Tom Lane Discussion: https://postgr.es/m/OS0PR01MB6113EA19F05E217C823B4CCAFB909@OS0PR01MB6113.jpnprd01.prod.outlook.com
* Allow users to skip logical replication of data having origin.Amit Kapila2022-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new SUBSCRIPTION parameter "origin". It specifies whether the subscription will request the publisher to only send changes that don't have an origin or send changes regardless of origin. Setting it to "none" means that the subscription will request the publisher to only send changes that have no origin associated. Setting it to "any" means that the publisher sends changes regardless of their origin. The default is "any". Usage: CREATE SUBSCRIPTION sub1 CONNECTION 'dbname=postgres port=9999' PUBLICATION pub1 WITH (origin = none); This can be used to avoid loops (infinite replication of the same data) among replication nodes. This feature allows filtering only the replication data originating from WAL but for initial sync (initial copy of table data) we don't have such a facility as we can only distinguish the data based on origin from WAL. As a follow-up patch, we are planning to forbid the initial sync if the origin is specified as none and we notice that the publication tables were also replicated from other publishers to avoid duplicate data or loops. We forbid to allow creating origin with names 'none' and 'any' to avoid confusion with the same name options. Author: Vignesh C, Amit Kapila Reviewed-By: Peter Smith, Amit Kapila, Dilip Kumar, Shi yu, Ashutosh Bapat, Hayato Kuroda Discussion: https://postgr.es/m/CALDaNm0gwjY_4HFxvvty01BOT01q_fJLKQ3pWP9=9orqubhjcQ@mail.gmail.com
* Fix various memory leaks in psql's describe commands \d*Michael Paquier2022-07-21
| | | | | | | | | | | | | | | Most of these have been introduced in d2d3547 with the new pattern validation logic, and would leak memory worth an amount of one PQExpBuffer each time (as of 256 bytes at minimum, possibly more). Most of the patch has been written by Tang Haiying, with a few tweaks coming from Álvaro Herrera. Reported-by: Tang Haiying Author: Tang Haiying, Álvaro Herrera Reviewed-by: Mark Dilger, Andres Freund, Álvaro Herrera, Tom Lane, Japin Li, Michael Paquier, Junwang Zhao Backpatch-through: 15
* psql: Output dir and dependency generation for sql_helpAndres Freund2022-07-18
| | | | | | | | | | | | | | | This is in preparation for building postgres with meson / ninja. When building with meson, commands are run at the root of the build tree. Add an option to put build output into the appropriate place. This can be utilized by src/tools/msvc/ for a minor simplification, which also provides some coverage for the new option. To deal with dependencies to the variable set of input files to this script, add an option to generate a dependency file (which meson / ninja can consume). Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/5e216522-ba3c-f0e6-7f97-5276d0270029@enterprisedb.com
* Revert "Use wildcards instead of manually-maintained file lists in */nls.mk."Tom Lane2022-07-13
| | | | | | | This reverts commit 617d69141220f277170927e03a19d2f1b77aed77. While I still think the basic idea is attractive, we need to sort out what happens with built .c files, and there also seem to be VPATH issues.
* Use wildcards instead of manually-maintained file lists in */nls.mk.Tom Lane2022-07-13
| | | | | | | | | | | | | | | | | | The backend already used a mechanically-generated list of *.c files, but everywhere else we had a manually-written-out list of files in which to seek translatable messages. Commit b0a55e432 contains the latest in a long line of failures to update those lists. Rather than manually fix its oversight, let's change to using "$(wildcard *.c)" in all these nls.mk files. Many of these files also have manual references to some *.c files in other directories, most often src/common/. Perhaps we should try to improve that situation too; but it's a bit less clear how, so for now just fix the local file references. Kyotaro Horiguchi and Tom Lane Discussion: https://postgr.es/m/20220713.160853.453362706160476128.horikyota.ntt@gmail.com
* NLS: Put list of available languages into LINGUAS filesPeter Eisentraut2022-07-13
| | | | | | | | | | | | | | | | | | | | | This moves the list of available languages from nls.mk into a separate file called po/LINGUAS. Advantages: - It keeps the parts notionally managed by programmers (nls.mk) separate from the parts notionally managed by translators (LINGUAS). - It's the standard practice recommended by the Gettext manual nowadays. - The Meson build system also supports this layout (and of course doesn't know anything about our custom nls.mk), so this would enable sharing the list of languages between the two build systems. (The MSVC build system currently finds all po files by globbing, so it is not affected by this change.) Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/557a9f5c-e871-edc7-2f58-a4140fb65b7b@enterprisedb.com
* Fix \watch's interaction with libedit on ^C.Thomas Munro2022-07-10
| | | | | | | | | | | | | | When you hit ^C, the terminal driver in Unix-like systems echoes "^C" as well as sending an interrupt signal (depending on stty settings). At least libedit (but maybe also libreadline) is then confused about the current cursor location, and corrupts the display if you try to scroll back. Fix, by moving to a new line before the next prompt is displayed. Back-patch to all supported released. Author: Pavel Stehule <pavel.stehule@gmail.com> Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3278793.1626198638%40sss.pgh.pa.us
* Re-order disable_on_error in tab-complete.Amit Kapila2022-07-07
| | | | | | | | | | | | | | By convention, the tab-complete subscription parameters are listed in the COMPLETE_WITH lists in alphabetical order, but when the "disable_on_error" parameter was introduced this was not done. This patch just tidies that up. Reported-by: Peter Smith Author: Peter Smith Reviewed-by: Euler Taveira, Takamichi Osumi Backpatch-through: 15, where it was introduced Discussion: https://postgr.es/m/CAHut+PucvKZgg_eJzUW--iL6DXHg1Jwj6F09tQziE3kUF67uLg@mail.gmail.com
* Simplify tab completion of extension versions, redux.Tom Lane2022-07-03
| | | | | | | | | | | | | | | | | | | After commit 662dbe2c8, psql tab completion didn't conveniently support the case of "ALTER EXTENSION foo UPDATE". It'd always add "TO", which is fine if you want to specify a target version but not if you don't ... and surely the latter is the much more common case. To fix, remove "TO" from the initially offered completion; you now need to press TAB one additional time to get that. We won't try to duplicate the old behavior of attempting initial completion on the target version along with TO. It's too squirrelly to get the quoting right, and this is such an infrequent usage that it doesn't seem worth expending a lot of effort and special code on. Noted by Noah Misch. Back-patch to v15. Discussion: https://postgr.es/m/20220703083217.GB2476530@rfd.leadboat.com
* Remove redundant null pointer checks before PQclear and PQconninfoFreePeter Eisentraut2022-07-03
| | | | | | | | These functions already had the free()-like behavior of handling null pointers as a no-op. But it wasn't documented, so add it explicitly to the documentation, too. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
* Remove redundant null pointer checks before free()Peter Eisentraut2022-07-03
| | | | | | | | | | Per applicable standards, free() with a null pointer is a no-op. Systems that don't observe that are ancient and no longer relevant. Some PostgreSQL code already required this behavior, so this change does not introduce any new requirements, just makes the code more consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
* Remove redundant null pointer checks before pg_free()Peter Eisentraut2022-07-03
| | | | | | | | | | These are especially useless because the whole point of pg_free() was to do that very check before calling free(). pg_free() could be removed altogether, but I'm keeping it here to keep the API consistent. Discussion: https://www.postgresql.org/message-id/flat/dac5d2d0-98f5-94d9-8e69-46da2413593d%40enterprisedb.com
* Add missing GETTEXT_FLAGS entryPeter Eisentraut2022-07-01
|
* pgindent run prior to branching v15.Tom Lane2022-06-30
| | | | pgperltidy and reformat-dat-files too. Not many changes.
* Translation updatesPeter Eisentraut2022-06-27
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 46c120873f1e906cc8dab74d8d756417e1b367f6
* Simplify tab completion of extension versions.Tom Lane2022-06-21
| | | | | | | | | | | | | | | | Second thoughts about 9cd43f6cb: given that we're staying bug-compatible with the old behavior of using double not single quotes for extension versions, we can simplify this completion code by pretending that extension versions *are* identifiers, and not using VERBATIM. Then _complete_from_query() will think that the query results are identifiers in need of quoting, and we end up with the same behavior as before. This doesn't work for Query_for_list_of_available_extension_versions_with_TO, but let's just drop that: there is no other place where we handle multi-keyword phrases that way, and it doesn't seem very desirable here either. Handle completion of "UPDATE TO" in our more usual pattern. Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com
* Message and documentation refinementsPeter Eisentraut2022-06-19
|
* Fix busted tab completion of extension versions.Tom Lane2022-06-18
| | | | | | | | | | | | | | | | | | | In 02b8048ba I (tgl) got rid of the need for most tab-completion queries to return pre-quoted identifiers. But I over-hastily removed the quote_ident call from Query_for_list_of_available_extension_versions* too; those still need it, because what is returned isn't an identifier at all and will (almost?) always need quoting. Arguably we should use quote_literal here instead. But quote_ident works too and people may be used to that behavior, so stick with it. In passing, fix inconsistent omission of schema-qualification in Query_for_list_of_encodings. That's not a security issue per our current guidelines, but it ought to be like the rest. Jeff Janes Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com
* Tweak behavior of psql --single-transaction depending on ON_ERROR_STOPMichael Paquier2022-06-15
| | | | | | | | | | | | | | | | | | | | | | | This commit, in completion of 157f873, forces a ROLLBACK for --single-transaction only when ON_ERROR_STOP is used when one of the steps defined by -f/-c fails. Hence, COMMIT is always used when ON_ERROR_STOP is not set, ignoring the status code of the last action taken in the set of switches specified by -c/-f (previously ROLLBACK would have been issued even without ON_ERROR_STOP if the last step failed, while COMMIT was issued if a step in-between failed as long as the last step succeeded, leading to more inconsistency). While on it, this adds much more test coverage in this area when not using ON_ERROR_STOP with multiple switch patterns involving -c and -f for query files, single queries and slash commands. The behavior of ON_ERROR_STOP is arguably a bug, but there was no much support for a backpatch to force a ROLLBACK on a step failure, so this change is done only on HEAD for now. Per discussion with Tom Lane and Kyotaro Horiguchi. Discussion: https://postgr.es/m/Yqbc8bAdwnP02na4@paquier.xyz
* psql: Show notices immediately (again)Peter Eisentraut2022-06-09
| | | | | | | | | | | | | | | The new show-all-results feature in psql (7844c9918) went out of its way to show notices next to the results of the statements (in a multi-statement string) that caused them. This also had the consequence that notices for a single statement were not shown until after the statement had executed, instead of right away. After some discussion, it seems very difficult to satisfy both of these goals, so here we are giving up on the first goal and just show the notices as we get them. This restores the pre-7844c9918 behavior for notices. Reported-by: Alastair McKinley <a.mckinley@analyticsengines.com> Author: Fabien COELHO <coelho@cri.ensmp.fr> Discussion: https://www.postgresql.org/message-id/flat/PAXPR02MB760039506C87A2083AD85575E3DA9%40PAXPR02MB7600.eurprd02.prod.outlook.com
* Fix portability issue in TAP tests of psql for localesMichael Paquier2022-06-08
| | | | | | | | | | | | | | | Some locales use a comma as decimal separator (like Czech or French), and psql's 001_basic.pl for \timing was not able to handle that properly. This fixes the matching regexes to be able to handle both comma and dot as possible decimal separators, as per a suggestion from Andrew Dunstan. psql tests were the only place with such a portability issue (check-world passed here with a forced LANG/LANGUAGE). These tests are new as of c0280bc, so there is no need for a backpatch. Reported-by: Pavel Stehule Discussion: https://postgr.es/m/CAFj8pRBz8iQmd2aOaCLvO-rJY6vZr-h6Q0qvV0J+yb78J7uiaA@mail.gmail.com
* Fix psql's single transaction mode on client-side errors with -c/-f switchesMichael Paquier2022-06-06
| | | | | | | | | | | | | | | | | | | | | | | psql --single-transaction is able to handle multiple -c and -f switches in a single transaction since d5563d7d, but this had the surprising behavior of forcing a transaction COMMIT even if psql failed with an error in the client (for example incorrect path given to \copy), which would generate an error, but still commit any changes that were already applied in the backend. This commit makes the behavior more consistent, by enforcing a transaction ROLLBACK if any commands fail, both client-side and backend-side, so as no changes are applied if one error happens in any of them. Some tests are added on HEAD to provide some coverage about all that. Backend-side errors are unreliable as IPC::Run can complain on SIGPIPE if psql quits before reading a query result, but that should work properly in the case where any errors come from psql itself, which is what the original report is about. Reported-by: Christoph Berg Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org Backpatch-through: 10
* Automatically count the number of output lines in psql/help.c.Tom Lane2022-06-04
| | | | | | | | | | | | | | | | | | | | The hard-wired PageOutput arguments in usage() and sibling functions have been a perennial maintenance gotcha, and there's no reason to think we'll ever get any better about that. Let's get rid of those magic constants by constructing the output in a buffer where we can count the newlines before calling PageOutput. (Perhaps this is microscopically slower; but none of these functions are performance critical, and anyway we might well be buying back all the cost by avoiding having to pass most of the data through snprintf.c. I could not detect any speed difference in a desultory check.) This also gets rid of the need to assume that platform-specific variations in the output are insignificant. While at it, make the code shorter and more abstract by inventing helper macros HELP0() and HELPN() to encapsulate the specific output actions being invoked. Discussion: https://postgr.es/m/365160.1654289490@sss.pgh.pa.us
* Improve psql \?'s description of large-object-related commands.Tom Lane2022-06-03
| | | | | | | | | | | | | Provide a gloss of which command does what, as all other backslash commands have. Put the large-object command section into a more considered spot in the list. In passing, update the output-lines count in helpVariables() (oversight in 7844c9918, looks like). Thibaud Walkowiak, reviewed by Nathan Bossart and myself Discussion: https://postgr.es/m/43f0439c-df3e-a045-ac99-af33523cc2d4@dalibo.com
* Add tab completion for table_rewrite's CREATE EVENT TRIGGER in psqlMichael Paquier2022-05-25
| | | | | Author: Hou Zhijie Discussion: https://postgr.es/m/OS0PR01MB5716DEFF787B925C4778228C94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com
* psql: Update \timing also in case of an errorPeter Eisentraut2022-05-23
| | | | | | | | | | | | | | | The changes to show all query results (7844c9918) broke \timing output in case of an error; it didn't update the timing result and showed 0.000 ms. Fix by updating the timing result also in the error case. Also, for robustness, update the timing result any time a result is obtained, not only for the last, so a sensible value is always available. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Author: Richard Guo <guofenglinux@gmail.com> Author: Fabien COELHO <coelho@cri.ensmp.fr> Discussion: https://www.postgresql.org/message-id/3813350.1652111765%40sss.pgh.pa.us
* Translation updatesPeter Eisentraut2022-05-16
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: dde45df385dab9032155c1f867b677d55695310c
* Pre-beta mechanical code beautification.Tom Lane2022-05-12
| | | | | Run pgindent, pgperltidy, and reformat-dat-files. I manually fixed a couple of comments that pgindent uglified.
* Add missing source files to nls.mkPeter Eisentraut2022-05-11
|
* Remove some tabs in SQL code in C string literalsPeter Eisentraut2022-05-10
| | | | | This is not handled uniformly throughout the code, but at least nearby code can be consistent.
* Allow db.schema.table patterns, but complain about random garbage.Robert Haas2022-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | psql, pg_dump, and pg_amcheck share code to process object name patterns like 'foo*.bar*' to match all tables with names starting in 'bar' that are in schemas starting with 'foo'. Before v14, any number of extra name parts were silently ignored, so a command line '\d foo.bar.baz.bletch.quux' was interpreted as '\d bletch.quux'. In v14, as a result of commit 2c8726c4b0a496608919d1f78a5abc8c9b6e0868, we instead treated this as a request for table quux in a schema named 'foo.bar.baz.bletch'. That caused problems for people like Justin Pryzby who were accustomed to copying strings of the form db.schema.table from messages generated by PostgreSQL itself and using them as arguments to \d. Accordingly, revise things so that if an object name pattern contains more parts than we're expecting, we throw an error, unless there's exactly one extra part and it matches the current database name. That way, thisdb.myschema.mytable is accepted as meaning just myschema.mytable, but otherdb.myschema.mytable is an error, and so is some.random.garbage.myschema.mytable. Mark Dilger, per report from Justin Pryzby and discussion among various people. Discussion: https://www.postgresql.org/message-id/20211013165426.GD27491%40telsasoft.com
* psql: fix \l display for pre-v15 databases.Tom Lane2022-04-15
| | | | | | | | | | | | | | With a pre-v15 server, show NULL for the "ICU Locale" column, matching what you see in v15 when the database locale isn't ICU. The previous coding incorrectly repeated datcollate here. (There's an unfinished discussion about whether to consolidate these columns in \l output, but in any case we'd want this fix for \l+ output.) Euler Taveira, per report from Christoph Berg Discussion: https://postgr.es/m/YlmIFCqu+TZSW4rB@msg.df7cb.de
* Fix case sensitivity in psql's tab completion for GUC names.Tom Lane2022-04-13
| | | | | | | | | | | | Input for these should be case-insensitive, but was not completely so. Comparing to the similar queries for timezone names, I realized that we'd missed forcing the comparison pattern to lower-case. With that, it behaves as I expect. While here, flatten the sub-selects in these queries; I don't find that those add any readability. Discussion: https://postgr.es/m/3369130.1649348542@sss.pgh.pa.us
* Further tweak the default behavior of psql's \dconfig.Tom Lane2022-04-13
| | | | | | | | | | | | | Define "parameters with non-default settings" as being those that not only have pg_settings.source different from 'default', but also have a current value different from the hard-wired boot_val. Adding the latter restriction removes a number of not-very-interesting cases where the active setting is chosen by initdb but in practice tends to be the same all the time. Per discussion with Jonathan Katz. Discussion: https://postgr.es/m/YlFQLzlPi4QD0wSi@msg.df7cb.de
* Remove extraneous blank lines before block-closing bracesAlvaro Herrera2022-04-13
| | | | | | | | | These are useless and distracting. We wouldn't have written the code with them to begin with, so there's no reason to keep them. Author: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com Discussion: https://postgr.es/m/attachment/133167/0016-Extraneous-blank-lines.patch
* Tweak the default behavior of psql's \dconfig.Tom Lane2022-04-11
| | | | | | | | | | | | \dconfig without an argument originally printed all parameters, but it seems more useful to print only those parameters with non-default settings. You can easily get the show-everything behavior with "\dconfig *", but that output is unwieldy and seems unlikely to be wanted very often. Per suggestion from Christoph Berg. Discussion: https://postgr.es/m/YlFQLzlPi4QD0wSi@msg.df7cb.de
* Fix various typos and spelling mistakes in code commentsDavid Rowley2022-04-11
| | | | | Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
* Improve frontend error logging style.Tom Lane2022-04-08
| | | | | | | | | | | | | | | | | | | | | | | | Get rid of the separate "FATAL" log level, as it was applied so inconsistently as to be meaningless. This mostly involves s/pg_log_fatal/pg_log_error/g. Create a macro pg_fatal() to handle the common use-case of pg_log_error() immediately followed by exit(1). Various modules had already invented either this or equivalent macros; standardize on pg_fatal() and apply it where possible. Invent the ability to add "detail" and "hint" messages to a frontend message, much as we have long had in the backend. Except where rewording was needed to convert existing coding to detail/hint style, I have (mostly) resisted the temptation to change existing message wording. Patch by me. Design and patch reviewed at various stages by Robert Haas, Kyotaro Horiguchi, Peter Eisentraut and Daniel Gustafsson. Discussion: https://postgr.es/m/1363732.1636496441@sss.pgh.pa.us
* psql: Fix translation markingPeter Eisentraut2022-04-08
| | | | | | | | | | | | | | | Commit 5a2832465fd8984d089e8c44c094e6900d987fcd added addFooterToPublicationDesc() as a wrapper around printTableAddFooter(). The translation marker _() was moved to the body of addFooterToPublicationDesc(), but addFooterToPublicationDesc() was not added to GETTEXT_TRIGGERS, so those strings were lost for translation. To fix, add the translation markers to the call sites of addFooterToPublicationDesc() and remove the translation marker from the body of the function. This seems easiest since there were only two callers and it keeps the API consistent with printTableAddFooter(). While we're here, add some const decorations to the prototype of addFooterToPublicationDesc() for consistency with printTableAddFooter().
* psql: add \dconfig command to show server's configuration parameters.Tom Lane2022-04-07
| | | | | | | | | | | | | | | | | | | | | | Plain \dconfig is basically equivalent to SHOW except that you can give it a pattern with wildcards, either to match multiple GUCs or because you don't exactly remember the name you want. \dconfig+ adds type, context, and access-privilege information, mainly because every other kind of object privilege has a psql command to show it, so GUC privileges should too. (A form of this command was in some versions of the patch series leading up to commit a0ffa885e. We pulled it out then because of doubts that the design and code were up to snuff, but I think subsequent work has resolved that.) In passing, fix incorrect completion of GUC names in GRANT/REVOKE ON PARAMETER: a0ffa885e neglected to use the VERBATIM form of COMPLETE_WITH_QUERY, so it misbehaved for custom (qualified) GUC names. Mark Dilger and Tom Lane Discussion: https://postgr.es/m/3118455.1649267333@sss.pgh.pa.us
* Revert "Logical decoding of sequences"Tomas Vondra2022-04-07
| | | | | | | | | | | | | | | | | | | | | This reverts a sequence of commits, implementing features related to logical decoding and replication of sequences: - 0da92dc530c9251735fc70b20cd004d9630a1266 - 80901b32913ffa59bf157a4d88284b2b3a7511d9 - b779d7d8fdae088d70da5ed9fcd8205035676df3 - d5ed9da41d96988d905b49bebb273a9b2d6e2915 - a180c2b34de0989269fdb819bff241a249bf5380 - 75b1521dae1ff1fde17fda2e30e591f2e5d64b6a - 2d2232933b02d9396113662e44dca5f120d6830e - 002c9dd97a0c874fd1693a570383e2dd38cd40d5 - 05843b1aa49df2ecc9b97c693b755bd1b6f856a9 The implementation has issues, mostly due to combining transactional and non-transactional behavior of sequences. It's not clear how this could be fixed, but it'll require reworking significant part of the patch. Discussion: https://postgr.es/m/95345a19-d508-63d1-860a-f5c2f41e8d40@enterprisedb.com
* Unlogged sequencesPeter Eisentraut2022-04-07
| | | | | | | | | | | | | | | | | | Add support for unlogged sequences. Unlike for unlogged tables, this is not a performance feature. It allows sequences associated with unlogged tables to be excluded from replication. A new subcommand ALTER SEQUENCE ... SET LOGGED/UNLOGGED is added. An identity/serial sequence now automatically gets and follows the persistence level (logged/unlogged) of its owning table. (The sequences owned by temporary tables were already temporary through the separate mechanism in RangeVarAdjustRelationPersistence().) But you can still change the persistence of an owned sequence separately. Also, pg_dump and pg_upgrade preserve the persistence of existing sequences. Discussion: https://www.postgresql.org/message-id/flat/04e12818-2f98-257c-b926-2845d74ed04f%402ndquadrant.com
* Allow granting SET and ALTER SYSTEM privileges on GUC parameters.Tom Lane2022-04-06
| | | | | | | | | | | | | | | | | | | | This patch allows "PGC_SUSET" parameters to be set by non-superusers if they have been explicitly granted the privilege to do so. The privilege to perform ALTER SYSTEM SET/RESET on a specific parameter can also be granted. Such privileges are cluster-wide, not per database. They are tracked in a new shared catalog, pg_parameter_acl. Granting and revoking these new privileges works as one would expect. One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege --- one could wish that those were handled by a revocable grant to PUBLIC, but they are not, because we couldn't make it robust enough for GUCs defined by extensions. Mark Dilger, reviewed at various times by Andrew Dunstan, Robert Haas, Joshua Brindle, and myself Discussion: https://postgr.es/m/3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com
* psql: Show all query results by defaultPeter Eisentraut2022-04-04
| | | | | | | | | | | | | | | | | | | Previously, psql printed only the last result if a command string returned multiple result sets. Now it prints all of them. The previous behavior can be obtained by setting the psql variable SHOW_ALL_RESULTS to off. This is a significantly enhanced version of 3a5130672296ed4e682403a77a9a3ad3d21cef75 (that was later reverted). There is also much more test coverage for various psql features now. Author: Fabien COELHO <coelho@cri.ensmp.fr> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: "Iwata, Aya" <iwata.aya@jp.fujitsu.com> (earlier version) Reviewed-by: Daniel Verite <daniel@manitou-mail.org> (earlier version) Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> (earlier version) Reviewed-by: vignesh C <vignesh21@gmail.com> (earlier version) Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1904132231510.8961@lancre
* Allow CLUSTER on partitioned tablesAlvaro Herrera2022-04-02
| | | | | | | | | | | | | | | | | | | | This is essentially the same as applying VACUUM FULL to a partitioned table, which has been supported since commit 3c3bb99330aa (March 2017). While there's no great use case in applying CLUSTER to partitioned tables, we don't have any strong reason not to allow it either. For now, partitioned indexes cannot be marked clustered, so an index must always be specified. While at it, rename some variables that were RangeVars during the development that led to 8bc717cb8878 but never made it that way to the source tree; there's no need to perpetuate names that have always been more confusing than helpful. Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Discussion: https://postgr.es/m/20201028003312.GU9241@telsasoft.com Discussion: https://postgr.es/m/20200611153502.GT14879@telsasoft.com
* psql: Refactor ProcessResult()Peter Eisentraut2022-04-01
| | | | | | | | Separate HandleCopyResult() from ProcessResult() in preparation for a subsequent patch. Author: Fabien COELHO <coelho@cri.ensmp.fr> Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1904132231510.8961@lancre