aboutsummaryrefslogtreecommitdiff
path: root/src/bin/psql
Commit message (Collapse)AuthorAge
...
* Remove silly completion for "DELETE FROM tabname ...".Tom Lane2015-12-20
| | | | | | psql offered USING, WHERE, and SET in this context, but SET is not a valid possibility here. Seems to have been a thinko in commit f5ab0a14ea83eb6c which added DELETE's USING option.
* Teach psql's tab completion to consider the entire input string.Tom Lane2015-12-20
| | | | | | | | | | | | | | | | | | | | | | | Up to now, the tab completion logic has only examined the last few words of the current input line; "last few" being originally as few as four words, but lately up to nine words. Furthermore, it only looked at what libreadline considers the current line of input, which made it rather myopic if you split your command across lines. This was tolerable, sort of, so long as the match patterns were only designed to consider the last few words of input; but with the recent addition of HeadMatches() and Matches() matching rules, we really have to do better if we want those to behave sanely. Hence, change the code to break the entire line down into words, and to include any previous lines in the command buffer along with the active readline input buffer. This will be a little bit slower than the previous coding, but some measurements say that even a query of several thousand characters can be parsed in a hundred or so microseconds on modern machines; so it's really not going to be significant for interactive tab completion. To reduce the cost some, I arranged to avoid the per-word malloc calls that used to occur: all the words are now kept in one malloc'd buffer.
* psql: Review of new help output stringsPeter Eisentraut2015-12-20
|
* Adopt a more compact, less error-prone notation for tab completion code.Tom Lane2015-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace tests like else if (pg_strcasecmp(prev4_wd, "CREATE") == 0 && pg_strcasecmp(prev3_wd, "TRIGGER") == 0 && (pg_strcasecmp(prev_wd, "BEFORE") == 0 || pg_strcasecmp(prev_wd, "AFTER") == 0)) with new notation like this: else if (TailMatches4("CREATE", "TRIGGER", MatchAny, "BEFORE|AFTER")) In addition, provide some macros COMPLETE_WITH_LISTn() to reduce the amount of clutter needed to specify a small number of predetermined completion alternatives. This makes the code substantially more compact: tab-complete.c gets over a thousand lines shorter in this patch, despite the addition of a couple of hundred lines of infrastructure for the new notations. The new way of specifying match rules seems a whole lot more readable and less error-prone, too. There's a lot more that could be done now to make matching faster and more reliable; for example I suspect that most of the TailMatches() rules should now be Matches() rules. That would allow them to be skipped after a single integer comparison if there aren't the right number of words on the line, and it would reduce the risk of unintended matches. But for now, (mostly) refrain from reworking any match rules in favor of just converting what we've got into the new notation. Thomas Munro, reviewed by Michael Paquier, some adjustments by me
* Fix tab completion for ALTER ... TABLESPACE ... OWNED BY.Andres Freund2015-12-19
| | | | | | | | | | | | Previously the completion used the wrong word to match 'BY'. This was introduced brokenly, in b2de2a. While at it, also add completion of IN TABLESPACE ... OWNED BY and fix comments referencing nonexistent syntax. Reported-By: Michael Paquier Author: Michael Paquier and Andres Freund Discussion: CAB7nPqSHDdSwsJqX0d2XzjqOHr==HdWiubCi4L=Zs7YFTUne8w@mail.gmail.com Backpatch: 9.4, like the commit introducing the bug
* Fix improper initialization order for readline.Tom Lane2015-12-17
| | | | | | | | | Turns out we must set rl_basic_word_break_characters *before* we call rl_initialize() the first time, because it will quietly copy that value elsewhere --- but only on the first call. (Love these undocumented dependencies.) I broke this yesterday in commit 2ec477dc8108339d; like that commit, back-patch to all active branches. Per report from Pavel Stehule.
* Cope with Readline's failure to track SIGWINCH events outside of input.Tom Lane2015-12-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It emerges that libreadline doesn't notice terminal window size change events unless they occur while collecting input. This is easy to stumble over if you resize the window while using a pager to look at query output, but it can be demonstrated without any pager involvement. The symptom is that queries exceeding one line are misdisplayed during subsequent input cycles, because libreadline has the wrong idea of the screen dimensions. The safest, simplest way to fix this is to call rl_reset_screen_size() just before calling readline(). That causes an extra ioctl(TIOCGWINSZ) for every command; but since it only happens when reading from a tty, the performance impact should be negligible. A more valid objection is that this still leaves a tiny window during entry to readline() wherein delivery of SIGWINCH will be missed; but the practical consequences of that are probably negligible. In any case, there doesn't seem to be any good way to avoid the race, since readline exposes no functions that seem safe to call from a generic signal handler --- rl_reset_screen_size() certainly isn't. It turns out that we also need an explicit rl_initialize() call, else rl_reset_screen_size() dumps core when called before the first readline() call. rl_reset_screen_size() is not present in old versions of libreadline, so we need a configure test for that. (rl_initialize() is present at least back to readline 4.0, so we won't bother with a test for it.) We would need a configure test anyway since libedit's emulation of libreadline doesn't currently include such a function. Fortunately, libedit seems not to have any corresponding bug. Merlin Moncure, adjusted a bit by me
* Code and docs review for multiple -c and -f options in psql.Tom Lane2015-12-13
| | | | | | | | | | | Commit d5563d7df94488bf drew complaints from Coverity, which quite correctly complained that one copy of each -c or -f string was being leaked. What's more, simple_action_list_append was allocating enough space for still a third copy of each string as part of the SimpleActionListCell, even though that coding method had been superseded by a separate strdup operation. There were some other minor coding infelicities too. The documentation needed more work as well, eg it forgot to explain that -c causes psql not to accept any interactive input.
* Improve ALTER POLICY tab completion.Robert Haas2015-12-10
| | | | | | | | | Complete "ALTER POLICY" with a policy name, as we do for DROP POLICY. And, complete "ALTER POLICY polname ON" with a table name that has such a policy, as we do for DROP POLICY, rather than with any table name at all. Masahiko Sawada
* Make failure to open psql's --log-file fatal.Tom Lane2015-12-08
| | | | | | | | Commit 344cdff2c made failure to open the target of --output fatal. For consistency, the --log-file switch should behave similarly. Like the previous commit, back-patch to 9.5 but no further. Daniel Verite
* psql: Support multiple -c and -f options, and allow mixing them.Robert Haas2015-12-08
| | | | | | | | | To support this, we must reconcile some historical anomalies in the behavior of -c. In particular, as a backward-incompatibility, -c no longer implies --no-psqlrc. Pavel Stehule (code) and Catalin Iacob (documentation). Review by Michael Paquier and myself. Proposed behavior per Tom Lane.
* Clean up some psql issues around handling of the query output file.Tom Lane2015-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, if "psql -o foo" failed to open the output file "foo", it would print an error message but then carry on as though -o had not been specified at all. This seems contrary to expectation: a program that cannot open its output file normally fails altogether. Make psql do exit(1) after reporting the error. If "\o foo" failed to open "foo", it would print an error message but then reset the output file to stdout, as if the argument had been omitted. This is likewise pretty surprising behavior. Make it keep the previous output state, instead. psql keeps SIGPIPE interrupts disabled when it is writing to a pipe, either a pipe specified by -o/\o or a transient pipe opened for purposes such as using a pager on query output. The logic for this was too simple and could sometimes re-enable SIGPIPE when a -o pipe was still active, thus possibly leading to an unexpected psql crash later. Fixing the last point required getting rid of the kluge in PrintQueryTuples and ExecQueryUsingCursor whereby they'd transiently change the global queryFout state, but that seems like good cleanup anyway. Back-patch to 9.5 but not further; these are minor-enough issues that changing the behavior in stable branches doesn't seem appropriate.
* psql: Improve spellingPeter Eisentraut2015-12-03
|
* Fix behavior of printTable() and friends with externally-invoked pager.Tom Lane2015-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The formatting modes that depend on knowledge of the terminal window width did not work right when printing a query result that's been fetched in sections (as a result of FETCH_SIZE). ExecQueryUsingCursor() would force use of the pager as soon as there's more than one result section, and then print.c would see an output file pointer that's not stdout and incorrectly conclude that the terminal window width isn't relevant. This has been broken all along for non-expanded "wrapped" output format, and as of 9.5 the issue affects expanded mode as well. The problem also caused "\pset expanded auto" mode to invariably *not* switch to expanded output in a segmented result, which seems to me to be exactly backwards. To fix, we need to pass down an "is_pager" flag to inform the print.c subroutines that some calling level has already replaced stdout with a pager pipe, so they should (a) not do that again and (b) nonetheless honor the window size. (Notably, this makes the first is_pager test in print_aligned_text() not be dead code anymore.) This patch is a bit invasive because there are so many existing calls of printQuery()/printTable(), but fortunately all but a couple can just pass "false" for the added parameter. Back-patch to 9.5 but no further. Given the lack of field complaints, it's not clear that we should change the behavior in stable branches. Also, the API change for printQuery()/printTable() might possibly break third-party code, again something we don't like to do in stable branches. However, it's not quite too late to do this in 9.5, and with the larger scope of the problem there, it seems worth doing.
* Further tweaking of print_aligned_vertical().Tom Lane2015-12-01
| | | | | | | | | | | Don't force the data width to extend all the way to the right margin if it doesn't need to. This reverts the behavior in non-wrapping cases to be what it was in 9.4. Also, make the logic that ensures the data line width is at least equal to the record-header line width a little less obscure. In passing, avoid possible calculation of log10(0). Probably that's harmless, given the lack of field complaints, but it seems risky: conversion of NaN to an integer isn't well defined.
* Further adjustment to psql's print_aligned_vertical() function.Tom Lane2015-12-01
| | | | | | | | | We should ignore output_columns unless it's greater than zero. A zero means we couldn't get any information from ioctl(TIOCGWINSZ); in that case the expected behavior is to print the data at native width, not to wrap it at the smallest possible value. print_aligned_text() gets this consideration right, but print_aligned_vertical() lost track of this detail somewhere along the line.
* Rework wrap-width calculation in psql's print_aligned_vertical() function.Tom Lane2015-11-30
| | | | | | | | | | | | | | | | | | | This area was rather heavily whacked around in 6513633b9 and follow-on commits, and it was showing it, because the logic to calculate the allowable data width in wrapped expanded mode had only the vaguest relationship to the logic that was actually printing the data. It was not very close to being right about the conditions requiring overhead columns to be added. Aside from being wrong, it was pretty unreadable and under-commented. Rewrite it so it corresponds to what the printing code actually does. In passing, remove a couple of dead tests in the printing logic, too. Per a complaint from Jeff Janes, though this doesn't look much like his patch because it fixes a number of other corner-case bogosities too. One such fix that's visible in the regression test results is that although the code was attempting to enforce a minimum data width of 3 columns, it sometimes left less space than that available.
* Improve PQhost() to return useful data for default Unix-socket connections.Tom Lane2015-11-27
| | | | | | | | | | | | | | | | | | | | | | Previously, if no host information had been specified at connection time, PQhost() would return NULL (unless you are on Windows, in which case you got "localhost"). This is an unhelpful definition for a couple of reasons: it can cause corner-case crashes in applications (cf commit c5ef8ce53d), and there's no well-defined way for applications to find out the socket directory path that's actually in use. As an example of the latter problem, psql substituted DEFAULT_PGSOCKET_DIR for NULL in a couple of places, but this is subtly wrong because it's conceivable that psql is using a libpq shared library that was built with a different setting. Hence, change PQhost() to return DEFAULT_PGSOCKET_DIR when appropriate, and strip out the now-dead substitutions in psql. (There is still one remaining reference to DEFAULT_PGSOCKET_DIR in psql, in prompt.c, which I don't see a nice way to get rid of. But it only controls a prompt abbreviation decision, so it seems noncritical.) Also update the docs for PQhost, which had never previously mentioned the possibility of a socket directory path being returned. In passing fix the outright-incorrect code comment about PGconn.pgunixsocket.
* COPY (INSERT/UPDATE/DELETE .. RETURNING ..)Teodor Sigaev2015-11-27
| | | | | | | Attached is a patch for being able to do COPY (query) without a CTE. Author: Marko Tiikkaja Review: Michael Paquier
* Be more paranoid about null return values from libpq status functions.Tom Lane2015-11-25
| | | | | | | | | | | | | | | | | PQhost() can return NULL in non-error situations, namely when a Unix-socket connection has been selected by default. That behavior is a tad debatable perhaps, but for the moment we should make sure that psql copes with it. Unfortunately, do_connect() failed to: it could pass a NULL pointer to strcmp(), resulting in crashes on most platforms. This was reported as a security issue by ChenQin of Topsec Security Team, but the consensus of the security list is that it's just a garden-variety bug with no security implications. For paranoia's sake, I made the keep_password test not trust PQuser or PQport either, even though I believe those will never return NULL given a valid PGconn. Back-patch to all supported branches.
* When completing ALTER INDEX .. SET, add an equals sign also.Robert Haas2015-11-06
| | | | Jeff Janes
* Code + docs review for unicode linestyle patch.Tom Lane2015-11-03
| | | | | | | | | Fix some brain fade in commit a2dabf0e1dda93c8: erroneous variable names in docs, rearrangements that made sentences less clear not more so, undocumented and poorly-chosen-anyway API behaviors of subroutines, bad grammar in error messages, copy-and-paste faults. Albe Laurenz and Tom Lane
* Message style improvementsPeter Eisentraut2015-10-28
| | | | | Message style, plurals, quoting, spelling, consistency with similar messages
* Remove redundant CREATEUSER/NOCREATEUSER options in CREATE ROLE et al.Tom Lane2015-10-22
| | | | | | | | | | | | Once upon a time we did not have a separate CREATEROLE privilege, and CREATEUSER effectively meant SUPERUSER. When we invented CREATEROLE (in 8.1) we also added SUPERUSER so as to have a less confusing keyword for this role property. However, we left CREATEUSER in place as a deprecated synonym for SUPERUSER, because of backwards-compatibility concerns. It's still there and is still confusing people, as for example in bug #13694 from Justin Catterson. 9.6 will be ten years or so later, which surely ought to be long enough to end the deprecation and just remove these old keywords. Hence, do so.
* Tab complete CREATE EXTENSION .. VERSION.Robert Haas2015-10-20
| | | | Jeff Janes
* psql: allow \pset C in setting the title, matches \CBruce Momjian2015-10-05
| | | | Report by David G. Johnston
* ALTER TABLE .. FORCE ROW LEVEL SECURITYStephen Frost2015-10-04
| | | | | | | | | | | | | | | | | To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS context to avoid data corruption when ALTER TABLE .. FORCE ROW SECURITY is being used. The SECURITY_NOFORCE_RLS security context is used only during referential integrity checks and is only considered in check_enable_rls() after we have already checked that the current user is the owner of the relation (which should always be the case during referential integrity checks). Back-patch to 9.5 where RLS was added.
* Add CASCADE support for CREATE EXTENSION.Andres Freund2015-10-03
| | | | | | | | | | | | | | | Without CASCADE, if an extension has an unfullfilled dependency on another extension, CREATE EXTENSION ERRORs out with "required extension ... is not installed". That is annoying, especially when that dependency is an implementation detail of the extension, rather than something the extension's user can make sense of. In addition to CASCADE this also includes a small set of regression tests around CREATE EXTENSION. Author: Petr Jelinek, editorialized by Michael Paquier, Andres Freund Reviewed-By: Michael Paquier, Andres Freund, Jeff Janes Discussion: 557E0520.3040800@2ndquadrant.com
* Fix incorrect tab-completion for GRANT and REVOKEFujii Masao2015-10-01
| | | | | | | | Previously "GRANT * ON * TO " was tab-completed to add an extra "TO", rather than with a list of roles. This is the bug that commit 2f88807 introduced unexpectedly. This commit fixes that incorrect tab-completion. Thomas Munro, reviewed by Jeff Janes.
* Fix compiler warning for non-TIOCGWINSZ caseAndrew Dunstan2015-09-28
| | | | Backpatch to 9.5 where the error was introduced.
* Fix compiler warning about unused function in non-readline case.Andrew Dunstan2015-09-28
| | | | Backpatch to all live branches to keep the code in sync.
* Further fix for psql's code for locale-aware formatting of numeric output.Tom Lane2015-09-25
| | | | | | | | | | | | (Third time's the charm, I hope.) Additional testing disclosed that this code could mangle already-localized output from the "money" datatype. We can't very easily skip applying it to "money" values, because the logic is tied to column right-justification and people expect "money" output to be right-justified. Short of decoupling that, we can fix it in what should be a safe enough way by testing to make sure the string doesn't contain any characters that would not be expected in plain numeric output.
* Further fix for psql's code for locale-aware formatting of numeric output.Tom Lane2015-09-25
| | | | | | | | | | | | | | | | On closer inspection, those seemingly redundant atoi() calls were not so much inefficient as just plain wrong: the author of this code either had not read, or had not understood, the POSIX specification for localeconv(). The grouping field is *not* a textual digit string but separate integers encoded as chars. We'll follow the existing code as well as the backend's cash.c in only honoring the first group width, but let's at least honor it correctly. This doesn't actually result in any behavioral change in any of the locales I have installed on my Linux box, which may explain why nobody's complained; grouping width 3 is close enough to universal that it's barely worth considering other cases. Still, wrong is wrong, so back-patch.
* Fix psql's code for locale-aware formatting of numeric output.Tom Lane2015-09-24
| | | | | | | | | | | | | | This code did the wrong thing entirely for numbers with an exponent but no decimal point (e.g., '1e6'), as reported by Jeff Janes in bug #13636. More generally, it made lots of unverified assumptions about what the input string could possibly look like. Rearrange so that it only fools with leading digits that it's directly verified are there, and an immediately adjacent decimal point. While at it, get rid of some useless inefficiencies, like converting the grouping count string to integer over and over (and over). This has been broken for a long time, so back-patch to all supported branches.
* Review program help output for wording and formattingPeter Eisentraut2015-09-16
|
* psql: Generic tab completion support for enum and bool GUCs.Andres Freund2015-09-08
| | | | | | Author: Pavel Stehule Reviewed-By: Andres Freund Discussion: 5594FE7A.5050205@iki.fi
* Improve tab-completion for GRANT and REVOKE.Fujii Masao2015-09-09
| | | | Thomas Munro, reviewed by Michael Paquier, modified by me.
* Allow per-tablespace effective_io_concurrencyAlvaro Herrera2015-09-08
| | | | | | | | | | Per discussion, nowadays it is possible to have tablespaces that have wildly different I/O characteristics from others. Setting different effective_io_concurrency parameters for those has been measured to improve performance. Author: Julien Rouhaud Reviewed by: Andres Freund
* Rearrange the handling of error context reports.Tom Lane2015-09-05
| | | | | | | | | | | | | | | | | | | | | | | | Remove the code in plpgsql that suppressed the innermost line of CONTEXT for messages emitted by RAISE commands. That was never more than a quick backwards-compatibility hack, and it's pretty silly in cases where the RAISE is nested in several levels of function. What's more, it violated our design theory that verbosity of error reports should be controlled on the client side not the server side. To alleviate the resulting noise increase, introduce a feature in libpq and psql whereby the CONTEXT field of messages can be suppressed, either always or only for non-error messages. Printing CONTEXT for errors only is now their default behavior. The actual code changes here are pretty small, but the effects on the regression test outputs are widespread. I had to edit some of the alternative expected outputs by hand; hopefully the buildfarm will soon find anything I fat-fingered. In passing, fix up (again) the output line counts in psql's various help displays. Add some commentary about how to verify them. Pavel Stehule, reviewed by Petr Jelínek, Jeevan Chalke, and others
* psql: print longtable as a possible \pset optionBruce Momjian2015-08-31
| | | | | | | For some reason this message was not updated when the longtable option was added. Backpatch through 9.3
* psql: Make EXECUTE PROCEDURE tab completion a bit narrower.Robert Haas2015-08-18
| | | | | | | If the user has typed GRANT EXECUTE, the correct completion is "ON", not "PROCEDURE". Daniel Verite
* Tab completion for CREATE SEQUENCE.Robert Haas2015-08-04
| | | | Vik Fearing, reviewed by Brendan Jurd, Michael Paquier, and myself
* Fix psql \d output of policies.Joe Conway2015-08-03
| | | | | | psql neglected to wrap parenthesis around USING and WITH CHECK expressions -- fixed. Back-patched to 9.5 where RLS policies were introduced.
* Redesign tablesample method API, and do extensive code review.Tom Lane2015-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original implementation of TABLESAMPLE modeled the tablesample method API on index access methods, which wasn't a good choice because, without specialized DDL commands, there's no way to build an extension that can implement a TSM. (Raw inserts into system catalogs are not an acceptable thing to do, because we can't undo them during DROP EXTENSION, nor will pg_upgrade behave sanely.) Instead adopt an API more like procedural language handlers or foreign data wrappers, wherein the only SQL-level support object needed is a single handler function identified by having a special return type. This lets us get rid of the supporting catalog altogether, so that no custom DDL support is needed for the feature. Adjust the API so that it can support non-constant tablesample arguments (the original coding assumed we could evaluate the argument expressions at ExecInitSampleScan time, which is undesirable even if it weren't outright unsafe), and discourage sampling methods from looking at invisible tuples. Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable within and across queries, as required by the SQL standard, and deal more honestly with methods that can't support that requirement. Make a full code-review pass over the tablesample additions, and fix assorted bugs, omissions, infelicities, and cosmetic issues (such as failure to put the added code stanzas in a consistent ordering). Improve EXPLAIN's output of tablesample plans, too. Back-patch to 9.5 so that we don't have to support the original API in production.
* Improve tab-completion for DROP POLICYAlvaro Herrera2015-07-20
| | | | | | Backpatch to 9.5. Author: Pavel Stěhule
* Fix null pointer dereference in "\c" psql command.Noah Misch2015-07-08
| | | | | | The psql crash happened when no current connection existed. (The second new check is optional given today's undocumented NULL argument handling in PQhost() etc.) Back-patch to 9.0 (all supported versions).
* Add tab-completion for psql meta-commands.Fujii Masao2015-07-07
| | | | Based on the original code from David Christensen, modified by me.
* Add psql PROMPT variable showing the pid of the connected to backend.Andres Freund2015-07-07
| | | | | | | The substitution for the pid is %p. Author: Julien Rouhaud Discussion: 116262CF971C844FB6E793F8809B51C6E99D48@BPXM02GP.gisp.nec.co.jp
* Add psql \ev and \sv commands for editing and showing view definitions.Tom Lane2015-07-03
| | | | | | These are basically just like the \ef and \sf commands for functions. Petr Korobeinikov, reviewed by Jeevan Chalke, some changes by me
* Use appendStringInfoString/Char et al where appropriate.Heikki Linnakangas2015-07-02
| | | | | | Patch by David Rowley. Backpatch to 9.5, as some of the calls were new in 9.5, and keeping the code in sync with master makes future backpatching easier.