2000-01-19 00:30:24 +01:00
/*
* psql - the PostgreSQL interactive terminal
*
2017-01-03 19:48:53 +01:00
* Copyright ( c ) 2000 - 2017 , PostgreSQL Global Development Group
2000-01-19 00:30:24 +01:00
*
2010-09-20 22:08:53 +02:00
* src / bin / psql / tab - complete . c
2000-01-19 00:30:24 +01:00
*/
2000-06-25 16:25:51 +02:00
/*----------------------------------------------------------------------
* This file implements a somewhat more sophisticated readline " TAB
* completion " in psql. It is not intended to be AI, to replace
* learning SQL , or to relieve you from thinking about what you ' re
* doing . Also it does not always give you all the syntactically legal
* completions , only those that are the most common or the ones that
* the programmer felt most like implementing .
*
* CAVEAT : Tab completion causes queries to be sent to the backend .
2003-10-16 22:03:09 +02:00
* The number of tuples returned gets limited , in most default
* installations to 1000 , but if you still don ' t like this prospect ,
2000-06-25 16:25:51 +02:00
* you can turn off tab completion in your ~ / . inputrc ( or else
* $ { INPUTRC } ) file so :
*
2001-03-22 05:01:46 +01:00
* $ if psql
* set disable - completion on
* $ endif
2000-06-25 16:25:51 +02:00
*
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* See ` man 3 readline ' or ` info readline ' for the full details .
2000-06-25 16:25:51 +02:00
*
* BUGS :
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* - Quotes , parentheses , and other funny characters are not handled
2001-03-22 05:01:46 +01:00
* all that gracefully .
2000-06-25 16:25:51 +02:00
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*/
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2001-02-10 03:31:31 +01:00
# include "postgres_fe.h"
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
# include "tab-complete.h"
# include "input.h"
/* If we don't have this, we might as well forget about the whole thing: */
# ifdef USE_READLINE
2000-12-03 21:45:40 +01:00
# include <ctype.h>
2017-03-10 04:42:16 +01:00
# include "catalog/pg_class.h"
2000-02-16 14:15:26 +01:00
# include "libpq-fe.h"
2006-06-12 01:06:00 +02:00
# include "pqexpbuffer.h"
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
# include "common.h"
2000-01-19 00:30:24 +01:00
# include "settings.h"
2008-03-29 20:19:14 +01:00
# include "stringutils.h"
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2001-06-12 00:12:48 +02:00
# ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
# define filename_completion_function rl_filename_completion_function
2001-06-20 20:39:14 +02:00
# else
/* missing in some header files */
extern char * filename_completion_function ( ) ;
2001-06-12 00:12:48 +02:00
# endif
2000-04-12 19:17:23 +02:00
2001-04-15 00:55:02 +02:00
# ifdef HAVE_RL_COMPLETION_MATCHES
2003-04-03 22:18:16 +02:00
# define completion_matches rl_completion_matches
2000-03-05 14:30:20 +01:00
# endif
2010-02-17 05:09:40 +01:00
/* word break characters */
# define WORD_BREAKS "\t\n@$><=;|&{() "
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
* Since readline doesn ' t let us pass any state through to the tab completion
* callback , we have to use this global variable to let get_previous_words ( )
* get at the previous lines of the current command . Ick .
*/
PQExpBuffer tab_completion_query_buf = NULL ;
2003-10-30 22:37:38 +01:00
/*
* This struct is used to define " schema queries " , which are custom - built
* to obtain possibly - schema - qualified names of database objects . There is
* enough similarity in the structure that we don ' t want to repeat it each
* time . So we put the components of each query into this struct and
* assemble them with the common boilerplate in _complete_from_query ( ) .
*/
typedef struct SchemaQuery
{
/*
* Name of catalog or catalogs to be queried , with alias , eg .
* " pg_catalog.pg_class c " . Note that " pg_namespace n " will be added .
*/
const char * catname ;
2004-08-29 07:07:03 +02:00
2003-10-30 22:37:38 +01:00
/*
2005-10-15 04:49:52 +02:00
* Selection condition - - - only rows meeting this condition are candidates
2014-05-06 18:12:18 +02:00
* to display . If catname mentions multiple tables , include the necessary
2017-03-10 04:42:16 +01:00
* join condition here . For example , this might look like " c.relkind = "
* CppAsString2 ( RELKIND_RELATION ) . Write NULL ( not an empty string ) if
* not needed .
2003-10-30 22:37:38 +01:00
*/
const char * selcondition ;
2004-08-29 07:07:03 +02:00
2003-10-30 22:37:38 +01:00
/*
* Visibility condition - - - which rows are visible without schema
2005-10-15 04:49:52 +02:00
* qualification ? For example , " pg_catalog.pg_table_is_visible(c.oid) " .
2003-10-30 22:37:38 +01:00
*/
const char * viscondition ;
2004-08-29 07:07:03 +02:00
2003-10-30 22:37:38 +01:00
/*
2005-10-15 04:49:52 +02:00
* Namespace - - - name of field to join to pg_namespace . oid . For example ,
* " c.relnamespace " .
2003-10-30 22:37:38 +01:00
*/
const char * namespace ;
2004-08-29 07:07:03 +02:00
2003-10-30 22:37:38 +01:00
/*
2005-10-15 04:49:52 +02:00
* Result - - - the appropriately - quoted name to return , in the case of an
* unqualified name . For example , " pg_catalog.quote_ident(c.relname) " .
2003-10-30 22:37:38 +01:00
*/
const char * result ;
2004-08-29 07:07:03 +02:00
2003-10-30 22:37:38 +01:00
/*
* In some cases a different result must be used for qualified names .
* Enter that here , or write NULL if result can be used .
*/
const char * qualresult ;
} SchemaQuery ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2000-04-12 19:17:23 +02:00
2003-10-30 22:37:38 +01:00
/* Store maximum number of records we want from database queries
* ( implemented via SELECT . . . LIMIT xx ) .
*/
static int completion_max_records ;
2000-04-12 19:17:23 +02:00
2003-10-30 22:37:38 +01:00
/*
* Communication variables set by COMPLETE_WITH_FOO macros and then used by
* the completion callback functions . Ugly but there is no better way .
*/
2009-06-11 16:49:15 +02:00
static const char * completion_charp ; /* to pass a string */
2005-10-15 04:49:52 +02:00
static const char * const * completion_charpp ; /* to pass a list of strings */
2004-08-29 07:07:03 +02:00
static const char * completion_info_charp ; /* to pass a second string */
2008-03-29 20:19:14 +01:00
static const char * completion_info_charp2 ; /* to pass a third string */
2004-08-29 07:07:03 +02:00
static const SchemaQuery * completion_squery ; /* to pass a SchemaQuery */
2012-06-10 21:20:04 +02:00
static bool completion_case_sensitive ; /* completion is case sensitive */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2008-03-29 20:19:14 +01:00
/*
* A few macros to ease typing . You can use these to complete the given
* string with
* 1 ) The results from a query you pass it . ( Perhaps one of those below ? )
* 2 ) The results from a schema query you pass it .
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* 3 ) The items from a null - pointer - terminated list ( with or without
* case - sensitive comparison ; see also COMPLETE_WITH_LISTn , below ) .
2008-03-29 20:19:14 +01:00
* 4 ) A string constant .
* 5 ) The list of attributes of the given table ( possibly schema - qualified ) .
2012-07-05 14:03:49 +02:00
* 6 / The list of arguments to the given function ( possibly schema - qualified ) .
2008-03-29 20:19:14 +01:00
*/
2003-10-30 22:37:38 +01:00
# define COMPLETE_WITH_QUERY(query) \
2008-03-29 20:19:14 +01:00
do { \
completion_charp = query ; \
matches = completion_matches ( text , complete_from_query ) ; \
} while ( 0 )
2006-02-12 08:21:40 +01:00
# define COMPLETE_WITH_SCHEMA_QUERY(query, addon) \
2008-03-29 20:19:14 +01:00
do { \
completion_squery = & ( query ) ; \
completion_charp = addon ; \
matches = completion_matches ( text , complete_from_schema_query ) ; \
} while ( 0 )
2012-02-01 19:16:40 +01:00
# define COMPLETE_WITH_LIST_CS(list) \
do { \
completion_charpp = list ; \
completion_case_sensitive = true ; \
matches = completion_matches ( text , complete_from_list ) ; \
} while ( 0 )
2003-10-30 22:37:38 +01:00
# define COMPLETE_WITH_LIST(list) \
2008-03-29 20:19:14 +01:00
do { \
completion_charpp = list ; \
2012-02-01 19:16:40 +01:00
completion_case_sensitive = false ; \
2008-03-29 20:19:14 +01:00
matches = completion_matches ( text , complete_from_list ) ; \
} while ( 0 )
2003-10-30 22:37:38 +01:00
# define COMPLETE_WITH_CONST(string) \
2008-03-29 20:19:14 +01:00
do { \
completion_charp = string ; \
2012-02-01 19:16:40 +01:00
completion_case_sensitive = false ; \
2008-03-29 20:19:14 +01:00
matches = completion_matches ( text , complete_from_const ) ; \
} while ( 0 )
# define COMPLETE_WITH_ATTR(relation, addon) \
do { \
char * _completion_schema ; \
char * _completion_table ; \
\
_completion_schema = strtokx ( relation , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
( void ) strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
_completion_table = strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
if ( _completion_table = = NULL ) \
{ \
completion_charp = Query_for_list_of_attributes addon ; \
completion_info_charp = relation ; \
} \
else \
{ \
completion_charp = Query_for_list_of_attributes_with_schema addon ; \
completion_info_charp = _completion_table ; \
completion_info_charp2 = _completion_schema ; \
} \
matches = completion_matches ( text , complete_from_query ) ; \
} while ( 0 )
2003-10-15 00:47:12 +02:00
2016-11-08 22:27:09 +01:00
# define COMPLETE_WITH_ENUM_VALUE(type) \
do { \
char * _completion_schema ; \
char * _completion_type ; \
\
_completion_schema = strtokx ( type , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
( void ) strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
_completion_type = strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
if ( _completion_type = = NULL ) \
{ \
completion_charp = Query_for_list_of_enum_values ; \
completion_info_charp = type ; \
} \
else \
{ \
completion_charp = Query_for_list_of_enum_values_with_schema ; \
completion_info_charp = _completion_type ; \
completion_info_charp2 = _completion_schema ; \
} \
matches = completion_matches ( text , complete_from_query ) ; \
} while ( 0 )
2012-07-05 14:03:49 +02:00
# define COMPLETE_WITH_FUNCTION_ARG(function) \
do { \
char * _completion_schema ; \
char * _completion_function ; \
\
_completion_schema = strtokx ( function , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
( void ) strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
_completion_function = strtokx ( NULL , " \t \n \r " , " . " , " \" " , 0 , \
false , false , pset . encoding ) ; \
if ( _completion_function = = NULL ) \
{ \
completion_charp = Query_for_list_of_arguments ; \
completion_info_charp = function ; \
} \
else \
{ \
completion_charp = Query_for_list_of_arguments_with_schema ; \
completion_info_charp = _completion_function ; \
completion_info_charp2 = _completion_schema ; \
} \
matches = completion_matches ( text , complete_from_query ) ; \
} while ( 0 )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/*
* These macros simplify use of COMPLETE_WITH_LIST for short , fixed lists .
* There is no COMPLETE_WITH_LIST1 ; use COMPLETE_WITH_CONST for that case .
*/
# define COMPLETE_WITH_LIST2(s1, s2) \
do { \
static const char * const list [ ] = { s1 , s2 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST3(s1, s2, s3) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST4(s1, s2, s3, s4) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST5(s1, s2, s3, s4, s5) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST6(s1, s2, s3, s4, s5, s6) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , s6 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST7(s1, s2, s3, s4, s5, s6, s7) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , s6 , s7 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST8(s1, s2, s3, s4, s5, s6, s7, s8) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , s6 , s7 , s8 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST9(s1, s2, s3, s4, s5, s6, s7, s8, s9) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , s6 , s7 , s8 , s9 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST10(s1, s2, s3, s4, s5, s6, s7, s8, s9, s10) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , s6 , s7 , s8 , s9 , s10 , NULL } ; \
COMPLETE_WITH_LIST ( list ) ; \
} while ( 0 )
2016-01-05 18:00:13 +01:00
/*
* Likewise for COMPLETE_WITH_LIST_CS .
*/
# define COMPLETE_WITH_LIST_CS2(s1, s2) \
do { \
static const char * const list [ ] = { s1 , s2 , NULL } ; \
COMPLETE_WITH_LIST_CS ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST_CS3(s1, s2, s3) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , NULL } ; \
COMPLETE_WITH_LIST_CS ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST_CS4(s1, s2, s3, s4) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , NULL } ; \
COMPLETE_WITH_LIST_CS ( list ) ; \
} while ( 0 )
# define COMPLETE_WITH_LIST_CS5(s1, s2, s3, s4, s5) \
do { \
static const char * const list [ ] = { s1 , s2 , s3 , s4 , s5 , NULL } ; \
COMPLETE_WITH_LIST_CS ( list ) ; \
} while ( 0 )
2003-10-30 22:37:38 +01:00
/*
* Assembly instructions for schema queries
*/
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_aggregates = {
/* catname */
" pg_catalog.pg_proc p " ,
/* selcondition */
" p.proisagg " ,
/* viscondition */
" pg_catalog.pg_function_is_visible(p.oid) " ,
/* namespace */
" p.pronamespace " ,
/* result */
" pg_catalog.quote_ident(p.proname) " ,
/* qualresult */
NULL
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_datatypes = {
/* catname */
" pg_catalog.pg_type t " ,
/* selcondition --- ignore table rowtypes and array types */
" (t.typrelid = 0 "
2017-03-10 04:42:16 +01:00
" OR (SELECT c.relkind = " CppAsString2 ( RELKIND_COMPOSITE_TYPE )
" FROM pg_catalog.pg_class c WHERE c.oid = t.typrelid)) "
2003-10-30 22:37:38 +01:00
" AND t.typname !~ '^_' " ,
/* viscondition */
" pg_catalog.pg_type_is_visible(t.oid) " ,
/* namespace */
" t.typnamespace " ,
/* result */
" pg_catalog.format_type(t.oid, NULL) " ,
/* qualresult */
" pg_catalog.quote_ident(t.typname) "
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_domains = {
/* catname */
" pg_catalog.pg_type t " ,
/* selcondition */
" t.typtype = 'd' " ,
/* viscondition */
" pg_catalog.pg_type_is_visible(t.oid) " ,
/* namespace */
" t.typnamespace " ,
/* result */
" pg_catalog.quote_ident(t.typname) " ,
/* qualresult */
NULL
} ;
2000-04-12 19:17:23 +02:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_functions = {
/* catname */
" pg_catalog.pg_proc p " ,
/* selcondition */
NULL ,
/* viscondition */
" pg_catalog.pg_function_is_visible(p.oid) " ,
/* namespace */
" p.pronamespace " ,
/* result */
" pg_catalog.quote_ident(p.proname) " ,
/* qualresult */
NULL
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_indexes = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_INDEX ) " ) " ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_sequences = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_SEQUENCE ) " ) " ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2011-01-02 05:48:11 +01:00
static const SchemaQuery Query_for_list_of_foreign_tables = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_FOREIGN_TABLE ) " ) " ,
2011-01-02 05:48:11 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_tables = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_RELATION ) " , "
CppAsString2 ( RELKIND_PARTITIONED_TABLE ) " ) " ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2017-02-26 18:20:00 +01:00
static const SchemaQuery Query_for_list_of_partitioned_tables = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_PARTITIONED_TABLE ) " ) " ,
2017-02-26 18:20:00 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2012-09-15 04:11:17 +02:00
static const SchemaQuery Query_for_list_of_constraints_with_schema = {
/* catname */
" pg_catalog.pg_constraint c " ,
/* selcondition */
" c.conrelid <> 0 " ,
/* viscondition */
2013-05-29 22:58:43 +02:00
" true " , /* there is no pg_constraint_is_visible */
2012-09-15 04:11:17 +02:00
/* namespace */
" c.connamespace " ,
/* result */
" pg_catalog.quote_ident(c.conname) " ,
/* qualresult */
NULL
} ;
2013-10-23 19:16:25 +02:00
/* Relations supporting INSERT, UPDATE or DELETE */
2010-12-14 04:37:55 +01:00
static const SchemaQuery Query_for_list_of_updatables = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_RELATION ) " , "
CppAsString2 ( RELKIND_FOREIGN_TABLE ) " , "
CppAsString2 ( RELKIND_VIEW ) " , "
CppAsString2 ( RELKIND_PARTITIONED_TABLE ) " ) " ,
2010-12-14 04:37:55 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2011-06-14 22:45:00 +02:00
static const SchemaQuery Query_for_list_of_relations = {
2003-10-30 22:37:38 +01:00
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2011-06-14 22:45:00 +02:00
NULL ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2013-03-04 01:23:31 +01:00
static const SchemaQuery Query_for_list_of_tsvmf = {
2003-10-30 22:37:38 +01:00
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_RELATION ) " , "
CppAsString2 ( RELKIND_SEQUENCE ) " , "
CppAsString2 ( RELKIND_VIEW ) " , "
CppAsString2 ( RELKIND_MATVIEW ) " , "
CppAsString2 ( RELKIND_FOREIGN_TABLE ) " , "
CppAsString2 ( RELKIND_PARTITIONED_TABLE ) " ) " ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2013-03-04 01:23:31 +01:00
static const SchemaQuery Query_for_list_of_tmf = {
2012-04-06 21:02:35 +02:00
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_RELATION ) " , "
CppAsString2 ( RELKIND_MATVIEW ) " , "
CppAsString2 ( RELKIND_FOREIGN_TABLE ) " ) " ,
2013-03-04 01:23:31 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
static const SchemaQuery Query_for_list_of_tm = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_RELATION ) " , "
CppAsString2 ( RELKIND_MATVIEW ) " ) " ,
2012-04-06 21:02:35 +02:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
2003-10-30 22:37:38 +01:00
static const SchemaQuery Query_for_list_of_views = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_VIEW ) " ) " ,
2003-10-30 22:37:38 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2013-03-04 01:23:31 +01:00
static const SchemaQuery Query_for_list_of_matviews = {
/* catname */
" pg_catalog.pg_class c " ,
/* selcondition */
2017-03-10 04:42:16 +01:00
" c.relkind IN ( " CppAsString2 ( RELKIND_MATVIEW ) " ) " ,
2013-03-04 01:23:31 +01:00
/* viscondition */
" pg_catalog.pg_table_is_visible(c.oid) " ,
/* namespace */
" c.relnamespace " ,
/* result */
" pg_catalog.quote_ident(c.relname) " ,
/* qualresult */
NULL
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2002-08-10 05:56:24 +02:00
/*
* Queries to get lists of names of various kinds of things , possibly
* restricted to names matching a partially entered name . In these queries ,
2008-03-29 20:19:14 +01:00
* the first % s will be replaced by the text entered so far ( suitably escaped
* to become a SQL literal string ) . % d will be replaced by the length of the
2014-05-06 18:12:18 +02:00
* string ( in unescaped form ) . A second and third % s , if present , will be
2008-03-29 20:19:14 +01:00
* replaced by a suitably - escaped version of the string provided in
* completion_info_charp . A fourth and fifth % s are similarly replaced by
* completion_info_charp2 .
2003-10-30 22:37:38 +01:00
*
* Beware that the allowed sequences of % s and % d are determined by
* _complete_from_query ( ) .
2002-08-10 05:56:24 +02:00
*/
2003-03-27 17:45:01 +01:00
# define Query_for_list_of_attributes \
2003-10-16 22:03:09 +02:00
" SELECT pg_catalog.quote_ident(attname) " \
" FROM pg_catalog.pg_attribute a, pg_catalog.pg_class c " \
2003-03-27 17:45:01 +01:00
" WHERE c.oid = a.attrelid " \
" AND a.attnum > 0 " \
" AND NOT a.attisdropped " \
2003-10-16 22:03:09 +02:00
" AND substring(pg_catalog.quote_ident(attname),1,%d)='%s' " \
2008-03-29 20:19:14 +01:00
" AND (pg_catalog.quote_ident(relname)='%s' " \
" OR ' \" ' || relname || ' \" '='%s') " \
2003-03-27 17:45:01 +01:00
" AND pg_catalog.pg_table_is_visible(c.oid) "
2008-03-29 20:19:14 +01:00
# define Query_for_list_of_attributes_with_schema \
" SELECT pg_catalog.quote_ident(attname) " \
" FROM pg_catalog.pg_attribute a, pg_catalog.pg_class c, pg_catalog.pg_namespace n " \
" WHERE c.oid = a.attrelid " \
" AND n.oid = c.relnamespace " \
" AND a.attnum > 0 " \
" AND NOT a.attisdropped " \
" AND substring(pg_catalog.quote_ident(attname),1,%d)='%s' " \
" AND (pg_catalog.quote_ident(relname)='%s' " \
" OR ' \" ' || relname || ' \" ' ='%s') " \
" AND (pg_catalog.quote_ident(nspname)='%s' " \
" OR ' \" ' || nspname || ' \" ' ='%s') "
2016-11-08 22:27:09 +01:00
# define Query_for_list_of_enum_values \
" SELECT pg_catalog.quote_literal(enumlabel) " \
" FROM pg_catalog.pg_enum e, pg_catalog.pg_type t " \
" WHERE t.oid = e.enumtypid " \
" AND substring(pg_catalog.quote_literal(enumlabel),1,%d)='%s' " \
" AND (pg_catalog.quote_ident(typname)='%s' " \
" OR ' \" ' || typname || ' \" '='%s') " \
" AND pg_catalog.pg_type_is_visible(t.oid) "
# define Query_for_list_of_enum_values_with_schema \
" SELECT pg_catalog.quote_literal(enumlabel) " \
" FROM pg_catalog.pg_enum e, pg_catalog.pg_type t, pg_catalog.pg_namespace n " \
" WHERE t.oid = e.enumtypid " \
" AND n.oid = t.typnamespace " \
" AND substring(pg_catalog.quote_literal(enumlabel),1,%d)='%s' " \
" AND (pg_catalog.quote_ident(typname)='%s' " \
" OR ' \" ' || typname || ' \" '='%s') " \
" AND (pg_catalog.quote_ident(nspname)='%s' " \
" OR ' \" ' || nspname || ' \" ' ='%s') "
2007-09-14 06:25:24 +02:00
# define Query_for_list_of_template_databases \
2016-09-11 22:37:27 +02:00
" SELECT pg_catalog.quote_ident(d.datname) " \
" FROM pg_catalog.pg_database d " \
" WHERE substring(pg_catalog.quote_ident(d.datname),1,%d)='%s' " \
2016-09-12 16:22:57 +02:00
" AND (d.datistemplate OR pg_catalog.pg_has_role(d.datdba, 'USAGE')) "
2007-09-14 06:25:24 +02:00
2003-03-27 17:45:01 +01:00
# define Query_for_list_of_databases \
2003-10-16 22:03:09 +02:00
" SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database " \
" WHERE substring(pg_catalog.quote_ident(datname),1,%d)='%s' "
2003-03-27 17:45:01 +01:00
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
# define Query_for_list_of_tablespaces \
" SELECT pg_catalog.quote_ident(spcname) FROM pg_catalog.pg_tablespace " \
" WHERE substring(pg_catalog.quote_ident(spcname),1,%d)='%s' "
2003-06-12 03:38:08 +02:00
# define Query_for_list_of_encodings \
" SELECT DISTINCT pg_catalog.pg_encoding_to_char(conforencoding) " \
" FROM pg_catalog.pg_conversion " \
2003-10-16 22:03:09 +02:00
" WHERE substring(pg_catalog.pg_encoding_to_char(conforencoding),1,%d)=UPPER('%s') "
2003-06-12 03:38:08 +02:00
2003-03-27 17:45:01 +01:00
# define Query_for_list_of_languages \
2003-10-16 22:03:09 +02:00
" SELECT pg_catalog.quote_ident(lanname) " \
2010-01-02 22:28:46 +01:00
" FROM pg_catalog.pg_language " \
2003-03-27 17:45:01 +01:00
" WHERE lanname != 'internal' " \
2010-01-02 22:28:46 +01:00
" AND substring(pg_catalog.quote_ident(lanname),1,%d)='%s' "
2003-03-27 17:45:01 +01:00
# define Query_for_list_of_schemas \
2003-10-16 22:03:09 +02:00
" SELECT pg_catalog.quote_ident(nspname) FROM pg_catalog.pg_namespace " \
" WHERE substring(pg_catalog.quote_ident(nspname),1,%d)='%s' "
2003-03-27 17:45:01 +01:00
2013-12-19 18:33:27 +01:00
# define Query_for_list_of_alter_system_set_vars \
" SELECT name FROM " \
" (SELECT pg_catalog.lower(name) AS name FROM pg_catalog.pg_settings " \
2017-02-15 21:23:19 +01:00
" WHERE context != 'internal' " \
" UNION ALL SELECT 'all') ss " \
" WHERE substring(name,1,%d)='%s' "
2013-12-19 18:33:27 +01:00
2005-08-14 20:49:30 +02:00
# define Query_for_list_of_set_vars \
" SELECT name FROM " \
" (SELECT pg_catalog.lower(name) AS name FROM pg_catalog.pg_settings " \
" WHERE context IN ('user', 'superuser') " \
" UNION ALL SELECT 'constraints' " \
" UNION ALL SELECT 'transaction' " \
" UNION ALL SELECT 'session' " \
" UNION ALL SELECT 'role' " \
2008-11-07 19:25:07 +01:00
" UNION ALL SELECT 'tablespace' " \
2005-08-14 20:49:30 +02:00
" UNION ALL SELECT 'all') ss " \
" WHERE substring(name,1,%d)='%s' "
# define Query_for_list_of_show_vars \
" SELECT name FROM " \
" (SELECT pg_catalog.lower(name) AS name FROM pg_catalog.pg_settings " \
" UNION ALL SELECT 'session authorization' " \
" UNION ALL SELECT 'all') ss " \
" WHERE substring(name,1,%d)='%s' "
# define Query_for_list_of_roles \
" SELECT pg_catalog.quote_ident(rolname) " \
" FROM pg_catalog.pg_roles " \
" WHERE substring(pg_catalog.quote_ident(rolname),1,%d)='%s' "
2002-08-10 05:56:24 +02:00
2005-08-14 20:49:30 +02:00
# define Query_for_list_of_grant_roles \
" SELECT pg_catalog.quote_ident(rolname) " \
" FROM pg_catalog.pg_roles " \
" WHERE substring(pg_catalog.quote_ident(rolname),1,%d)='%s' " \
2015-09-08 18:58:29 +02:00
" UNION ALL SELECT 'PUBLIC' " \
" UNION ALL SELECT 'CURRENT_USER' " \
" UNION ALL SELECT 'SESSION_USER' "
2005-05-18 06:47:40 +02:00
2003-10-15 00:47:12 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_table_owning_index \
2003-10-16 22:03:09 +02:00
" SELECT pg_catalog.quote_ident(c1.relname) " \
2003-10-15 00:47:12 +02:00
" FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2, pg_catalog.pg_index i " \
" WHERE c1.oid=i.indrelid and i.indexrelid=c2.oid " \
2007-06-14 01:59:47 +02:00
" and (%d = pg_catalog.length('%s')) " \
2003-10-16 22:03:09 +02:00
" and pg_catalog.quote_ident(c2.relname)='%s' " \
2003-10-15 00:47:12 +02:00
" and pg_catalog.pg_table_is_visible(c2.oid) "
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_index_of_table \
" SELECT pg_catalog.quote_ident(c2.relname) " \
" FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2, pg_catalog.pg_index i " \
" WHERE c1.oid=i.indrelid and i.indexrelid=c2.oid " \
2007-06-14 01:59:47 +02:00
" and (%d = pg_catalog.length('%s')) " \
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
" and pg_catalog.quote_ident(c1.relname)='%s' " \
" and pg_catalog.pg_table_is_visible(c2.oid) "
2012-08-20 22:30:08 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_constraint_of_table \
" SELECT pg_catalog.quote_ident(conname) " \
" FROM pg_catalog.pg_class c1, pg_catalog.pg_constraint con " \
" WHERE c1.oid=conrelid and (%d = pg_catalog.length('%s')) " \
" and pg_catalog.quote_ident(c1.relname)='%s' " \
" and pg_catalog.pg_table_is_visible(c1.oid) "
2012-09-15 04:11:17 +02:00
# define Query_for_all_table_constraints \
" SELECT pg_catalog.quote_ident(conname) " \
" FROM pg_catalog.pg_constraint c " \
" WHERE c.conrelid <> 0 "
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_constraint_of_type \
" SELECT pg_catalog.quote_ident(conname) " \
" FROM pg_catalog.pg_type t, pg_catalog.pg_constraint con " \
" WHERE t.oid=contypid and (%d = pg_catalog.length('%s')) " \
" and pg_catalog.quote_ident(t.typname)='%s' " \
" and pg_catalog.pg_type_is_visible(t.oid) "
/* the silly-looking length condition is just to eat up the current word */
2013-05-29 22:58:43 +02:00
# define Query_for_list_of_tables_for_constraint \
2012-09-15 04:11:17 +02:00
" SELECT pg_catalog.quote_ident(relname) " \
" FROM pg_catalog.pg_class " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND oid IN " \
" (SELECT conrelid FROM pg_catalog.pg_constraint " \
" WHERE pg_catalog.quote_ident(conname)='%s') "
2014-06-23 22:47:39 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_rule_of_table \
" SELECT pg_catalog.quote_ident(rulename) " \
" FROM pg_catalog.pg_class c1, pg_catalog.pg_rewrite " \
" WHERE c1.oid=ev_class and (%d = pg_catalog.length('%s')) " \
" and pg_catalog.quote_ident(c1.relname)='%s' " \
" and pg_catalog.pg_table_is_visible(c1.oid) "
2013-02-09 05:58:40 +01:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_list_of_tables_for_rule \
" SELECT pg_catalog.quote_ident(relname) " \
" FROM pg_catalog.pg_class " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND oid IN " \
" (SELECT ev_class FROM pg_catalog.pg_rewrite " \
" WHERE pg_catalog.quote_ident(rulename)='%s') "
2014-06-23 22:47:39 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_trigger_of_table \
" SELECT pg_catalog.quote_ident(tgname) " \
" FROM pg_catalog.pg_class c1, pg_catalog.pg_trigger " \
" WHERE c1.oid=tgrelid and (%d = pg_catalog.length('%s')) " \
" and pg_catalog.quote_ident(c1.relname)='%s' " \
" and pg_catalog.pg_table_is_visible(c1.oid) " \
" and not tgisinternal "
2004-09-22 06:25:16 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_list_of_tables_for_trigger \
" SELECT pg_catalog.quote_ident(relname) " \
" FROM pg_catalog.pg_class " \
2007-06-14 01:59:47 +02:00
" WHERE (%d = pg_catalog.length('%s')) " \
2004-09-22 06:25:16 +02:00
" AND oid IN " \
" (SELECT tgrelid FROM pg_catalog.pg_trigger " \
" WHERE pg_catalog.quote_ident(tgname)='%s') "
2007-09-14 06:25:24 +02:00
# define Query_for_list_of_ts_configurations \
" SELECT pg_catalog.quote_ident(cfgname) FROM pg_catalog.pg_ts_config " \
" WHERE substring(pg_catalog.quote_ident(cfgname),1,%d)='%s' "
# define Query_for_list_of_ts_dictionaries \
" SELECT pg_catalog.quote_ident(dictname) FROM pg_catalog.pg_ts_dict " \
" WHERE substring(pg_catalog.quote_ident(dictname),1,%d)='%s' "
# define Query_for_list_of_ts_parsers \
" SELECT pg_catalog.quote_ident(prsname) FROM pg_catalog.pg_ts_parser " \
" WHERE substring(pg_catalog.quote_ident(prsname),1,%d)='%s' "
# define Query_for_list_of_ts_templates \
" SELECT pg_catalog.quote_ident(tmplname) FROM pg_catalog.pg_ts_template " \
" WHERE substring(pg_catalog.quote_ident(tmplname),1,%d)='%s' "
2008-12-19 17:25:19 +01:00
# define Query_for_list_of_fdws \
" SELECT pg_catalog.quote_ident(fdwname) " \
" FROM pg_catalog.pg_foreign_data_wrapper " \
" WHERE substring(pg_catalog.quote_ident(fdwname),1,%d)='%s' "
# define Query_for_list_of_servers \
" SELECT pg_catalog.quote_ident(srvname) " \
" FROM pg_catalog.pg_foreign_server " \
" WHERE substring(pg_catalog.quote_ident(srvname),1,%d)='%s' "
# define Query_for_list_of_user_mappings \
" SELECT pg_catalog.quote_ident(usename) " \
" FROM pg_catalog.pg_user_mappings " \
" WHERE substring(pg_catalog.quote_ident(usename),1,%d)='%s' "
2010-02-17 05:09:40 +01:00
# define Query_for_list_of_access_methods \
" SELECT pg_catalog.quote_ident(amname) " \
" FROM pg_catalog.pg_am " \
" WHERE substring(pg_catalog.quote_ident(amname),1,%d)='%s' "
2017-03-03 20:13:48 +01:00
# define Query_for_list_of_publications \
" SELECT pg_catalog.quote_ident(pubname) " \
" FROM pg_catalog.pg_publication " \
" WHERE substring(pg_catalog.quote_ident(pubname),1,%d)='%s' "
# define Query_for_list_of_subscriptions \
" SELECT pg_catalog.quote_ident(s.subname) " \
" FROM pg_catalog.pg_subscription s, pg_catalog.pg_database d " \
" WHERE substring(pg_catalog.quote_ident(s.subname),1,%d)='%s' " \
" AND d.datname = pg_catalog.current_database() " \
" AND s.subdbid = d.oid "
2012-07-05 14:03:49 +02:00
/* the silly-looking length condition is just to eat up the current word */
2010-04-05 07:33:24 +02:00
# define Query_for_list_of_arguments \
2012-07-05 14:03:49 +02:00
" SELECT pg_catalog.oidvectortypes(proargtypes)||')' " \
" FROM pg_catalog.pg_proc " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND (pg_catalog.quote_ident(proname)='%s' " \
" OR ' \" ' || proname || ' \" '='%s') " \
" AND (pg_catalog.pg_function_is_visible(pg_proc.oid)) "
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_list_of_arguments_with_schema \
" SELECT pg_catalog.oidvectortypes(proargtypes)||')' " \
" FROM pg_catalog.pg_proc p, pg_catalog.pg_namespace n " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND n.oid = p.pronamespace " \
" AND (pg_catalog.quote_ident(proname)='%s' " \
" OR ' \" ' || proname || ' \" ' ='%s') " \
" AND (pg_catalog.quote_ident(nspname)='%s' " \
" OR ' \" ' || nspname || ' \" ' ='%s') "
2010-04-05 07:33:24 +02:00
2011-02-08 22:08:41 +01:00
# define Query_for_list_of_extensions \
" SELECT pg_catalog.quote_ident(extname) " \
" FROM pg_catalog.pg_extension " \
" WHERE substring(pg_catalog.quote_ident(extname),1,%d)='%s' "
# define Query_for_list_of_available_extensions \
" SELECT pg_catalog.quote_ident(name) " \
" FROM pg_catalog.pg_available_extensions " \
2011-02-14 22:07:00 +01:00
" WHERE substring(pg_catalog.quote_ident(name),1,%d)='%s' AND installed_version IS NULL "
2011-02-08 22:08:41 +01:00
2015-10-20 16:27:20 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_list_of_available_extension_versions \
" SELECT pg_catalog.quote_ident(version) " \
" FROM pg_catalog.pg_available_extension_versions " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND pg_catalog.quote_ident(name)='%s' "
2016-08-18 17:17:10 +02:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_list_of_available_extension_versions_with_TO \
" SELECT 'TO ' || pg_catalog.quote_ident(version) " \
" FROM pg_catalog.pg_available_extension_versions " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND pg_catalog.quote_ident(name)='%s' "
2011-10-24 01:25:34 +02:00
# define Query_for_list_of_prepared_statements \
" SELECT pg_catalog.quote_ident(name) " \
" FROM pg_catalog.pg_prepared_statements " \
" WHERE substring(pg_catalog.quote_ident(name),1,%d)='%s' "
2014-04-14 14:44:21 +02:00
# define Query_for_list_of_event_triggers \
" SELECT pg_catalog.quote_ident(evtname) " \
" FROM pg_catalog.pg_event_trigger " \
" WHERE substring(pg_catalog.quote_ident(evtname),1,%d)='%s' "
2015-06-22 20:13:56 +02:00
# define Query_for_list_of_tablesample_methods \
Redesign tablesample method API, and do extensive code review.
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.
2015-07-25 20:39:00 +02:00
" SELECT pg_catalog.quote_ident(proname) " \
" FROM pg_catalog.pg_proc " \
" WHERE prorettype = 'pg_catalog.tsm_handler'::pg_catalog.regtype AND " \
" proargtypes[0] = 'pg_catalog.internal'::pg_catalog.regtype AND " \
" substring(pg_catalog.quote_ident(proname),1,%d)='%s' "
2015-06-22 20:13:56 +02:00
2015-07-20 15:37:17 +02:00
# define Query_for_list_of_policies \
" SELECT pg_catalog.quote_ident(polname) " \
Redesign tablesample method API, and do extensive code review.
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.
2015-07-25 20:39:00 +02:00
" FROM pg_catalog.pg_policy " \
2015-07-20 15:37:17 +02:00
" WHERE substring(pg_catalog.quote_ident(polname),1,%d)='%s' "
# define Query_for_list_of_tables_for_policy \
" SELECT pg_catalog.quote_ident(relname) " \
" FROM pg_catalog.pg_class " \
" WHERE (%d = pg_catalog.length('%s')) " \
" AND oid IN " \
" (SELECT polrelid FROM pg_catalog.pg_policy " \
" WHERE pg_catalog.quote_ident(polname)='%s') "
2015-09-08 20:57:35 +02:00
# define Query_for_enum \
" SELECT name FROM ( " \
" SELECT pg_catalog.quote_ident(pg_catalog.unnest(enumvals)) AS name " \
" FROM pg_catalog.pg_settings " \
" WHERE pg_catalog.lower(name)=pg_catalog.lower('%s') " \
" UNION ALL " \
" SELECT 'DEFAULT' ) ss " \
" WHERE pg_catalog.substring(name,1,%%d)='%%s' "
2017-02-26 18:20:00 +01:00
/* the silly-looking length condition is just to eat up the current word */
# define Query_for_partition_of_table \
" SELECT pg_catalog.quote_ident(c2.relname) " \
" FROM pg_catalog.pg_class c1, pg_catalog.pg_class c2, pg_catalog.pg_inherits i " \
" WHERE c1.oid=i.inhparent and i.inhrelid=c2.oid " \
" and (%d = pg_catalog.length('%s')) " \
" and pg_catalog.quote_ident(c1.relname)='%s' " \
" and pg_catalog.pg_table_is_visible(c2.oid) " \
" and c2.relispartition = 'true' "
2003-10-30 22:37:38 +01:00
/*
* This is a list of all " things " in Pgsql , which can show up after CREATE or
* DROP ; and there is also a query to get a list of them .
*/
2003-03-27 17:45:01 +01:00
2000-04-12 19:17:23 +02:00
typedef struct
{
2003-10-30 22:37:38 +01:00
const char * name ;
const char * query ; /* simple query, or NULL */
const SchemaQuery * squery ; /* schema query, or NULL */
2011-02-24 02:13:27 +01:00
const bits32 flags ; /* visibility flags, see below */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
} pgsql_thing_t ;
2011-02-24 02:13:27 +01:00
# define THING_NO_CREATE (1 << 0) /* should not show up after CREATE */
# define THING_NO_DROP (1 << 1) /* should not show up after DROP */
2017-03-16 23:54:28 +01:00
# define THING_NO_ALTER (1 << 2) /* should not show up after ALTER */
# define THING_NO_SHOW (THING_NO_CREATE | THING_NO_DROP | THING_NO_ALTER)
2011-02-24 02:13:27 +01:00
2003-10-30 22:37:38 +01:00
static const pgsql_thing_t words_after_create [ ] = {
2017-03-16 23:54:28 +01:00
{ " ACCESS METHOD " , NULL , NULL , THING_NO_ALTER } ,
2003-10-30 22:37:38 +01:00
{ " AGGREGATE " , NULL , & Query_for_list_of_aggregates } ,
2005-10-15 04:49:52 +02:00
{ " CAST " , NULL , NULL } , /* Casts have complex structures for names, so
* skip it */
2011-03-11 19:20:11 +01:00
{ " COLLATION " , " SELECT pg_catalog.quote_ident(collname) FROM pg_catalog.pg_collation WHERE collencoding IN (-1, pg_catalog.pg_char_to_encoding(pg_catalog.getdatabaseencoding())) AND substring(pg_catalog.quote_ident(collname),1,%d)='%s' " } ,
2005-10-15 04:49:52 +02:00
/*
* CREATE CONSTRAINT TRIGGER is not supported here because it is designed
* to be used only by pg_dump .
*/
2011-02-24 02:13:27 +01:00
{ " CONFIGURATION " , Query_for_list_of_ts_configurations , NULL , THING_NO_SHOW } ,
2003-10-30 22:37:38 +01:00
{ " CONVERSION " , " SELECT pg_catalog.quote_ident(conname) FROM pg_catalog.pg_conversion WHERE substring(pg_catalog.quote_ident(conname),1,%d)='%s' " } ,
{ " DATABASE " , Query_for_list_of_databases } ,
2011-02-24 02:13:27 +01:00
{ " DICTIONARY " , Query_for_list_of_ts_dictionaries , NULL , THING_NO_SHOW } ,
2017-03-16 23:54:28 +01:00
{ " DEFAULT PRIVILEGES " , NULL , NULL , THING_NO_CREATE | THING_NO_DROP } ,
2003-10-30 22:37:38 +01:00
{ " DOMAIN " , NULL , & Query_for_list_of_domains } ,
2014-04-14 14:44:21 +02:00
{ " EVENT TRIGGER " , NULL , NULL } ,
2011-02-08 22:08:41 +01:00
{ " EXTENSION " , Query_for_list_of_extensions } ,
2008-12-19 17:25:19 +01:00
{ " FOREIGN DATA WRAPPER " , NULL , NULL } ,
2011-01-02 05:48:11 +01:00
{ " FOREIGN TABLE " , NULL , NULL } ,
2003-10-30 22:37:38 +01:00
{ " FUNCTION " , NULL , & Query_for_list_of_functions } ,
2005-08-14 20:49:30 +02:00
{ " GROUP " , Query_for_list_of_roles } ,
2003-10-30 22:37:38 +01:00
{ " INDEX " , NULL , & Query_for_list_of_indexes } ,
2017-03-16 23:54:28 +01:00
{ " LANGUAGE " , Query_for_list_of_languages } ,
{ " LARGE OBJECT " , NULL , NULL , THING_NO_CREATE | THING_NO_DROP } ,
2016-01-26 15:45:08 +01:00
{ " MATERIALIZED VIEW " , NULL , & Query_for_list_of_matviews } ,
2005-10-15 04:49:52 +02:00
{ " OPERATOR " , NULL , NULL } , /* Querying for this is probably not such a
* good idea . */
2017-03-16 23:54:28 +01:00
{ " OWNED " , NULL , NULL , THING_NO_CREATE | THING_NO_ALTER } , /* for DROP OWNED BY ... */
2011-02-24 02:13:27 +01:00
{ " PARSER " , Query_for_list_of_ts_parsers , NULL , THING_NO_SHOW } ,
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
{ " POLICY " , NULL , NULL } ,
2017-03-03 20:13:48 +01:00
{ " PUBLICATION " , Query_for_list_of_publications } ,
2005-08-14 20:49:30 +02:00
{ " ROLE " , Query_for_list_of_roles } ,
2003-10-30 22:37:38 +01:00
{ " RULE " , " SELECT pg_catalog.quote_ident(rulename) FROM pg_catalog.pg_rules WHERE substring(pg_catalog.quote_ident(rulename),1,%d)='%s' " } ,
{ " SCHEMA " , Query_for_list_of_schemas } ,
{ " SEQUENCE " , NULL , & Query_for_list_of_sequences } ,
2008-12-19 17:25:19 +01:00
{ " SERVER " , Query_for_list_of_servers } ,
2017-03-03 20:13:48 +01:00
{ " SUBSCRIPTION " , Query_for_list_of_subscriptions } ,
2017-03-16 23:54:28 +01:00
{ " SYSTEM " , NULL , NULL , THING_NO_CREATE | THING_NO_DROP } ,
2003-10-30 22:37:38 +01:00
{ " TABLE " , NULL , & Query_for_list_of_tables } ,
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
{ " TABLESPACE " , Query_for_list_of_tablespaces } ,
2017-03-16 23:54:28 +01:00
{ " TEMP " , NULL , NULL , THING_NO_DROP | THING_NO_ALTER } , /* for CREATE TEMP TABLE ... */
2011-02-24 02:13:27 +01:00
{ " TEMPLATE " , Query_for_list_of_ts_templates , NULL , THING_NO_SHOW } ,
2017-03-16 23:54:28 +01:00
{ " TEMPORARY " , NULL , NULL , THING_NO_DROP | THING_NO_ALTER } , /* for CREATE TEMPORARY TABLE ... */
2007-09-14 06:25:24 +02:00
{ " TEXT SEARCH " , NULL , NULL } ,
2017-03-16 23:54:28 +01:00
{ " TRANSFORM " , NULL , NULL } ,
2014-06-23 22:47:39 +02:00
{ " TRIGGER " , " SELECT pg_catalog.quote_ident(tgname) FROM pg_catalog.pg_trigger WHERE substring(pg_catalog.quote_ident(tgname),1,%d)='%s' AND NOT tgisinternal " } ,
2003-10-30 22:37:38 +01:00
{ " TYPE " , NULL , & Query_for_list_of_datatypes } ,
2017-03-16 23:54:28 +01:00
{ " UNIQUE " , NULL , NULL , THING_NO_DROP | THING_NO_ALTER } , /* for CREATE UNIQUE INDEX ... */
{ " UNLOGGED " , NULL , NULL , THING_NO_DROP | THING_NO_ALTER } , /* for CREATE UNLOGGED TABLE
2011-04-10 17:42:00 +02:00
* . . . */
2005-08-14 20:49:30 +02:00
{ " USER " , Query_for_list_of_roles } ,
2008-12-19 17:25:19 +01:00
{ " USER MAPPING FOR " , NULL , NULL } ,
2003-10-30 22:37:38 +01:00
{ " VIEW " , NULL , & Query_for_list_of_views } ,
2011-04-10 17:42:00 +02:00
{ NULL } /* end of list */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
} ;
2003-10-30 22:37:38 +01:00
/* Forward declaration of functions */
2014-04-04 17:26:01 +02:00
static char * * psql_completion ( const char * text , int start , int end ) ;
2003-10-30 22:37:38 +01:00
static char * create_command_generator ( const char * text , int state ) ;
2006-04-02 11:02:41 +02:00
static char * drop_command_generator ( const char * text , int state ) ;
2017-03-16 23:54:28 +01:00
static char * alter_command_generator ( const char * text , int state ) ;
2003-10-30 22:37:38 +01:00
static char * complete_from_query ( const char * text , int state ) ;
static char * complete_from_schema_query ( const char * text , int state ) ;
static char * _complete_from_query ( int is_schema_query ,
const char * text , int state ) ;
static char * complete_from_list ( const char * text , int state ) ;
2010-10-11 00:42:35 +02:00
static char * complete_from_const ( const char * text , int state ) ;
2014-08-12 04:57:39 +02:00
static void append_variable_names ( char * * * varnames , int * nvars ,
2015-05-24 03:35:49 +02:00
int * maxvars , const char * varname ,
const char * prefix , const char * suffix ) ;
2014-04-04 17:26:01 +02:00
static char * * complete_from_variables ( const char * text ,
2015-05-24 03:35:49 +02:00
const char * prefix , const char * suffix , bool need_value ) ;
2012-02-28 05:06:29 +01:00
static char * complete_from_files ( const char * text , int state ) ;
2003-10-30 22:37:38 +01:00
2012-05-08 20:03:45 +02:00
static char * pg_strdup_keyword_case ( const char * s , const char * ref ) ;
2015-09-08 20:57:35 +02:00
static char * escape_string ( const char * text ) ;
2003-10-30 22:37:38 +01:00
static PGresult * exec_query ( const char * query ) ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
static char * * get_previous_words ( int point , char * * buffer , int * nwords ) ;
2003-10-30 22:37:38 +01:00
2015-09-08 20:57:35 +02:00
static char * get_guctype ( const char * varname ) ;
2010-10-11 00:42:35 +02:00
# ifdef NOT_USED
2003-10-30 22:37:38 +01:00
static char * quote_file_name ( char * text , int match_type , char * quote_pointer ) ;
static char * dequote_file_name ( char * text , char quote_char ) ;
# endif
2010-10-11 00:42:35 +02:00
/*
* Initialize the readline library for our purposes .
*/
2003-10-30 22:37:38 +01:00
void
initialize_readline ( void )
{
2004-08-29 07:07:03 +02:00
rl_readline_name = ( char * ) pset . progname ;
2014-04-04 17:26:01 +02:00
rl_attempted_completion_function = psql_completion ;
2003-10-30 22:37:38 +01:00
2010-02-17 05:09:40 +01:00
rl_basic_word_break_characters = WORD_BREAKS ;
2003-10-30 22:37:38 +01:00
completion_max_records = 1000 ;
/*
2005-10-15 04:49:52 +02:00
* There is a variable rl_completion_query_items for this but apparently
* it ' s not defined everywhere .
2003-10-30 22:37:38 +01:00
*/
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/*
* Check if ' word ' matches any of the ' | ' - separated strings in ' pattern ' ,
2016-01-05 18:00:13 +01:00
* using case - insensitive or case - sensitive comparisons .
*
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* If pattern is NULL , it ' s a wild card that matches any word .
2016-01-05 18:00:13 +01:00
* If pattern begins with ' ! ' , the result is negated , ie we check that ' word '
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* does * not * match any alternative appearing in the rest of ' pattern ' .
2016-01-05 18:00:13 +01:00
* Any alternative can end with ' * ' which is a wild card , i . e . , it means
* match any word that matches the characters so far . ( We do not currently
* support ' * ' elsewhere than the end of an alternative . )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
*
* For readability , callers should use the macros MatchAny and MatchAnyExcept
2016-01-05 18:00:13 +01:00
* to invoke those two special cases for ' pattern ' . ( But ' | ' and ' * ' must
* just be written directly in patterns . )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
*/
# define MatchAny NULL
# define MatchAnyExcept(pattern) ("!" pattern)
static bool
2016-01-05 18:00:13 +01:00
word_matches_internal ( const char * pattern ,
const char * word ,
bool case_sensitive )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
{
2016-01-05 18:00:13 +01:00
size_t wordlen ,
patternlen ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* NULL pattern matches anything. */
if ( pattern = = NULL )
return true ;
/* Handle negated patterns from the MatchAnyExcept macro. */
if ( * pattern = = ' ! ' )
2016-01-05 18:00:13 +01:00
return ! word_matches_internal ( pattern + 1 , word , case_sensitive ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* Else consider each alternative in the pattern. */
wordlen = strlen ( word ) ;
for ( ; ; )
{
const char * c ;
/* Find end of current alternative. */
c = pattern ;
while ( * c ! = ' \0 ' & & * c ! = ' | ' )
c + + ;
2016-01-05 18:00:13 +01:00
/* Was there a wild card? (Assumes first alternative is not empty) */
if ( c [ - 1 ] = = ' * ' )
{
/* Yes, wildcard match? */
patternlen = c - pattern - 1 ;
if ( wordlen > = patternlen & &
( case_sensitive ?
strncmp ( word , pattern , patternlen ) = = 0 :
pg_strncasecmp ( word , pattern , patternlen ) = = 0 ) )
return true ;
}
else
{
/* No, plain match? */
patternlen = c - pattern ;
if ( wordlen = = patternlen & &
( case_sensitive ?
strncmp ( word , pattern , wordlen ) = = 0 :
pg_strncasecmp ( word , pattern , wordlen ) = = 0 ) )
return true ;
}
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* Out of alternatives? */
if ( * c = = ' \0 ' )
break ;
/* Nope, try next alternative. */
pattern = c + 1 ;
}
return false ;
}
2016-01-05 18:00:13 +01:00
/*
* There are enough matching calls below that it seems worth having these two
* interface routines rather than including a third parameter in every call .
*
* word_matches - - - match case - insensitively .
*/
static bool
word_matches ( const char * pattern , const char * word )
{
return word_matches_internal ( pattern , word , false ) ;
}
/*
* word_matches_cs - - - match case - sensitively .
*/
static bool
word_matches_cs ( const char * pattern , const char * word )
{
return word_matches_internal ( pattern , word , true ) ;
}
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/*
* Check if the final character of ' s ' is ' c ' .
*/
static bool
ends_with ( const char * s , char c )
{
size_t length = strlen ( s ) ;
return ( length > 0 & & s [ length - 1 ] = = c ) ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2010-10-11 00:42:35 +02:00
/*
* The completion function .
*
* According to readline spec this gets passed the text entered so far and its
* start and end positions in the readline buffer . The return value is some
* partially obscure list format that can be generated by readline ' s
* completion_matches ( ) function , so we don ' t have to worry about it .
*/
2000-04-21 05:01:54 +02:00
static char * *
2014-04-04 17:26:01 +02:00
psql_completion ( const char * text , int start , int end )
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
{
2000-04-12 19:17:23 +02:00
/* This is the variable we'll return. */
char * * matches = NULL ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/* Workspace for parsed words. */
char * words_buffer ;
/* This array will contain pointers to parsed words. */
char * * previous_words ;
2011-10-20 21:38:57 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* The number of words found on the input line. */
int previous_words_count ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
* For compactness , we use these macros to reference previous_words [ ] .
* Caution : do not access a previous_words [ ] entry without having checked
* previous_words_count to be sure it ' s valid . In most cases below , that
* check is implicit in a TailMatches ( ) or similar macro , but in some
* places we have to check it explicitly .
*/
2011-10-20 21:38:57 +02:00
# define prev_wd (previous_words[0])
# define prev2_wd (previous_words[1])
# define prev3_wd (previous_words[2])
# define prev4_wd (previous_words[3])
# define prev5_wd (previous_words[4])
# define prev6_wd (previous_words[5])
2015-09-08 18:58:29 +02:00
# define prev7_wd (previous_words[6])
# define prev8_wd (previous_words[7])
# define prev9_wd (previous_words[8])
2000-04-12 19:17:23 +02:00
2016-01-05 18:00:13 +01:00
/* Macros for matching the last N words before point, case-insensitively. */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
# define TailMatches1(p1) \
( previous_words_count > = 1 & & \
word_matches ( p1 , prev_wd ) )
# define TailMatches2(p2, p1) \
( previous_words_count > = 2 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) )
# define TailMatches3(p3, p2, p1) \
( previous_words_count > = 3 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) )
# define TailMatches4(p4, p3, p2, p1) \
( previous_words_count > = 4 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) )
# define TailMatches5(p5, p4, p3, p2, p1) \
( previous_words_count > = 5 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) & & \
word_matches ( p5 , prev5_wd ) )
# define TailMatches6(p6, p5, p4, p3, p2, p1) \
( previous_words_count > = 6 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) & & \
word_matches ( p5 , prev5_wd ) & & \
word_matches ( p6 , prev6_wd ) )
# define TailMatches7(p7, p6, p5, p4, p3, p2, p1) \
( previous_words_count > = 7 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) & & \
word_matches ( p5 , prev5_wd ) & & \
word_matches ( p6 , prev6_wd ) & & \
word_matches ( p7 , prev7_wd ) )
# define TailMatches8(p8, p7, p6, p5, p4, p3, p2, p1) \
( previous_words_count > = 8 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) & & \
word_matches ( p5 , prev5_wd ) & & \
word_matches ( p6 , prev6_wd ) & & \
word_matches ( p7 , prev7_wd ) & & \
word_matches ( p8 , prev8_wd ) )
# define TailMatches9(p9, p8, p7, p6, p5, p4, p3, p2, p1) \
( previous_words_count > = 9 & & \
word_matches ( p1 , prev_wd ) & & \
word_matches ( p2 , prev2_wd ) & & \
word_matches ( p3 , prev3_wd ) & & \
word_matches ( p4 , prev4_wd ) & & \
word_matches ( p5 , prev5_wd ) & & \
word_matches ( p6 , prev6_wd ) & & \
word_matches ( p7 , prev7_wd ) & & \
word_matches ( p8 , prev8_wd ) & & \
word_matches ( p9 , prev9_wd ) )
2016-01-05 18:00:13 +01:00
/* Macros for matching the last N words before point, case-sensitively. */
# define TailMatchesCS1(p1) \
( previous_words_count > = 1 & & \
word_matches_cs ( p1 , prev_wd ) )
# define TailMatchesCS2(p2, p1) \
( previous_words_count > = 2 & & \
word_matches_cs ( p1 , prev_wd ) & & \
word_matches_cs ( p2 , prev2_wd ) )
2017-03-16 23:54:28 +01:00
# define TailMatchesCS3(p3, p2, p1) \
( previous_words_count > = 3 & & \
word_matches_cs ( p1 , prev_wd ) & & \
word_matches_cs ( p2 , prev2_wd ) & & \
word_matches_cs ( p3 , prev3_wd ) )
# define TailMatchesCS4(p4, p3, p2, p1) \
( previous_words_count > = 4 & & \
word_matches_cs ( p1 , prev_wd ) & & \
word_matches_cs ( p2 , prev2_wd ) & & \
word_matches_cs ( p3 , prev3_wd ) & & \
word_matches_cs ( p4 , prev4_wd ) )
2016-01-05 18:00:13 +01:00
/*
* Macros for matching N words beginning at the start of the line ,
* case - insensitively .
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
# define Matches1(p1) \
( previous_words_count = = 1 & & \
TailMatches1 ( p1 ) )
# define Matches2(p1, p2) \
( previous_words_count = = 2 & & \
TailMatches2 ( p1 , p2 ) )
# define Matches3(p1, p2, p3) \
( previous_words_count = = 3 & & \
TailMatches3 ( p1 , p2 , p3 ) )
# define Matches4(p1, p2, p3, p4) \
( previous_words_count = = 4 & & \
TailMatches4 ( p1 , p2 , p3 , p4 ) )
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
# define Matches5(p1, p2, p3, p4, p5) \
( previous_words_count = = 5 & & \
TailMatches5 ( p1 , p2 , p3 , p4 , p5 ) )
# define Matches6(p1, p2, p3, p4, p5, p6) \
( previous_words_count = = 6 & & \
TailMatches6 ( p1 , p2 , p3 , p4 , p5 , p6 ) )
# define Matches7(p1, p2, p3, p4, p5, p6, p7) \
( previous_words_count = = 7 & & \
TailMatches7 ( p1 , p2 , p3 , p4 , p5 , p6 , p7 ) )
# define Matches8(p1, p2, p3, p4, p5, p6, p7, p8) \
( previous_words_count = = 8 & & \
TailMatches8 ( p1 , p2 , p3 , p4 , p5 , p6 , p7 , p8 ) )
# define Matches9(p1, p2, p3, p4, p5, p6, p7, p8, p9) \
( previous_words_count = = 9 & & \
TailMatches9 ( p1 , p2 , p3 , p4 , p5 , p6 , p7 , p8 , p9 ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/*
* Macros for matching N words at the start of the line , regardless of
2016-01-05 18:00:13 +01:00
* what is after them , case - insensitively .
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
*/
# define HeadMatches1(p1) \
( previous_words_count > = 1 & & \
word_matches ( p1 , previous_words [ previous_words_count - 1 ] ) )
# define HeadMatches2(p1, p2) \
( previous_words_count > = 2 & & \
word_matches ( p1 , previous_words [ previous_words_count - 1 ] ) & & \
word_matches ( p2 , previous_words [ previous_words_count - 2 ] ) )
# define HeadMatches3(p1, p2, p3) \
( previous_words_count > = 3 & & \
word_matches ( p1 , previous_words [ previous_words_count - 1 ] ) & & \
word_matches ( p2 , previous_words [ previous_words_count - 2 ] ) & & \
word_matches ( p3 , previous_words [ previous_words_count - 3 ] ) )
/* Known command-starting keywords. */
2004-08-29 07:07:03 +02:00
static const char * const sql_commands [ ] = {
2006-04-02 11:02:41 +02:00
" ABORT " , " ALTER " , " ANALYZE " , " BEGIN " , " CHECKPOINT " , " CLOSE " , " CLUSTER " ,
" COMMENT " , " COMMIT " , " COPY " , " CREATE " , " DEALLOCATE " , " DECLARE " ,
2014-07-10 21:01:31 +02:00
" DELETE FROM " , " DISCARD " , " DO " , " DROP " , " END " , " EXECUTE " , " EXPLAIN " ,
" FETCH " , " GRANT " , " IMPORT " , " INSERT " , " LISTEN " , " LOAD " , " LOCK " ,
" MOVE " , " NOTIFY " , " PREPARE " ,
2016-01-26 15:45:08 +01:00
" REASSIGN " , " REFRESH MATERIALIZED VIEW " , " REINDEX " , " RELEASE " ,
" RESET " , " REVOKE " , " ROLLBACK " ,
2010-09-28 02:55:27 +02:00
" SAVEPOINT " , " SECURITY LABEL " , " SELECT " , " SET " , " SHOW " , " START " ,
" TABLE " , " TRUNCATE " , " UNLISTEN " , " UPDATE " , " VACUUM " , " VALUES " , " WITH " ,
NULL
2000-04-12 19:17:23 +02:00
} ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* psql's backslash commands. */
2004-08-29 07:07:03 +02:00
static const char * const backslash_commands [ ] = {
2016-04-09 01:23:18 +02:00
" \\ a " , " \\ connect " , " \\ conninfo " , " \\ C " , " \\ cd " , " \\ copy " ,
" \\ copyright " , " \\ crosstabview " ,
2016-06-07 23:59:34 +02:00
" \\ d " , " \\ da " , " \\ dA " , " \\ db " , " \\ dc " , " \\ dC " , " \\ dd " , " \\ ddp " , " \\ dD " ,
2015-07-07 16:34:18 +02:00
" \\ des " , " \\ det " , " \\ deu " , " \\ dew " , " \\ dE " , " \\ df " ,
2011-01-20 06:00:30 +01:00
" \\ dF " , " \\ dFd " , " \\ dFp " , " \\ dFt " , " \\ dg " , " \\ di " , " \\ dl " , " \\ dL " ,
2015-07-07 16:34:18 +02:00
" \\ dm " , " \\ dn " , " \\ do " , " \\ dO " , " \\ dp " , " \\ drds " , " \\ ds " , " \\ dS " ,
" \\ dt " , " \\ dT " , " \\ dv " , " \\ du " , " \\ dx " , " \\ dy " ,
2016-04-03 18:29:55 +02:00
" \\ e " , " \\ echo " , " \\ ef " , " \\ encoding " , " \\ errverbose " , " \\ ev " ,
2017-03-07 15:31:52 +01:00
" \\ f " , " \\ g " , " \\ gexec " , " \\ gset " , " \\ gx " , " \\ h " , " \\ help " , " \\ H " ,
" \\ i " , " \\ ir " , " \\ l " , " \\ lo_import " , " \\ lo_export " , " \\ lo_list " ,
" \\ lo_unlink " , " \\ o " , " \\ p " , " \\ password " , " \\ prompt " , " \\ pset " , " \\ q " ,
" \\ qecho " , " \\ r " , " \\ s " , " \\ set " , " \\ setenv " , " \\ sf " , " \\ sv " , " \\ t " ,
" \\ T " , " \\ timing " , " \\ unset " , " \\ x " , " \\ w " , " \\ watch " , " \\ z " , " \\ ! " ,
NULL
2000-04-12 19:17:23 +02:00
} ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
( void ) end ; /* "end" is not used */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2000-02-20 15:28:28 +01:00
# ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
2000-04-12 19:17:23 +02:00
rl_completion_append_character = ' ' ;
2000-02-20 15:28:28 +01:00
# endif
2000-04-12 19:17:23 +02:00
/* Clear a few things. */
completion_charp = NULL ;
completion_charpp = NULL ;
completion_info_charp = NULL ;
2008-03-29 20:19:14 +01:00
completion_info_charp2 = NULL ;
2000-04-12 19:17:23 +02:00
/*
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* Scan the input line to extract the words before our current position .
2012-06-10 21:20:04 +02:00
* According to those we ' ll make some smart decisions on what the user is
* probably intending to type .
2000-04-12 19:17:23 +02:00
*/
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
previous_words = get_previous_words ( start ,
& words_buffer ,
& previous_words_count ) ;
2000-04-12 19:17:23 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* If current word is a backslash command, offer completions for that */
2000-04-12 19:17:23 +02:00
if ( text [ 0 ] = = ' \\ ' )
2012-02-01 19:16:40 +01:00
COMPLETE_WITH_LIST_CS ( backslash_commands ) ;
2000-04-12 19:17:23 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* If current word is a variable interpolation, handle that case */
2011-02-11 22:57:58 +01:00
else if ( text [ 0 ] = = ' : ' & & text [ 1 ] ! = ' : ' )
{
if ( text [ 1 ] = = ' \' ' )
2014-08-12 04:57:39 +02:00
matches = complete_from_variables ( text , " :' " , " ' " , true ) ;
2011-02-11 22:57:58 +01:00
else if ( text [ 1 ] = = ' " ' )
2014-08-12 04:57:39 +02:00
matches = complete_from_variables ( text , " : \" " , " \" " , true ) ;
2011-02-11 22:57:58 +01:00
else
2014-08-12 04:57:39 +02:00
matches = complete_from_variables ( text , " : " , " " , true ) ;
2011-02-11 22:57:58 +01:00
}
2000-04-12 19:17:23 +02:00
/* If no previous word, suggest one of the basic sql commands */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( previous_words_count = = 0 )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_LIST ( sql_commands ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2006-04-02 11:02:41 +02:00
/* CREATE */
/* complete with something you can create */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " CREATE " ) )
2003-08-04 02:43:34 +02:00
matches = completion_matches ( text , create_command_generator ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2011-10-20 21:38:57 +02:00
/* DROP, but not DROP embedded in other commands */
2006-04-02 11:02:41 +02:00
/* complete with something you can drop */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " DROP " ) )
2006-04-02 11:02:41 +02:00
matches = completion_matches ( text , drop_command_generator ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* ALTER */
2003-08-04 02:43:34 +02:00
2014-09-07 14:04:35 +02:00
/* ALTER TABLE */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches2 ( " ALTER " , " TABLE " ) )
2014-09-07 14:04:35 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables ,
" UNION SELECT 'ALL IN TABLESPACE' " ) ;
2015-05-24 03:35:49 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* ALTER something */
else if ( Matches1 ( " ALTER " ) )
2017-03-16 23:54:28 +01:00
matches = completion_matches ( text , alter_command_generator ) ;
2015-12-19 17:37:11 +01:00
/* ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " ALL " , " IN " , " TABLESPACE " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " SET TABLESPACE " , " OWNED BY " ) ;
2015-12-19 17:37:11 +01:00
/* ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches6 ( " ALL " , " IN " , " TABLESPACE " , MatchAny , " OWNED " , " BY " ) )
2014-09-07 14:04:35 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2015-12-19 17:37:11 +01:00
/* ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY xxx */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches7 ( " ALL " , " IN " , " TABLESPACE " , MatchAny , " OWNED " , " BY " , MatchAny ) )
2015-12-19 17:37:11 +01:00
COMPLETE_WITH_CONST ( " SET TABLESPACE " ) ;
2005-08-14 20:49:30 +02:00
/* ALTER AGGREGATE,FUNCTION <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " AGGREGATE|FUNCTION " , MatchAny ) )
2010-07-06 21:19:02 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
2010-04-05 07:33:24 +02:00
/* ALTER AGGREGATE,FUNCTION <name> (...) */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " AGGREGATE|FUNCTION " , MatchAny , MatchAny ) )
2005-08-14 20:49:30 +02:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( ends_with ( prev_wd , ' ) ' ) )
COMPLETE_WITH_LIST3 ( " OWNER TO " , " RENAME TO " , " SET SCHEMA " ) ;
2010-04-05 07:33:24 +02:00
else
2012-07-05 14:03:49 +02:00
COMPLETE_WITH_FUNCTION_ARG ( prev2_wd ) ;
2005-08-14 20:49:30 +02:00
}
2017-01-19 18:00:00 +01:00
/* ALTER PUBLICATION <name> ...*/
else if ( Matches3 ( " ALTER " , " PUBLICATION " , MatchAny ) )
{
2017-03-03 16:47:04 +01:00
COMPLETE_WITH_LIST6 ( " WITH " , " ADD TABLE " , " SET TABLE " , " DROP TABLE " ,
" OWNER TO " , " RENAME TO " ) ;
2017-01-19 18:00:00 +01:00
}
/* ALTER PUBLICATION <name> .. WITH ( ... */
else if ( HeadMatches3 ( " ALTER " , " PUBLICATION " , MatchAny ) & & TailMatches2 ( " WITH " , " ( " ) )
{
COMPLETE_WITH_LIST6 ( " PUBLISH INSERT " , " NOPUBLISH INSERT " , " PUBLISH UPDATE " ,
" NOPUBLISH UPDATE " , " PUBLISH DELETE " , " NOPUBLISH DELETE " ) ;
}
/* ALTER SUBSCRIPTION <name> ... */
else if ( Matches3 ( " ALTER " , " SUBSCRIPTION " , MatchAny ) )
{
2017-03-03 16:47:04 +01:00
COMPLETE_WITH_LIST7 ( " WITH " , " CONNECTION " , " SET PUBLICATION " , " ENABLE " ,
" DISABLE " , " OWNER TO " , " RENAME TO " ) ;
2017-01-19 18:00:00 +01:00
}
else if ( HeadMatches3 ( " ALTER " , " SUBSCRIPTION " , MatchAny ) & & TailMatches2 ( " WITH " , " ( " ) )
{
COMPLETE_WITH_CONST ( " SLOT NAME " ) ;
}
2010-11-26 23:27:23 +01:00
/* ALTER SCHEMA <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " SCHEMA " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " OWNER TO " , " RENAME TO " ) ;
2001-03-22 05:01:46 +01:00
2011-02-12 14:54:13 +01:00
/* ALTER COLLATION <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " COLLATION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " OWNER TO " , " RENAME TO " , " SET SCHEMA " ) ;
2011-02-12 14:54:13 +01:00
2010-11-26 23:27:23 +01:00
/* ALTER CONVERSION <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " CONVERSION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " OWNER TO " , " RENAME TO " , " SET SCHEMA " ) ;
2010-11-26 23:27:23 +01:00
Clean up psql:
Add simple ALTER DATABASE, ALTER TRIGGER, CHECK POINT, CREATE
CONVERSION, CREATE DOMAIN, CREATE LANGUAGE, DEALLOCATE, DROP CONVERSION,
DROP DOMAIN, DROP LANGUAGE, EXECUTE, PREPARE
Complete CAST in CREATE CAST and DROP CAST but doesn't suggest what
should follow.
Add many more SET / SHOW variables to the list. Taken from SHOW ALL
output.
Complete a case sensitive search to allow \dD, \dd, \dS, \ds, \h, \H to
complete properly. But there are no matches, then try a case
insensitive search to allow case conversion. Add all missing help
options.
\Q<tab> -> \q
\dD<tab> -> \dD
\dd<tab> -> \dd
\D<tab><tab><tab> -> \d (with listing of \d? commands)
sel<tab> -> SELECT
Rod Taylor
2002-11-15 04:07:52 +01:00
/* ALTER DATABASE <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " DATABASE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST7 ( " RESET " , " SET " , " OWNER TO " , " RENAME TO " ,
" IS_TEMPLATE " , " ALLOW_CONNECTIONS " ,
" CONNECTION LIMIT " ) ;
2004-08-21 20:45:59 +02:00
2014-04-14 14:44:21 +02:00
/* ALTER EVENT TRIGGER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " EVENT " , " TRIGGER " ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_event_triggers ) ;
/* ALTER EVENT TRIGGER <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " EVENT " , " TRIGGER " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " DISABLE " , " ENABLE " , " OWNER TO " , " RENAME TO " ) ;
2014-04-14 14:44:21 +02:00
/* ALTER EVENT TRIGGER <name> ENABLE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " EVENT " , " TRIGGER " , MatchAny , " ENABLE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " REPLICA " , " ALWAYS " ) ;
2014-04-14 14:44:21 +02:00
2011-02-08 22:08:41 +01:00
/* ALTER EXTENSION <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " EXTENSION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " ADD " , " DROP " , " UPDATE " , " SET SCHEMA " ) ;
2011-02-08 22:08:41 +01:00
2016-08-18 17:17:10 +02:00
/* ALTER EXTENSION <name> UPDATE */
else if ( Matches4 ( " ALTER " , " EXTENSION " , MatchAny , " UPDATE " ) )
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_available_extension_versions_with_TO ) ;
}
/* ALTER EXTENSION <name> UPDATE TO */
else if ( Matches5 ( " ALTER " , " EXTENSION " , MatchAny , " UPDATE " , " TO " ) )
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_available_extension_versions ) ;
}
2011-01-02 05:48:11 +01:00
/* ALTER FOREIGN */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " ALTER " , " FOREIGN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " TABLE " ) ;
2011-01-02 05:48:11 +01:00
2008-12-19 17:25:19 +01:00
/* ALTER FOREIGN DATA WRAPPER <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " FOREIGN " , " DATA " , " WRAPPER " , MatchAny ) )
2016-01-23 12:57:42 +01:00
COMPLETE_WITH_LIST5 ( " HANDLER " , " VALIDATOR " , " OPTIONS " , " OWNER TO " , " RENAME TO " ) ;
2008-12-19 17:25:19 +01:00
2011-01-02 05:48:11 +01:00
/* ALTER FOREIGN TABLE <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " FOREIGN " , " TABLE " , MatchAny ) )
2011-01-02 05:48:11 +01:00
{
static const char * const list_ALTER_FOREIGN_TABLE [ ] =
2015-04-29 18:49:10 +02:00
{ " ADD " , " ALTER " , " DISABLE TRIGGER " , " DROP " , " ENABLE " , " INHERIT " ,
2015-05-24 03:35:49 +02:00
" NO INHERIT " , " OPTIONS " , " OWNER TO " , " RENAME " , " SET " ,
2015-04-29 18:49:10 +02:00
" VALIDATE CONSTRAINT " , NULL } ;
2011-01-02 05:48:11 +01:00
COMPLETE_WITH_LIST ( list_ALTER_FOREIGN_TABLE ) ;
}
2014-09-07 14:04:35 +02:00
/* ALTER INDEX */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " ALTER " , " INDEX " ) )
2014-09-07 14:04:35 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes ,
" UNION SELECT 'ALL IN TABLESPACE' " ) ;
2004-08-20 06:29:33 +02:00
/* ALTER INDEX <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " INDEX " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " OWNER TO " , " RENAME TO " , " SET " , " RESET " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER INDEX <name> SET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " INDEX " , MatchAny , " SET " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " ( " , " TABLESPACE " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER INDEX <name> RESET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " INDEX " , MatchAny , " RESET " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
/* ALTER INDEX <foo> SET|RESET ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " INDEX " , MatchAny , " RESET " , " ( " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " fillfactor " , " fastupdate " ,
" gin_pending_list_limit " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " INDEX " , MatchAny , " SET " , " ( " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " fillfactor = " , " fastupdate = " ,
" gin_pending_list_limit = " ) ;
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
2004-09-22 06:25:16 +02:00
/* ALTER LANGUAGE <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " LANGUAGE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " OWNER_TO " , " RENAME TO " ) ;
2004-09-22 06:25:16 +02:00
2009-12-11 04:34:57 +01:00
/* ALTER LARGE OBJECT <oid> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " LARGE " , " OBJECT " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " OWNER TO " ) ;
2009-12-11 04:34:57 +01:00
2013-03-04 01:23:31 +01:00
/* ALTER MATERIALIZED VIEW */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " MATERIALIZED " , " VIEW " ) )
2014-09-07 14:04:35 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews ,
" UNION SELECT 'ALL IN TABLESPACE' " ) ;
2013-03-04 01:23:31 +01:00
2005-08-14 20:49:30 +02:00
/* ALTER USER,ROLE <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " USER|ROLE " , MatchAny ) & &
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
! TailMatches2 ( " USER " , " MAPPING " ) )
2004-09-22 06:25:16 +02:00
{
static const char * const list_ALTERUSER [ ] =
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
{ " BYPASSRLS " , " CONNECTION LIMIT " , " CREATEDB " , " CREATEROLE " ,
2015-10-22 18:33:51 +02:00
" ENCRYPTED " , " INHERIT " , " LOGIN " , " NOBYPASSRLS " ,
" NOCREATEDB " , " NOCREATEROLE " , " NOINHERIT " ,
2015-06-19 17:11:22 +02:00
" NOLOGIN " , " NOREPLICATION " , " NOSUPERUSER " , " PASSWORD " , " RENAME TO " ,
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
" REPLICATION " , " RESET " , " SET " , " SUPERUSER " , " UNENCRYPTED " ,
" VALID UNTIL " , " WITH " , NULL } ;
2004-09-22 06:25:16 +02:00
COMPLETE_WITH_LIST ( list_ALTERUSER ) ;
}
2012-04-18 15:55:01 +02:00
/* ALTER USER,ROLE <name> WITH */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " USER|ROLE " , MatchAny , " WITH " ) )
2012-04-18 15:55:01 +02:00
{
/* Similar to the above, but don't complete "WITH" again. */
static const char * const list_ALTERUSER_WITH [ ] =
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
{ " BYPASSRLS " , " CONNECTION LIMIT " , " CREATEDB " , " CREATEROLE " ,
2015-10-22 18:33:51 +02:00
" ENCRYPTED " , " INHERIT " , " LOGIN " , " NOBYPASSRLS " ,
" NOCREATEDB " , " NOCREATEROLE " , " NOINHERIT " ,
2015-06-19 17:11:22 +02:00
" NOLOGIN " , " NOREPLICATION " , " NOSUPERUSER " , " PASSWORD " , " RENAME TO " ,
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
" REPLICATION " , " RESET " , " SET " , " SUPERUSER " , " UNENCRYPTED " ,
" VALID UNTIL " , NULL } ;
2012-04-18 15:55:01 +02:00
COMPLETE_WITH_LIST ( list_ALTERUSER_WITH ) ;
}
2005-08-14 20:49:30 +02:00
/* complete ALTER USER,ROLE <name> ENCRYPTED,UNENCRYPTED with PASSWORD */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " USER|ROLE " , MatchAny , " ENCRYPTED|UNENCRYPTED " ) )
2005-10-15 04:49:52 +02:00
COMPLETE_WITH_CONST ( " PASSWORD " ) ;
2010-04-07 05:51:19 +02:00
/* ALTER DEFAULT PRIVILEGES */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " DEFAULT " , " PRIVILEGES " ) )
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
COMPLETE_WITH_LIST2 ( " FOR ROLE " , " IN SCHEMA " ) ;
2010-04-07 05:51:19 +02:00
/* ALTER DEFAULT PRIVILEGES FOR */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " FOR " ) )
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
COMPLETE_WITH_CONST ( " ROLE " ) ;
/* ALTER DEFAULT PRIVILEGES IN */
else if ( Matches4 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " IN " ) )
COMPLETE_WITH_CONST ( " SCHEMA " ) ;
/* ALTER DEFAULT PRIVILEGES FOR ROLE|USER ... */
else if ( Matches6 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " FOR " , " ROLE|USER " ,
MatchAny ) )
COMPLETE_WITH_LIST3 ( " GRANT " , " REVOKE " , " IN SCHEMA " ) ;
/* ALTER DEFAULT PRIVILEGES IN SCHEMA ... */
else if ( Matches6 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " IN " , " SCHEMA " ,
MatchAny ) )
COMPLETE_WITH_LIST3 ( " GRANT " , " REVOKE " , " FOR ROLE " ) ;
/* ALTER DEFAULT PRIVILEGES IN SCHEMA ... FOR */
else if ( Matches7 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " IN " , " SCHEMA " ,
MatchAny , " FOR " ) )
COMPLETE_WITH_CONST ( " ROLE " ) ;
/* ALTER DEFAULT PRIVILEGES FOR ROLE|USER ... IN SCHEMA ... */
/* ALTER DEFAULT PRIVILEGES IN SCHEMA ... FOR ROLE|USER ... */
else if ( Matches9 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " FOR " , " ROLE|USER " ,
MatchAny , " IN " , " SCHEMA " , MatchAny ) | |
Matches9 ( " ALTER " , " DEFAULT " , " PRIVILEGES " , " IN " , " SCHEMA " ,
MatchAny , " FOR " , " ROLE|USER " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " GRANT " , " REVOKE " ) ;
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
/* ALTER DOMAIN <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " DOMAIN " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST6 ( " ADD " , " DROP " , " OWNER TO " , " RENAME " , " SET " ,
" VALIDATE CONSTRAINT " ) ;
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
/* ALTER DOMAIN <sth> DROP */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " DOMAIN " , MatchAny , " DROP " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " CONSTRAINT " , " DEFAULT " , " NOT NULL " ) ;
2012-09-15 04:11:17 +02:00
/* ALTER DOMAIN <sth> DROP|RENAME|VALIDATE CONSTRAINT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " DOMAIN " , MatchAny , " DROP|RENAME|VALIDATE " , " CONSTRAINT " ) )
2012-09-15 04:11:17 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_constraint_of_type ) ;
}
2012-04-26 19:07:40 +02:00
/* ALTER DOMAIN <sth> RENAME */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " DOMAIN " , MatchAny , " RENAME " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " CONSTRAINT " , " TO " ) ;
2012-04-26 19:07:40 +02:00
/* ALTER DOMAIN <sth> RENAME CONSTRAINT <sth> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " DOMAIN " , MatchAny , " RENAME " , " CONSTRAINT " , MatchAny ) )
2012-04-26 19:07:40 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
/* ALTER DOMAIN <sth> SET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " DOMAIN " , MatchAny , " SET " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " DEFAULT " , " NOT NULL " , " SCHEMA " ) ;
2004-09-22 06:25:16 +02:00
/* ALTER SEQUENCE <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " SEQUENCE " , MatchAny ) )
2004-09-22 06:25:16 +02:00
{
2005-10-15 04:49:52 +02:00
static const char * const list_ALTERSEQUENCE [ ] =
{ " INCREMENT " , " MINVALUE " , " MAXVALUE " , " RESTART " , " NO " , " CACHE " , " CYCLE " ,
2010-04-05 07:33:24 +02:00
" SET SCHEMA " , " OWNED BY " , " OWNER TO " , " RENAME TO " , NULL } ;
2004-09-22 06:25:16 +02:00
2005-10-15 04:49:52 +02:00
COMPLETE_WITH_LIST ( list_ALTERSEQUENCE ) ;
2004-09-22 06:25:16 +02:00
}
/* ALTER SEQUENCE <name> NO */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " SEQUENCE " , MatchAny , " NO " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " MINVALUE " , " MAXVALUE " , " CYCLE " ) ;
2008-12-19 17:25:19 +01:00
/* ALTER SERVER <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " SERVER " , MatchAny ) )
2016-01-23 12:57:42 +01:00
COMPLETE_WITH_LIST4 ( " VERSION " , " OPTIONS " , " OWNER TO " , " RENAME TO " ) ;
2016-06-10 00:02:36 +02:00
/* ALTER SERVER <name> VERSION <version> */
2016-01-23 12:57:42 +01:00
else if ( Matches5 ( " ALTER " , " SERVER " , MatchAny , " VERSION " , MatchAny ) )
COMPLETE_WITH_CONST ( " OPTIONS " ) ;
2014-09-02 09:06:58 +02:00
/* ALTER SYSTEM SET, RESET, RESET ALL */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " ALTER " , " SYSTEM " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " SET " , " RESET " ) ;
2016-02-01 14:19:51 +01:00
else if ( Matches3 ( " ALTER " , " SYSTEM " , " SET|RESET " ) )
2013-12-19 18:33:27 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_alter_system_set_vars ) ;
2017-02-15 21:23:19 +01:00
else if ( Matches4 ( " ALTER " , " SYSTEM " , " SET " , MatchAny ) )
COMPLETE_WITH_CONST ( " TO " ) ;
2007-07-03 03:30:37 +02:00
/* ALTER VIEW <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " VIEW " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " ALTER COLUMN " , " OWNER TO " , " RENAME TO " ,
" SET SCHEMA " ) ;
2013-03-04 01:23:31 +01:00
/* ALTER MATERIALIZED VIEW <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " MATERIALIZED " , " VIEW " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " ALTER COLUMN " , " OWNER TO " , " RENAME TO " ,
" SET SCHEMA " ) ;
2013-02-09 05:58:40 +01:00
2015-12-10 18:28:46 +01:00
/* ALTER POLICY <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " ALTER " , " POLICY " ) )
2015-12-10 18:28:46 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_policies ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* ALTER POLICY <name> ON */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " POLICY " , MatchAny ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
/* ALTER POLICY <name> ON <table> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " POLICY " , MatchAny , " ON " ) )
2015-12-10 18:28:46 +01:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_policy ) ;
}
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* ALTER POLICY <name> ON <table> - show options */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " POLICY " , MatchAny , " ON " , MatchAny ) )
COMPLETE_WITH_LIST4 ( " RENAME TO " , " TO " , " USING ( " , " WITH CHECK ( " ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* ALTER POLICY <name> ON <table> TO <role> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " POLICY " , MatchAny , " ON " , MatchAny , " TO " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_grant_roles ) ;
/* ALTER POLICY <name> ON <table> USING ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " POLICY " , MatchAny , " ON " , MatchAny , " USING " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
/* ALTER POLICY <name> ON <table> WITH CHECK ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " ALTER " , " POLICY " , MatchAny , " ON " , MatchAny , " WITH " , " CHECK " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
2013-02-09 05:58:40 +01:00
/* ALTER RULE <name>, add ON */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " RULE " , MatchAny ) )
2013-02-09 05:58:40 +01:00
COMPLETE_WITH_CONST ( " ON " ) ;
/* If we have ALTER RULE <name> ON, then add the correct tablename */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " RULE " , MatchAny , " ON " ) )
2013-02-09 05:58:40 +01:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_rule ) ;
}
/* ALTER RULE <name> ON <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " RULE " , MatchAny , " ON " , MatchAny ) )
2013-02-09 05:58:40 +01:00
COMPLETE_WITH_CONST ( " RENAME TO " ) ;
Clean up psql:
Add simple ALTER DATABASE, ALTER TRIGGER, CHECK POINT, CREATE
CONVERSION, CREATE DOMAIN, CREATE LANGUAGE, DEALLOCATE, DROP CONVERSION,
DROP DOMAIN, DROP LANGUAGE, EXECUTE, PREPARE
Complete CAST in CREATE CAST and DROP CAST but doesn't suggest what
should follow.
Add many more SET / SHOW variables to the list. Taken from SHOW ALL
output.
Complete a case sensitive search to allow \dD, \dd, \dS, \ds, \h, \H to
complete properly. But there are no matches, then try a case
insensitive search to allow case conversion. Add all missing help
options.
\Q<tab> -> \q
\dD<tab> -> \dD
\dd<tab> -> \dd
\D<tab><tab><tab> -> \d (with listing of \d? commands)
sel<tab> -> SELECT
Rod Taylor
2002-11-15 04:07:52 +01:00
/* ALTER TRIGGER <name>, add ON */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " TRIGGER " , MatchAny ) )
Clean up psql:
Add simple ALTER DATABASE, ALTER TRIGGER, CHECK POINT, CREATE
CONVERSION, CREATE DOMAIN, CREATE LANGUAGE, DEALLOCATE, DROP CONVERSION,
DROP DOMAIN, DROP LANGUAGE, EXECUTE, PREPARE
Complete CAST in CREATE CAST and DROP CAST but doesn't suggest what
should follow.
Add many more SET / SHOW variables to the list. Taken from SHOW ALL
output.
Complete a case sensitive search to allow \dD, \dd, \dS, \ds, \h, \H to
complete properly. But there are no matches, then try a case
insensitive search to allow case conversion. Add all missing help
options.
\Q<tab> -> \q
\dD<tab> -> \dD
\dd<tab> -> \dd
\D<tab><tab><tab> -> \d (with listing of \d? commands)
sel<tab> -> SELECT
Rod Taylor
2002-11-15 04:07:52 +01:00
COMPLETE_WITH_CONST ( " ON " ) ;
2004-11-02 17:10:05 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TRIGGER " , MatchAny , MatchAny ) )
2004-09-22 06:25:16 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_trigger ) ;
}
Clean up psql:
Add simple ALTER DATABASE, ALTER TRIGGER, CHECK POINT, CREATE
CONVERSION, CREATE DOMAIN, CREATE LANGUAGE, DEALLOCATE, DROP CONVERSION,
DROP DOMAIN, DROP LANGUAGE, EXECUTE, PREPARE
Complete CAST in CREATE CAST and DROP CAST but doesn't suggest what
should follow.
Add many more SET / SHOW variables to the list. Taken from SHOW ALL
output.
Complete a case sensitive search to allow \dD, \dd, \dS, \ds, \h, \H to
complete properly. But there are no matches, then try a case
insensitive search to allow case conversion. Add all missing help
options.
\Q<tab> -> \q
\dD<tab> -> \dD
\dd<tab> -> \dd
\D<tab><tab><tab> -> \d (with listing of \d? commands)
sel<tab> -> SELECT
Rod Taylor
2002-11-15 04:07:52 +01:00
/*
* If we have ALTER TRIGGER < sth > ON , then add the correct tablename
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TRIGGER " , MatchAny , " ON " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
Clean up psql:
Add simple ALTER DATABASE, ALTER TRIGGER, CHECK POINT, CREATE
CONVERSION, CREATE DOMAIN, CREATE LANGUAGE, DEALLOCATE, DROP CONVERSION,
DROP DOMAIN, DROP LANGUAGE, EXECUTE, PREPARE
Complete CAST in CREATE CAST and DROP CAST but doesn't suggest what
should follow.
Add many more SET / SHOW variables to the list. Taken from SHOW ALL
output.
Complete a case sensitive search to allow \dD, \dd, \dS, \ds, \h, \H to
complete properly. But there are no matches, then try a case
insensitive search to allow case conversion. Add all missing help
options.
\Q<tab> -> \q
\dD<tab> -> \dD
\dd<tab> -> \dd
\D<tab><tab><tab> -> \d (with listing of \d? commands)
sel<tab> -> SELECT
Rod Taylor
2002-11-15 04:07:52 +01:00
2004-09-22 06:25:16 +02:00
/* ALTER TRIGGER <name> ON <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TRIGGER " , MatchAny , " ON " , MatchAny ) )
2004-09-22 06:25:16 +02:00
COMPLETE_WITH_CONST ( " RENAME TO " ) ;
2001-03-22 05:01:46 +01:00
/*
2011-02-24 13:05:40 +01:00
* If we detect ALTER TABLE < name > , suggest sub commands
2001-03-22 05:01:46 +01:00
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " TABLE " , MatchAny ) )
2000-04-12 19:17:23 +02:00
{
2003-10-30 22:37:38 +01:00
static const char * const list_ALTER2 [ ] =
2007-09-14 06:25:24 +02:00
{ " ADD " , " ALTER " , " CLUSTER ON " , " DISABLE " , " DROP " , " ENABLE " , " INHERIT " ,
2011-04-10 17:42:00 +02:00
" NO INHERIT " , " RENAME " , " RESET " , " OWNER TO " , " SET " ,
2017-02-26 18:20:00 +01:00
" VALIDATE CONSTRAINT " , " REPLICA IDENTITY " , " ATTACH PARTITION " ,
" DETACH PARTITION " , NULL } ;
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_LIST ( list_ALTER2 ) ;
}
2007-09-14 06:25:24 +02:00
/* ALTER TABLE xxx ENABLE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " ALWAYS " , " REPLICA " , " ROW LEVEL SECURITY " , " RULE " ,
" TRIGGER " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " , " REPLICA|ALWAYS " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " RULE " , " TRIGGER " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " , " RULE " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_rule_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " , MatchAny , " RULE " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev4_wd ;
COMPLETE_WITH_QUERY ( Query_for_rule_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " , " TRIGGER " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_trigger_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TABLE " , MatchAny , " ENABLE " , MatchAny , " TRIGGER " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev4_wd ;
COMPLETE_WITH_QUERY ( Query_for_trigger_of_table ) ;
}
2012-07-26 16:16:55 +02:00
/* ALTER TABLE xxx INHERIT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " INHERIT " ) )
2012-07-26 16:16:55 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , " " ) ;
/* ALTER TABLE xxx NO INHERIT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " NO " , " INHERIT " ) )
2012-07-26 16:16:55 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , " " ) ;
2014-06-23 22:47:39 +02:00
/* ALTER TABLE xxx DISABLE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " DISABLE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " ROW LEVEL SECURITY " , " RULE " , " TRIGGER " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " DISABLE " , " RULE " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_rule_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " DISABLE " , " TRIGGER " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_trigger_of_table ) ;
}
2007-11-15 22:14:46 +01:00
2012-04-26 19:07:40 +02:00
/* ALTER TABLE xxx ALTER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " ALTER " ) )
2014-11-28 13:29:45 +01:00
COMPLETE_WITH_ATTR ( prev2_wd , " UNION SELECT 'COLUMN' UNION SELECT 'CONSTRAINT' " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2012-04-26 19:07:40 +02:00
/* ALTER TABLE xxx RENAME */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " RENAME " ) )
2012-04-26 19:07:40 +02:00
COMPLETE_WITH_ATTR ( prev2_wd , " UNION SELECT 'COLUMN' UNION SELECT 'CONSTRAINT' UNION SELECT 'TO' " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ALTER|RENAME " , " COLUMN " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev3_wd , " " ) ;
2006-10-04 02:30:14 +02:00
2004-09-22 06:25:16 +02:00
/* ALTER TABLE xxx RENAME yyy */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " RENAME " , MatchAnyExcept ( " CONSTRAINT|TO " ) ) )
2004-09-22 06:25:16 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
2012-04-26 19:07:40 +02:00
/* ALTER TABLE xxx RENAME COLUMN/CONSTRAINT yyy */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TABLE " , MatchAny , " RENAME " , " COLUMN|CONSTRAINT " , MatchAnyExcept ( " TO " ) ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_CONST ( " TO " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have ALTER TABLE <sth> DROP, provide COLUMN or CONSTRAINT */
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " DROP " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " COLUMN " , " CONSTRAINT " ) ;
2012-09-15 04:11:17 +02:00
/* If we have ALTER TABLE <sth> DROP COLUMN, provide list of columns */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " DROP " , " COLUMN " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev3_wd , " " ) ;
2013-05-29 22:58:43 +02:00
/*
2014-11-28 13:29:45 +01:00
* If we have ALTER TABLE < sth > ALTER | DROP | RENAME | VALIDATE CONSTRAINT ,
* provide list of constraints
2013-05-29 22:58:43 +02:00
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ALTER|DROP|RENAME|VALIDATE " , " CONSTRAINT " ) )
2012-08-20 22:30:08 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_constraint_of_table ) ;
}
2004-09-22 06:25:16 +02:00
/* ALTER TABLE ALTER [COLUMN] <foo> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , " COLUMN " , MatchAny ) | |
Matches5 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " TYPE " , " SET " , " RESET " , " DROP " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLE ALTER [COLUMN] <foo> SET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , " COLUMN " , MatchAny , " SET " ) | |
Matches6 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , MatchAny , " SET " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " ( " , " DEFAULT " , " NOT NULL " , " STATISTICS " , " STORAGE " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLE ALTER [COLUMN] <foo> SET ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches8 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , " COLUMN " , MatchAny , " SET " , " ( " ) | |
Matches7 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , MatchAny , " SET " , " ( " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " n_distinct " , " n_distinct_inherited " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLE ALTER [COLUMN] <foo> SET STORAGE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches8 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , " COLUMN " , MatchAny , " SET " , " STORAGE " ) | |
Matches7 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , MatchAny , " SET " , " STORAGE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " PLAIN " , " EXTERNAL " , " EXTENDED " , " MAIN " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLE ALTER [COLUMN] <foo> DROP */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , " COLUMN " , MatchAny , " DROP " ) | |
2016-11-28 17:51:30 +01:00
Matches6 ( " ALTER " , " TABLE " , MatchAny , " ALTER " , MatchAny , " DROP " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DEFAULT " , " NOT NULL " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " CLUSTER " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " CLUSTER " , " ON " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_index_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have ALTER TABLE <sth> SET, provide list of attributes and '(' */
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " SET " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST7 ( " ( " , " LOGGED " , " SCHEMA " , " TABLESPACE " , " UNLOGGED " ,
" WITH " , " WITHOUT " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/*
* If we have ALTER TABLE < sth > SET TABLESPACE provide a list of
* tablespaces
*/
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " SET " , " TABLESPACE " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_tablespaces ) ;
2016-02-01 14:19:51 +01:00
/* If we have ALTER TABLE <sth> SET WITH provide OIDS */
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " SET " , " WITH " ) )
COMPLETE_WITH_CONST ( " OIDS " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have ALTER TABLE <sth> SET WITHOUT provide CLUSTER or OIDS */
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " SET " , " WITHOUT " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " CLUSTER " , " OIDS " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLE <foo> RESET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " RESET " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
/* ALTER TABLE <foo> SET|RESET ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " SET|RESET " , " ( " ) )
2010-02-17 05:09:40 +01:00
{
static const char * const list_TABLEOPTIONS [ ] =
{
" autovacuum_analyze_scale_factor " ,
" autovacuum_analyze_threshold " ,
" autovacuum_enabled " ,
" autovacuum_freeze_max_age " ,
" autovacuum_freeze_min_age " ,
" autovacuum_freeze_table_age " ,
2014-09-05 04:40:08 +02:00
" autovacuum_multixact_freeze_max_age " ,
" autovacuum_multixact_freeze_min_age " ,
" autovacuum_multixact_freeze_table_age " ,
2010-02-17 05:09:40 +01:00
" autovacuum_vacuum_cost_delay " ,
" autovacuum_vacuum_cost_limit " ,
" autovacuum_vacuum_scale_factor " ,
" autovacuum_vacuum_threshold " ,
" fillfactor " ,
2016-06-09 15:08:27 +02:00
" parallel_workers " ,
2015-04-03 16:55:50 +02:00
" log_autovacuum_min_duration " ,
2010-02-17 05:09:40 +01:00
" toast.autovacuum_enabled " ,
" toast.autovacuum_freeze_max_age " ,
" toast.autovacuum_freeze_min_age " ,
" toast.autovacuum_freeze_table_age " ,
2014-09-05 04:40:08 +02:00
" toast.autovacuum_multixact_freeze_max_age " ,
" toast.autovacuum_multixact_freeze_min_age " ,
" toast.autovacuum_multixact_freeze_table_age " ,
2010-02-17 05:09:40 +01:00
" toast.autovacuum_vacuum_cost_delay " ,
" toast.autovacuum_vacuum_cost_limit " ,
" toast.autovacuum_vacuum_scale_factor " ,
" toast.autovacuum_vacuum_threshold " ,
2015-04-03 16:55:50 +02:00
" toast.log_autovacuum_min_duration " ,
2014-09-05 04:40:08 +02:00
" user_catalog_table " ,
2010-02-17 05:09:40 +01:00
NULL
} ;
COMPLETE_WITH_LIST ( list_TABLEOPTIONS ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " ALTER " , " TABLE " , MatchAny , " REPLICA " , " IDENTITY " , " USING " , " INDEX " ) )
2013-11-08 18:30:43 +01:00
{
completion_info_charp = prev5_wd ;
COMPLETE_WITH_QUERY ( Query_for_index_of_table ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TABLE " , MatchAny , " REPLICA " , " IDENTITY " , " USING " ) )
2013-11-08 18:30:43 +01:00
COMPLETE_WITH_CONST ( " INDEX " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " REPLICA " , " IDENTITY " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " FULL " , " NOTHING " , " DEFAULT " , " USING " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLE " , MatchAny , " REPLICA " ) )
2013-11-08 18:30:43 +01:00
COMPLETE_WITH_CONST ( " IDENTITY " ) ;
2017-02-26 18:20:00 +01:00
/*
* If we have ALTER TABLE < foo > ATTACH PARTITION , provide a list of
* tables .
*/
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " ATTACH " , " PARTITION " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , " " ) ;
/* Limited completion support for partition bound specification */
else if ( TailMatches3 ( " ATTACH " , " PARTITION " , MatchAny ) )
COMPLETE_WITH_CONST ( " FOR VALUES " ) ;
else if ( TailMatches2 ( " FOR " , " VALUES " ) )
COMPLETE_WITH_LIST2 ( " FROM ( " , " IN ( " ) ;
/*
* If we have ALTER TABLE < foo > DETACH PARTITION , provide a list of
* partitions of < foo > .
*/
else if ( Matches5 ( " ALTER " , " TABLE " , MatchAny , " DETACH " , " PARTITION " ) )
{
completion_info_charp = prev3_wd ;
COMPLETE_WITH_QUERY ( Query_for_partition_of_table ) ;
}
2010-02-17 05:09:40 +01:00
2014-09-07 14:04:35 +02:00
/* ALTER TABLESPACE <foo> with RENAME TO, OWNER TO, SET, RESET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " TABLESPACE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " RENAME TO " , " OWNER TO " , " SET " , " RESET " ) ;
2010-02-17 05:09:40 +01:00
/* ALTER TABLESPACE <foo> SET|RESET */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TABLESPACE " , MatchAny , " SET|RESET " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
/* ALTER TABLESPACE <foo> SET|RESET ( */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TABLESPACE " , MatchAny , " SET|RESET " , " ( " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " seq_page_cost " , " random_page_cost " ,
" effective_io_concurrency " ) ;
2010-02-17 05:09:40 +01:00
2007-09-14 06:25:24 +02:00
/* ALTER TEXT SEARCH */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " TEXT " , " SEARCH " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " CONFIGURATION " , " DICTIONARY " , " PARSER " , " TEMPLATE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TEXT " , " SEARCH " , " TEMPLATE|PARSER " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " RENAME TO " , " SET SCHEMA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TEXT " , " SEARCH " , " DICTIONARY " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " OWNER TO " , " RENAME TO " , " SET SCHEMA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TEXT " , " SEARCH " , " CONFIGURATION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST6 ( " ADD MAPPING FOR " , " ALTER MAPPING " ,
" DROP MAPPING FOR " ,
" OWNER TO " , " RENAME TO " , " SET SCHEMA " ) ;
2007-09-14 06:25:24 +02:00
2010-09-26 13:41:03 +02:00
/* complete ALTER TYPE <foo> with actions */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " TYPE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST7 ( " ADD ATTRIBUTE " , " ADD VALUE " , " ALTER ATTRIBUTE " ,
" DROP ATTRIBUTE " ,
" OWNER TO " , " RENAME " , " SET SCHEMA " ) ;
2011-02-24 13:05:40 +01:00
/* complete ALTER TYPE <foo> ADD with actions */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TYPE " , MatchAny , " ADD " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " ATTRIBUTE " , " VALUE " ) ;
2011-04-10 17:42:00 +02:00
/* ALTER TYPE <foo> RENAME */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " TYPE " , MatchAny , " RENAME " ) )
2016-11-08 22:27:09 +01:00
COMPLETE_WITH_LIST3 ( " ATTRIBUTE " , " TO " , " VALUE " ) ;
/* ALTER TYPE xxx RENAME (ATTRIBUTE|VALUE) yyy */
else if ( Matches6 ( " ALTER " , " TYPE " , MatchAny , " RENAME " , " ATTRIBUTE|VALUE " , MatchAny ) )
2010-09-26 13:41:03 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
2011-04-10 17:42:00 +02:00
/*
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
* If we have ALTER TYPE < sth > ALTER / DROP / RENAME ATTRIBUTE , provide list
* of attributes
2011-04-10 17:42:00 +02:00
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " TYPE " , MatchAny , " ALTER|DROP|RENAME " , " ATTRIBUTE " ) )
2010-09-26 13:41:03 +02:00
COMPLETE_WITH_ATTR ( prev3_wd , " " ) ;
/* ALTER TYPE ALTER ATTRIBUTE <foo> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " ALTER " , " TYPE " , MatchAny , " ALTER " , " ATTRIBUTE " , MatchAny ) )
2010-09-26 13:41:03 +02:00
COMPLETE_WITH_CONST ( " TYPE " ) ;
2004-09-22 06:25:16 +02:00
/* complete ALTER GROUP <foo> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER " , " GROUP " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " ADD USER " , " DROP USER " , " RENAME TO " ) ;
2000-06-25 16:25:51 +02:00
/* complete ALTER GROUP <foo> ADD|DROP with USER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER " , " GROUP " , MatchAny , " ADD|DROP " ) )
2000-06-25 16:25:51 +02:00
COMPLETE_WITH_CONST ( " USER " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* complete ALTER GROUP <foo> ADD|DROP USER with a user name */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " ALTER " , " GROUP " , MatchAny , " ADD|DROP " , " USER " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2000-06-25 16:25:51 +02:00
2016-11-08 22:27:09 +01:00
/*
* If we have ALTER TYPE < sth > RENAME VALUE , provide list of enum values
*/
else if ( Matches5 ( " ALTER " , " TYPE " , MatchAny , " RENAME " , " VALUE " ) )
COMPLETE_WITH_ENUM_VALUE ( prev3_wd ) ;
2016-09-01 23:10:30 +02:00
/* BEGIN */
else if ( Matches1 ( " BEGIN " ) )
COMPLETE_WITH_LIST6 ( " WORK " , " TRANSACTION " , " ISOLATION LEVEL " , " READ " , " DEFERRABLE " , " NOT DEFERRABLE " ) ;
/* END, ABORT */
else if ( Matches1 ( " END|ABORT " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " WORK " , " TRANSACTION " ) ;
2005-07-29 00:14:30 +02:00
/* COMMIT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " COMMIT " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " WORK " , " TRANSACTION " , " PREPARED " ) ;
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
/* RELEASE SAVEPOINT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " RELEASE " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
COMPLETE_WITH_CONST ( " SAVEPOINT " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* ROLLBACK */
else if ( Matches1 ( " ROLLBACK " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " WORK " , " TRANSACTION " , " TO SAVEPOINT " , " PREPARED " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* CLUSTER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " CLUSTER " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm , " UNION SELECT 'VERBOSE' " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CLUSTER " , " VERBOSE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm , NULL ) ;
2007-04-08 02:26:34 +02:00
/* If we have CLUSTER <sth>, then add "USING" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CLUSTER " , MatchAnyExcept ( " VERBOSE|ON " ) ) )
2012-08-20 22:45:44 +02:00
COMPLETE_WITH_CONST ( " USING " ) ;
/* If we have CLUSTER VERBOSE <sth>, then add "USING" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CLUSTER " , " VERBOSE " , MatchAny ) )
2007-04-08 02:26:34 +02:00
COMPLETE_WITH_CONST ( " USING " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have CLUSTER <sth> USING, then add the index as well */
else if ( Matches3 ( " CLUSTER " , MatchAny , " USING " ) | |
Matches4 ( " CLUSTER " , " VERBOSE " , MatchAny , " USING " ) )
2012-08-20 22:45:44 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_index_of_table ) ;
}
2000-06-25 16:25:51 +02:00
/* COMMENT */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " COMMENT " ) )
2000-06-25 16:25:51 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " COMMENT " , " ON " ) )
2000-06-25 16:25:51 +02:00
{
2003-10-30 22:37:38 +01:00
static const char * const list_COMMENT [ ] =
2016-06-07 23:59:34 +02:00
{ " ACCESS METHOD " , " CAST " , " COLLATION " , " CONVERSION " , " DATABASE " ,
" EVENT TRIGGER " , " EXTENSION " ,
2011-06-12 05:52:44 +02:00
" FOREIGN DATA WRAPPER " , " FOREIGN TABLE " ,
Rename pg_rowsecurity -> pg_policy and other fixes
As pointed out by Robert, we should really have named pg_rowsecurity
pg_policy, as the objects stored in that catalog are policies. This
patch fixes that and updates the column names to start with 'pol' to
match the new catalog name.
The security consideration for COPY with row level security, also
pointed out by Robert, has also been addressed by remembering and
re-checking the OID of the relation initially referenced during COPY
processing, to make sure it hasn't changed under us by the time we
finish planning out the query which has been built.
Robert and Alvaro also commented on missing OCLASS and OBJECT entries
for POLICY (formerly ROWSECURITY or POLICY, depending) in various
places. This patch fixes that too, which also happens to add the
ability to COMMENT on policies.
In passing, attempt to improve the consistency of messages, comments,
and documentation as well. This removes various incarnations of
'row-security', 'row-level security', 'Row-security', etc, in favor
of 'policy', 'row level security' or 'row_security' as appropriate.
Happy Thanksgiving!
2014-11-27 07:06:36 +01:00
" SERVER " , " INDEX " , " LANGUAGE " , " POLICY " , " RULE " , " SCHEMA " , " SEQUENCE " ,
2013-03-04 01:23:31 +01:00
" TABLE " , " TYPE " , " VIEW " , " MATERIALIZED VIEW " , " COLUMN " , " AGGREGATE " , " FUNCTION " ,
2006-02-12 04:22:21 +01:00
" OPERATOR " , " TRIGGER " , " CONSTRAINT " , " DOMAIN " , " LARGE OBJECT " ,
2007-09-14 06:25:24 +02:00
" TABLESPACE " , " TEXT SEARCH " , " ROLE " , NULL } ;
2001-03-22 05:01:46 +01:00
2000-06-25 16:25:51 +02:00
COMPLETE_WITH_LIST ( list_COMMENT ) ;
}
2016-06-07 23:59:34 +02:00
else if ( Matches4 ( " COMMENT " , " ON " , " ACCESS " , " METHOD " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_access_methods ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " COMMENT " , " ON " , " FOREIGN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " TABLE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " COMMENT " , " ON " , " TEXT " , " SEARCH " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " CONFIGURATION " , " DICTIONARY " , " PARSER " , " TEMPLATE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " COMMENT " , " ON " , " CONSTRAINT " ) )
2012-09-15 04:11:17 +02:00
COMPLETE_WITH_QUERY ( Query_for_all_table_constraints ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " COMMENT " , " ON " , " CONSTRAINT " , MatchAny ) )
2012-09-15 04:11:17 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " COMMENT " , " ON " , " CONSTRAINT " , MatchAny , " ON " ) )
2012-09-15 04:11:17 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_constraint ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " COMMENT " , " ON " , " MATERIALIZED " , " VIEW " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews , NULL ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " COMMENT " , " ON " , " EVENT " , " TRIGGER " ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_event_triggers ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " COMMENT " , " ON " , MatchAny , MatchAnyExcept ( " IS " ) ) | |
Matches5 ( " COMMENT " , " ON " , MatchAny , MatchAny , MatchAnyExcept ( " IS " ) ) | |
Matches6 ( " COMMENT " , " ON " , MatchAny , MatchAny , MatchAny , MatchAnyExcept ( " IS " ) ) )
2000-06-25 16:25:51 +02:00
COMPLETE_WITH_CONST ( " IS " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* COPY */
2000-04-12 19:17:23 +02:00
/*
2016-01-21 03:27:46 +01:00
* If we have COPY , offer list of tables or " ( " ( Also cover the analogous
* backslash command ) .
2000-04-12 19:17:23 +02:00
*/
2016-01-21 03:27:46 +01:00
else if ( Matches1 ( " COPY| \\ copy " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables ,
" UNION ALL SELECT '(' " ) ;
/* If we have COPY BINARY, complete with list of tables */
else if ( Matches2 ( " COPY " , " BINARY " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
2016-01-21 03:27:46 +01:00
/* If we have COPY (, complete it with legal commands */
else if ( Matches2 ( " COPY| \\ copy " , " ( " ) )
COMPLETE_WITH_LIST7 ( " SELECT " , " TABLE " , " VALUES " , " INSERT " , " UPDATE " , " DELETE " , " WITH " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have COPY [BINARY] <sth>, complete it with "TO" or "FROM" */
else if ( Matches2 ( " COPY| \\ copy " , MatchAny ) | |
Matches3 ( " COPY " , " BINARY " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " FROM " , " TO " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* If we have COPY [BINARY] <sth> FROM|TO, complete with filename */
else if ( Matches3 ( " COPY| \\ copy " , MatchAny , " FROM|TO " ) | |
Matches4 ( " COPY " , " BINARY " , MatchAny , " FROM|TO " ) )
2012-02-28 05:06:29 +01:00
{
completion_charp = " " ;
matches = completion_matches ( text , complete_from_files ) ;
}
2004-09-22 06:25:16 +02:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Handle COPY [BINARY] <sth> FROM|TO filename */
else if ( Matches4 ( " COPY| \\ copy " , MatchAny , " FROM|TO " , MatchAny ) | |
Matches5 ( " COPY " , " BINARY " , MatchAny , " FROM|TO " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST6 ( " BINARY " , " OIDS " , " DELIMITER " , " NULL " , " CSV " ,
" ENCODING " ) ;
2004-09-22 06:25:16 +02:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Handle COPY [BINARY] <sth> FROM|TO filename CSV */
else if ( Matches5 ( " COPY| \\ copy " , MatchAny , " FROM|TO " , MatchAny , " CSV " ) | |
Matches6 ( " COPY " , " BINARY " , MatchAny , " FROM|TO " , MatchAny , " CSV " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " HEADER " , " QUOTE " , " ESCAPE " , " FORCE QUOTE " ,
" FORCE NOT NULL " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2016-03-28 18:32:13 +02:00
/* CREATE ACCESS METHOD */
/* Complete "CREATE ACCESS METHOD <name>" */
else if ( Matches4 ( " CREATE " , " ACCESS " , " METHOD " , MatchAny ) )
COMPLETE_WITH_CONST ( " TYPE " ) ;
/* Complete "CREATE ACCESS METHOD <name> TYPE" */
else if ( Matches5 ( " CREATE " , " ACCESS " , " METHOD " , MatchAny , " TYPE " ) )
COMPLETE_WITH_CONST ( " INDEX " ) ;
/* Complete "CREATE ACCESS METHOD <name> TYPE <type>" */
else if ( Matches6 ( " CREATE " , " ACCESS " , " METHOD " , MatchAny , " TYPE " , MatchAny ) )
COMPLETE_WITH_CONST ( " HANDLER " ) ;
2005-08-14 20:49:30 +02:00
/* CREATE DATABASE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " DATABASE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST9 ( " OWNER " , " TEMPLATE " , " ENCODING " , " TABLESPACE " ,
" IS_TEMPLATE " ,
" ALLOW_CONNECTIONS " , " CONNECTION LIMIT " ,
" LC_COLLATE " , " LC_CTYPE " ) ;
2005-08-14 20:49:30 +02:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " DATABASE " , MatchAny , " TEMPLATE " ) )
2007-09-14 06:25:24 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_template_databases ) ;
2011-02-08 22:08:41 +01:00
/* CREATE EXTENSION */
/* Complete with available extensions rather than installed ones. */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CREATE " , " EXTENSION " ) )
2011-02-08 22:08:41 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_available_extensions ) ;
/* CREATE EXTENSION <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " EXTENSION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " WITH SCHEMA " , " CASCADE " , " VERSION " ) ;
2015-10-20 16:27:20 +02:00
/* CREATE EXTENSION <name> VERSION */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " EXTENSION " , MatchAny , " VERSION " ) )
2015-10-20 16:27:20 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_available_extension_versions ) ;
}
2011-02-08 22:08:41 +01:00
2011-01-02 05:48:11 +01:00
/* CREATE FOREIGN */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CREATE " , " FOREIGN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " TABLE " ) ;
2011-01-02 05:48:11 +01:00
2008-12-19 17:25:19 +01:00
/* CREATE FOREIGN DATA WRAPPER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " FOREIGN " , " DATA " , " WRAPPER " , MatchAny ) )
2016-01-23 12:57:42 +01:00
COMPLETE_WITH_LIST3 ( " HANDLER " , " VALIDATOR " , " OPTIONS " ) ;
2008-12-19 17:25:19 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* CREATE INDEX --- is allowed inside CREATE SCHEMA, so use TailMatches */
2000-04-12 19:17:23 +02:00
/* First off we complete CREATE UNIQUE with "INDEX" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " CREATE " , " UNIQUE " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " INDEX " ) ;
2016-06-10 00:02:36 +02:00
/*
* If we have CREATE | UNIQUE INDEX , then add " ON " , " CONCURRENTLY " , and
* existing indexes
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " CREATE|UNIQUE " , " INDEX " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes ,
" UNION SELECT 'ON' "
" UNION SELECT 'CONCURRENTLY' " ) ;
2016-01-13 02:31:43 +01:00
/* Complete ... INDEX|CONCURRENTLY [<name>] ON with a list of tables */
else if ( TailMatches3 ( " INDEX|CONCURRENTLY " , MatchAny , " ON " ) | |
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
TailMatches2 ( " INDEX|CONCURRENTLY " , " ON " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm , NULL ) ;
2016-06-10 00:02:36 +02:00
/*
* Complete CREATE | UNIQUE INDEX CONCURRENTLY with " ON " and existing
* indexes
*/
2016-01-17 02:46:14 +01:00
else if ( TailMatches3 ( " CREATE|UNIQUE " , " INDEX " , " CONCURRENTLY " ) )
2016-01-13 02:31:43 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes ,
" UNION SELECT 'ON' " ) ;
/* Complete CREATE|UNIQUE INDEX [CONCURRENTLY] <sth> with "ON" */
else if ( TailMatches3 ( " CREATE|UNIQUE " , " INDEX " , MatchAny ) | |
TailMatches4 ( " CREATE|UNIQUE " , " INDEX " , " CONCURRENTLY " , MatchAny ) )
2016-01-10 17:43:27 +01:00
COMPLETE_WITH_CONST ( " ON " ) ;
2000-04-12 19:17:23 +02:00
/*
2005-10-15 04:49:52 +02:00
* Complete INDEX < name > ON < table > with a list of table columns ( which
* should really be in parens )
2000-04-12 19:17:23 +02:00
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " INDEX " , MatchAny , " ON " , MatchAny ) | |
TailMatches3 ( " INDEX|CONCURRENTLY " , " ON " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " ( " , " USING " ) ;
else if ( TailMatches5 ( " INDEX " , MatchAny , " ON " , MatchAny , " ( " ) | |
TailMatches4 ( " INDEX|CONCURRENTLY " , " ON " , MatchAny , " ( " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev2_wd , " " ) ;
2000-04-12 19:17:23 +02:00
/* same if you put in USING */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches5 ( " ON " , MatchAny , " USING " , MatchAny , " ( " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_ATTR ( prev4_wd , " " ) ;
2000-04-12 19:17:23 +02:00
/* Complete USING with an index method */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches6 ( " INDEX " , MatchAny , MatchAny , " ON " , MatchAny , " USING " ) | |
TailMatches5 ( " INDEX " , MatchAny , " ON " , MatchAny , " USING " ) | |
TailMatches4 ( " INDEX " , " ON " , MatchAny , " USING " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_access_methods ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " ON " , MatchAny , " USING " , MatchAny ) & &
! TailMatches6 ( " POLICY " , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny ) & &
! TailMatches4 ( " FOR " , MatchAny , MatchAny , MatchAny ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
2000-04-12 19:17:23 +02:00
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* CREATE POLICY */
/* Complete "CREATE POLICY <name> ON" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " POLICY " , MatchAny ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
/* Complete "CREATE POLICY <name> ON <table>" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " POLICY " , MatchAny , " ON " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
2016-12-05 21:50:55 +01:00
/* Complete "CREATE POLICY <name> ON <table> AS|FOR|TO|USING|WITH CHECK" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny ) )
2016-12-05 21:50:55 +01:00
COMPLETE_WITH_LIST5 ( " AS " , " FOR " , " TO " , " USING ( " , " WITH CHECK ( " ) ;
/* CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE */
else if ( Matches6 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " ) )
COMPLETE_WITH_LIST2 ( " PERMISSIVE " , " RESTRICTIVE " ) ;
/* CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE FOR|TO|USING|WITH CHECK */
else if ( Matches7 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny ) )
COMPLETE_WITH_LIST4 ( " FOR " , " TO " , " USING " , " WITH CHECK " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* CREATE POLICY <name> ON <table> FOR ALL|SELECT|INSERT|UPDATE|DELETE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " FOR " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " ALL " , " SELECT " , " INSERT " , " UPDATE " , " DELETE " ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* Complete "CREATE POLICY <name> ON <table> FOR INSERT TO|WITH CHECK" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " FOR " , " INSERT " ) )
COMPLETE_WITH_LIST2 ( " TO " , " WITH CHECK ( " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* Complete "CREATE POLICY <name> ON <table> FOR SELECT|DELETE TO|USING" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " FOR " , " SELECT|DELETE " ) )
COMPLETE_WITH_LIST2 ( " TO " , " USING ( " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* CREATE POLICY <name> ON <table> FOR ALL|UPDATE TO|USING|WITH CHECK */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches7 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " FOR " , " ALL|UPDATE " ) )
COMPLETE_WITH_LIST3 ( " TO " , " USING ( " , " WITH CHECK ( " ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* Complete "CREATE POLICY <name> ON <table> TO <role>" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " TO " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_grant_roles ) ;
/* Complete "CREATE POLICY <name> ON <table> USING (" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " USING " ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
2016-12-05 21:50:55 +01:00
/* CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE FOR ALL|SELECT|INSERT|UPDATE|DELETE */
else if ( Matches8 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " FOR " ) )
COMPLETE_WITH_LIST5 ( " ALL " , " SELECT " , " INSERT " , " UPDATE " , " DELETE " ) ;
/* Complete "CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE FOR INSERT TO|WITH CHECK" */
else if ( Matches9 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " FOR " , " INSERT " ) )
COMPLETE_WITH_LIST2 ( " TO " , " WITH CHECK ( " ) ;
/* Complete "CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE FOR SELECT|DELETE TO|USING" */
else if ( Matches9 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " FOR " , " SELECT|DELETE " ) )
COMPLETE_WITH_LIST2 ( " TO " , " USING ( " ) ;
/* CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE FOR ALL|UPDATE TO|USING|WITH CHECK */
else if ( Matches9 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " FOR " , " ALL|UPDATE " ) )
COMPLETE_WITH_LIST3 ( " TO " , " USING ( " , " WITH CHECK ( " ) ;
/* Complete "CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE TO <role>" */
else if ( Matches8 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " TO " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_grant_roles ) ;
/* Complete "CREATE POLICY <name> ON <table> AS PERMISSIVE|RESTRICTIVE USING (" */
else if ( Matches8 ( " CREATE " , " POLICY " , MatchAny , " ON " , MatchAny , " AS " , MatchAny , " USING " ) )
COMPLETE_WITH_CONST ( " ( " ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
2017-01-19 18:00:00 +01:00
/* CREATE PUBLICATION */
else if ( Matches3 ( " CREATE " , " PUBLICATION " , MatchAny ) )
COMPLETE_WITH_LIST3 ( " FOR TABLE " , " FOR ALL TABLES " , " WITH ( " ) ;
else if ( Matches4 ( " CREATE " , " PUBLICATION " , MatchAny , " FOR " ) )
COMPLETE_WITH_LIST2 ( " TABLE " , " ALL TABLES " ) ;
/* Complete "CREATE PUBLICATION <name> FOR TABLE <table>" */
else if ( Matches4 ( " CREATE " , " PUBLICATION " , MatchAny , " FOR TABLE " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
/* Complete "CREATE PUBLICATION <name> [...] WITH" */
else if ( HeadMatches2 ( " CREATE " , " PUBLICATION " ) & & TailMatches2 ( " WITH " , " ( " ) )
COMPLETE_WITH_LIST2 ( " PUBLISH " , " NOPUBLISH " ) ;
else if ( HeadMatches2 ( " CREATE " , " PUBLICATION " ) & & TailMatches3 ( " WITH " , " ( " , MatchAny ) )
COMPLETE_WITH_LIST3 ( " INSERT " , " UPDATE " , " DELETE " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* CREATE RULE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Complete "CREATE RULE <sth>" with "AS ON" */
else if ( Matches3 ( " CREATE " , " RULE " , MatchAny ) )
COMPLETE_WITH_CONST ( " AS ON " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* Complete "CREATE RULE <sth> AS" with "ON" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " RULE " , MatchAny , " AS " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Complete "CREATE RULE <sth> AS ON" with SELECT|UPDATE|INSERT|DELETE */
else if ( Matches5 ( " CREATE " , " RULE " , MatchAny , " AS " , " ON " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " SELECT " , " UPDATE " , " INSERT " , " DELETE " ) ;
/* Complete "AS ON SELECT|UPDATE|INSERT|DELETE" with a "TO" */
else if ( TailMatches3 ( " AS " , " ON " , " SELECT|UPDATE|INSERT|DELETE " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
/* Complete "AS ON <sth> TO" with a table name */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " AS " , " ON " , " SELECT|UPDATE|INSERT|DELETE " , " TO " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* CREATE SEQUENCE --- is allowed inside CREATE SCHEMA, so use TailMatches */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " CREATE " , " SEQUENCE " , MatchAny ) | |
TailMatches4 ( " CREATE " , " TEMP|TEMPORARY " , " SEQUENCE " , MatchAny ) )
COMPLETE_WITH_LIST8 ( " INCREMENT BY " , " MINVALUE " , " MAXVALUE " , " NO " , " CACHE " ,
" CYCLE " , " OWNED BY " , " START WITH " ) ;
else if ( TailMatches4 ( " CREATE " , " SEQUENCE " , MatchAny , " NO " ) | |
TailMatches5 ( " CREATE " , " TEMP|TEMPORARY " , " SEQUENCE " , MatchAny , " NO " ) )
COMPLETE_WITH_LIST3 ( " MINVALUE " , " MAXVALUE " , " CYCLE " ) ;
2015-08-04 18:29:20 +02:00
2008-12-19 17:25:19 +01:00
/* CREATE SERVER <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " SERVER " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " TYPE " , " VERSION " , " FOREIGN DATA WRAPPER " ) ;
2008-12-19 17:25:19 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* CREATE TABLE --- is allowed inside CREATE SCHEMA, so use TailMatches */
2007-04-27 00:25:56 +02:00
/* Complete "CREATE TEMP/TEMPORARY" with the possible temp objects */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " CREATE " , " TEMP|TEMPORARY " ) )
COMPLETE_WITH_LIST3 ( " SEQUENCE " , " TABLE " , " VIEW " ) ;
/* Complete "CREATE UNLOGGED" with TABLE or MATVIEW */
else if ( TailMatches2 ( " CREATE " , " UNLOGGED " ) )
COMPLETE_WITH_LIST2 ( " TABLE " , " MATERIALIZED VIEW " ) ;
2017-02-26 18:20:00 +01:00
/* Complete PARTITION BY with RANGE ( or LIST ( or ... */
else if ( TailMatches2 ( " PARTITION " , " BY " ) )
COMPLETE_WITH_LIST2 ( " RANGE ( " , " LIST ( " ) ;
/* If we have xxx PARTITION OF, provide a list of partitioned tables */
else if ( TailMatches2 ( " PARTITION " , " OF " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_partitioned_tables , " " ) ;
/* Limited completion support for partition bound specification */
else if ( TailMatches3 ( " PARTITION " , " OF " , MatchAny ) )
COMPLETE_WITH_CONST ( " FOR VALUES " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2004-11-02 17:10:05 +01:00
/* CREATE TABLESPACE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " TABLESPACE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " OWNER " , " LOCATION " ) ;
2004-11-02 17:10:05 +01:00
/* Complete CREATE TABLESPACE name OWNER name with "LOCATION" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " TABLESPACE " , MatchAny , " OWNER " , MatchAny ) )
2004-11-02 17:10:05 +01:00
COMPLETE_WITH_CONST ( " LOCATION " ) ;
2007-09-14 06:25:24 +02:00
/* CREATE TEXT SEARCH */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " TEXT " , " SEARCH " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " CONFIGURATION " , " DICTIONARY " , " PARSER " , " TEMPLATE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " TEXT " , " SEARCH " , " CONFIGURATION " , MatchAny ) )
2007-11-15 22:14:46 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
2007-09-14 06:25:24 +02:00
2017-01-19 18:00:00 +01:00
/* CREATE SUBSCRIPTION */
else if ( Matches3 ( " CREATE " , " SUBSCRIPTION " , MatchAny ) )
COMPLETE_WITH_CONST ( " CONNECTION " ) ;
2017-03-03 20:13:48 +01:00
else if ( Matches5 ( " CREATE " , " SUBSCRIPTION " , MatchAny , " CONNECTION " , MatchAny ) )
2017-01-19 18:00:00 +01:00
COMPLETE_WITH_CONST ( " PUBLICATION " ) ;
2017-03-03 20:13:48 +01:00
else if ( Matches6 ( " CREATE " , " SUBSCRIPTION " , MatchAny , " CONNECTION " ,
MatchAny , " PUBLICATION " ) )
{
/* complete with nothing here as this refers to remote publications */
}
2017-01-19 18:00:00 +01:00
/* Complete "CREATE SUBSCRIPTION <name> ... WITH ( <opt>" */
else if ( HeadMatches2 ( " CREATE " , " SUBSCRIPTION " ) & & TailMatches2 ( " WITH " , " ( " ) )
COMPLETE_WITH_LIST5 ( " ENABLED " , " DISABLED " , " CREATE SLOT " ,
" NOCREATE SLOT " , " SLOT NAME " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* CREATE TRIGGER --- is allowed inside CREATE SCHEMA, so use TailMatches */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* complete CREATE TRIGGER <name> with BEFORE,AFTER,INSTEAD OF */
else if ( TailMatches3 ( " CREATE " , " TRIGGER " , MatchAny ) )
COMPLETE_WITH_LIST3 ( " BEFORE " , " AFTER " , " INSTEAD OF " ) ;
2010-02-17 05:09:40 +01:00
/* complete CREATE TRIGGER <name> BEFORE,AFTER with an event */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " CREATE " , " TRIGGER " , MatchAny , " BEFORE|AFTER " ) )
COMPLETE_WITH_LIST4 ( " INSERT " , " DELETE " , " UPDATE " , " TRUNCATE " ) ;
2011-02-24 13:05:40 +01:00
/* complete CREATE TRIGGER <name> INSTEAD OF with an event */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches5 ( " CREATE " , " TRIGGER " , MatchAny , " INSTEAD " , " OF " ) )
COMPLETE_WITH_LIST3 ( " INSERT " , " DELETE " , " UPDATE " ) ;
2011-02-24 13:05:40 +01:00
/* complete CREATE TRIGGER <name> BEFORE,AFTER sth with OR,ON */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches5 ( " CREATE " , " TRIGGER " , MatchAny , " BEFORE|AFTER " , MatchAny ) | |
TailMatches6 ( " CREATE " , " TRIGGER " , MatchAny , " INSTEAD " , " OF " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " ON " , " OR " ) ;
2010-02-26 03:01:40 +01:00
/*
* complete CREATE TRIGGER < name > BEFORE , AFTER event ON with a list of
* tables
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( TailMatches6 ( " CREATE " , " TRIGGER " , MatchAny , " BEFORE|AFTER " , MatchAny , " ON " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
2011-02-24 13:05:40 +01:00
/* complete CREATE TRIGGER ... INSTEAD OF event ON with a list of views */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( TailMatches7 ( " CREATE " , " TRIGGER " , MatchAny , " INSTEAD " , " OF " , MatchAny , " ON " ) )
2011-02-24 13:05:40 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_views , NULL ) ;
2016-11-04 17:02:07 +01:00
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches2 ( " ON " , MatchAny ) )
COMPLETE_WITH_LIST7 ( " NOT DEFERRABLE " , " DEFERRABLE " , " INITIALLY " ,
" REFERENCING " , " FOR " , " WHEN ( " , " EXECUTE PROCEDURE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & &
( TailMatches1 ( " DEFERRABLE " ) | | TailMatches2 ( " INITIALLY " , " IMMEDIATE|DEFERRED " ) ) )
COMPLETE_WITH_LIST4 ( " REFERENCING " , " FOR " , " WHEN ( " , " EXECUTE PROCEDURE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches1 ( " REFERENCING " ) )
COMPLETE_WITH_LIST2 ( " OLD TABLE " , " NEW TABLE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches2 ( " OLD|NEW " , " TABLE " ) )
COMPLETE_WITH_CONST ( " AS " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & &
( TailMatches5 ( " REFERENCING " , " OLD " , " TABLE " , " AS " , MatchAny ) | |
TailMatches4 ( " REFERENCING " , " OLD " , " TABLE " , MatchAny ) ) )
COMPLETE_WITH_LIST4 ( " NEW TABLE " , " FOR " , " WHEN ( " , " EXECUTE PROCEDURE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & &
( TailMatches5 ( " REFERENCING " , " NEW " , " TABLE " , " AS " , MatchAny ) | |
TailMatches4 ( " REFERENCING " , " NEW " , " TABLE " , MatchAny ) ) )
COMPLETE_WITH_LIST4 ( " OLD TABLE " , " FOR " , " WHEN ( " , " EXECUTE PROCEDURE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & &
( TailMatches9 ( " REFERENCING " , " OLD|NEW " , " TABLE " , " AS " , MatchAny , " OLD|NEW " , " TABLE " , " AS " , MatchAny ) | |
TailMatches8 ( " REFERENCING " , " OLD|NEW " , " TABLE " , MatchAny , " OLD|NEW " , " TABLE " , " AS " , MatchAny ) | |
TailMatches8 ( " REFERENCING " , " OLD|NEW " , " TABLE " , " AS " , MatchAny , " OLD|NEW " , " TABLE " , MatchAny ) | |
TailMatches7 ( " REFERENCING " , " OLD|NEW " , " TABLE " , MatchAny , " OLD|NEW " , " TABLE " , MatchAny ) ) )
COMPLETE_WITH_LIST3 ( " FOR " , " WHEN ( " , " EXECUTE PROCEDURE " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches1 ( " FOR " ) )
COMPLETE_WITH_LIST3 ( " EACH " , " ROW " , " STATEMENT " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches2 ( " FOR " , " EACH " ) )
COMPLETE_WITH_LIST2 ( " ROW " , " STATEMENT " ) ;
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & &
( TailMatches3 ( " FOR " , " EACH " , " ROW|STATEMENT " ) | |
TailMatches2 ( " FOR " , " ROW|STATEMENT " ) ) )
COMPLETE_WITH_LIST2 ( " WHEN ( " , " EXECUTE PROCEDURE " ) ;
2010-02-17 05:09:40 +01:00
/* complete CREATE TRIGGER ... EXECUTE with PROCEDURE */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches1 ( " EXECUTE " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " PROCEDURE " ) ;
2016-11-04 17:02:07 +01:00
else if ( HeadMatches2 ( " CREATE " , " TRIGGER " ) & & TailMatches2 ( " EXECUTE " , " PROCEDURE " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_functions , NULL ) ;
2005-08-14 20:49:30 +02:00
2012-04-18 15:55:01 +02:00
/* CREATE ROLE,USER,GROUP <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " CREATE " , " ROLE|GROUP|USER " , MatchAny ) & &
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
! TailMatches2 ( " USER " , " MAPPING " ) )
2005-08-14 20:49:30 +02:00
{
static const char * const list_CREATEROLE [ ] =
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
{ " ADMIN " , " BYPASSRLS " , " CONNECTION LIMIT " , " CREATEDB " , " CREATEROLE " ,
2015-10-22 18:33:51 +02:00
" ENCRYPTED " , " IN " , " INHERIT " , " LOGIN " , " NOBYPASSRLS " ,
" NOCREATEDB " , " NOCREATEROLE " , " NOINHERIT " ,
2015-06-19 17:11:22 +02:00
" NOLOGIN " , " NOREPLICATION " , " NOSUPERUSER " , " PASSWORD " ,
" REPLICATION " , " ROLE " , " SUPERUSER " , " SYSID " , " UNENCRYPTED " ,
2015-07-03 21:48:18 +02:00
" VALID UNTIL " , " WITH " , NULL } ;
2005-10-15 04:49:52 +02:00
COMPLETE_WITH_LIST ( list_CREATEROLE ) ;
2005-08-14 20:49:30 +02:00
}
2005-10-15 04:49:52 +02:00
2012-04-18 15:55:01 +02:00
/* CREATE ROLE,USER,GROUP <name> WITH */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " ROLE|GROUP|USER " , MatchAny , " WITH " ) )
2012-04-18 15:55:01 +02:00
{
/* Similar to the above, but don't complete "WITH" again. */
static const char * const list_CREATEROLE_WITH [ ] =
Code review for row security.
Buildfarm member tick identified an issue where the policies in the
relcache for a relation were were being replaced underneath a running
query, leading to segfaults while processing the policies to be added
to a query. Similar to how TupleDesc RuleLocks are handled, add in a
equalRSDesc() function to check if the policies have actually changed
and, if not, swap back the rsdesc field (using the original instead of
the temporairly built one; the whole structure is swapped and then
specific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYS
for me and should resolve the buildfarm error.
In addition to addressing this, add a new chapter in Data Definition
under Privileges which explains row security and provides examples of
its usage, change \d to always list policies (even if row security is
disabled- but note that it is disabled, or enabled with no policies),
rework check_role_for_policy (it really didn't need the entire policy,
but it did need to be using has_privs_of_role()), and change the field
in pg_class to relrowsecurity from relhasrowsecurity, based on
Heikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY in
pg_restore when talking to a 9.5+ server, list Bypass RLS in \du, and
document --enable-row-security options for pg_dump and pg_restore.
Lastly, fix a number of minor whitespace and typo issues from Heikki,
Dimitri, add a missing #include, per Peter E, fix a few minor
variable-assigned-but-not-used and resource leak issues from Coverity
and add tab completion for role attribute bypassrls as well.
2014-09-24 22:32:22 +02:00
{ " ADMIN " , " BYPASSRLS " , " CONNECTION LIMIT " , " CREATEDB " , " CREATEROLE " ,
2015-10-22 18:33:51 +02:00
" ENCRYPTED " , " IN " , " INHERIT " , " LOGIN " , " NOBYPASSRLS " ,
" NOCREATEDB " , " NOCREATEROLE " , " NOINHERIT " ,
2015-06-19 17:11:22 +02:00
" NOLOGIN " , " NOREPLICATION " , " NOSUPERUSER " , " PASSWORD " ,
" REPLICATION " , " ROLE " , " SUPERUSER " , " SYSID " , " UNENCRYPTED " ,
2015-07-03 21:48:18 +02:00
" VALID UNTIL " , NULL } ;
2012-04-18 15:55:01 +02:00
COMPLETE_WITH_LIST ( list_CREATEROLE_WITH ) ;
}
2005-10-15 04:49:52 +02:00
/*
* complete CREATE ROLE , USER , GROUP < name > ENCRYPTED , UNENCRYPTED with
* PASSWORD
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " ROLE|USER|GROUP " , MatchAny , " ENCRYPTED|UNENCRYPTED " ) )
2005-10-15 04:49:52 +02:00
COMPLETE_WITH_CONST ( " PASSWORD " ) ;
2005-08-14 20:49:30 +02:00
/* complete CREATE ROLE,USER,GROUP <name> IN with ROLE,GROUP */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " ROLE|USER|GROUP " , MatchAny , " IN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " GROUP " , " ROLE " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* CREATE VIEW --- is allowed inside CREATE SCHEMA, so use TailMatches */
2005-08-14 20:49:30 +02:00
/* Complete CREATE VIEW <name> with AS */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " CREATE " , " VIEW " , MatchAny ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " AS " ) ;
/* Complete "CREATE VIEW <sth> AS with "SELECT" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " CREATE " , " VIEW " , MatchAny , " AS " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " SELECT " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2013-03-04 01:23:31 +01:00
/* CREATE MATERIALIZED VIEW */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CREATE " , " MATERIALIZED " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " VIEW " ) ;
/* Complete CREATE MATERIALIZED VIEW <name> with AS */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " MATERIALIZED " , " VIEW " , MatchAny ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " AS " ) ;
/* Complete "CREATE MATERIALIZED VIEW <sth> AS with "SELECT" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " MATERIALIZED " , " VIEW " , MatchAny , " AS " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " SELECT " ) ;
2014-04-14 14:44:21 +02:00
/* CREATE EVENT TRIGGER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " CREATE " , " EVENT " ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_CONST ( " TRIGGER " ) ;
/* Complete CREATE EVENT TRIGGER <name> with ON */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " EVENT " , " TRIGGER " , MatchAny ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
/* Complete CREATE EVENT TRIGGER <name> ON with event_type */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE " , " EVENT " , " TRIGGER " , MatchAny , " ON " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " ddl_command_start " , " ddl_command_end " , " sql_drop " ) ;
2014-04-14 14:44:21 +02:00
2017-03-01 14:51:57 +01:00
/* DEALLOCATE */
else if ( Matches1 ( " DEALLOCATE " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_prepared_statements ) ;
2005-05-18 06:47:40 +02:00
/* DECLARE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DECLARE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " BINARY " , " INSENSITIVE " , " SCROLL " , " NO SCROLL " ,
" CURSOR " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( HeadMatches1 ( " DECLARE " ) & & TailMatches1 ( " CURSOR " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " WITH HOLD " , " WITHOUT HOLD " , " FOR " ) ;
2005-05-18 06:47:40 +02:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* DELETE --- can be inside EXPLAIN, RULE, etc */
/* ... despite which, only complete DELETE with FROM at start of line */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " DELETE " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " FROM " ) ;
/* Complete DELETE FROM with a list of tables */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " DELETE " , " FROM " ) )
2013-10-23 19:16:25 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_updatables , NULL ) ;
2005-04-07 03:51:41 +02:00
/* Complete DELETE FROM <table> */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " DELETE " , " FROM " , MatchAny ) )
2015-12-21 00:29:51 +01:00
COMPLETE_WITH_LIST2 ( " USING " , " WHERE " ) ;
2005-04-07 03:51:41 +02:00
/* XXX: implement tab completion for DELETE ... USING */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2007-04-26 18:13:15 +02:00
/* DISCARD */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " DISCARD " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " ALL " , " PLANS " , " SEQUENCES " , " TEMP " ) ;
2007-04-26 18:13:15 +02:00
2010-02-15 03:55:01 +01:00
/* DO */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " DO " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " LANGUAGE " ) ;
2010-02-15 03:55:01 +01:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* DROP */
/* Complete DROP object with CASCADE / RESTRICT */
else if ( Matches3 ( " DROP " ,
2017-01-19 18:00:00 +01:00
" COLLATION|CONVERSION|DOMAIN|EXTENSION|LANGUAGE|PUBLICATION|SCHEMA|SEQUENCE|SERVER|TABLE|TYPE|VIEW " ,
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
MatchAny ) | |
2016-03-28 18:32:13 +02:00
Matches4 ( " DROP " , " ACCESS " , " METHOD " , MatchAny ) | |
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
( Matches4 ( " DROP " , " AGGREGATE|FUNCTION " , MatchAny , MatchAny ) & &
ends_with ( prev_wd , ' ) ' ) ) | |
Matches4 ( " DROP " , " EVENT " , " TRIGGER " , MatchAny ) | |
Matches5 ( " DROP " , " FOREIGN " , " DATA " , " WRAPPER " , MatchAny ) | |
Matches4 ( " DROP " , " FOREIGN " , " TABLE " , MatchAny ) | |
Matches5 ( " DROP " , " TEXT " , " SEARCH " , " CONFIGURATION|DICTIONARY|PARSER|TEMPLATE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " CASCADE " , " RESTRICT " ) ;
/* help completing some of the variants */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " AGGREGATE|FUNCTION " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " DROP " , " AGGREGATE|FUNCTION " , MatchAny , " ( " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_FUNCTION_ARG ( prev2_wd ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DROP " , " FOREIGN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " TABLE " ) ;
2013-03-04 01:23:31 +01:00
2016-01-17 02:46:14 +01:00
/* DROP INDEX */
else if ( Matches2 ( " DROP " , " INDEX " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes ,
" UNION SELECT 'CONCURRENTLY' " ) ;
else if ( Matches3 ( " DROP " , " INDEX " , " CONCURRENTLY " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes , NULL ) ;
else if ( Matches3 ( " DROP " , " INDEX " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " CASCADE " , " RESTRICT " ) ;
else if ( Matches4 ( " DROP " , " INDEX " , " CONCURRENTLY " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " CASCADE " , " RESTRICT " ) ;
2013-03-04 01:23:31 +01:00
/* DROP MATERIALIZED VIEW */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DROP " , " MATERIALIZED " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " VIEW " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " MATERIALIZED " , " VIEW " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews , NULL ) ;
2006-04-02 11:02:41 +02:00
/* DROP OWNED BY */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DROP " , " OWNED " ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_CONST ( " BY " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " OWNED " , " BY " ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2005-12-08 22:33:58 +01:00
2017-03-16 23:54:28 +01:00
/* DROP TEXT SEARCH */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " TEXT " , " SEARCH " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " CONFIGURATION " , " DICTIONARY " , " PARSER " , " TEMPLATE " ) ;
2007-11-15 22:14:46 +01:00
2014-06-23 22:47:39 +02:00
/* DROP TRIGGER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " TRIGGER " , MatchAny ) )
2014-06-23 22:47:39 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " DROP " , " TRIGGER " , MatchAny , " ON " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_trigger ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " DROP " , " TRIGGER " , MatchAny , " ON " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " CASCADE " , " RESTRICT " ) ;
2014-06-23 22:47:39 +02:00
2016-06-07 23:59:34 +02:00
/* DROP ACCESS METHOD */
else if ( Matches2 ( " DROP " , " ACCESS " ) )
COMPLETE_WITH_CONST ( " METHOD " ) ;
else if ( Matches3 ( " DROP " , " ACCESS " , " METHOD " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_access_methods ) ;
2014-04-14 14:44:21 +02:00
/* DROP EVENT TRIGGER */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DROP " , " EVENT " ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_CONST ( " TRIGGER " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " EVENT " , " TRIGGER " ) )
2014-04-14 14:44:21 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_event_triggers ) ;
2015-07-20 15:37:17 +02:00
/* DROP POLICY <name> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " DROP " , " POLICY " ) )
2015-07-20 15:37:17 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_policies ) ;
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
/* DROP POLICY <name> ON */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " POLICY " , MatchAny ) )
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
/* DROP POLICY <name> ON <table> */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " DROP " , " POLICY " , MatchAny , " ON " ) )
2015-07-20 15:37:17 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_policy ) ;
}
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
2014-06-23 22:47:39 +02:00
/* DROP RULE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " DROP " , " RULE " , MatchAny ) )
2014-06-23 22:47:39 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " DROP " , " RULE " , MatchAny , " ON " ) )
2014-06-23 22:47:39 +02:00
{
completion_info_charp = prev2_wd ;
COMPLETE_WITH_QUERY ( Query_for_list_of_tables_for_rule ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " DROP " , " RULE " , MatchAny , " ON " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " CASCADE " , " RESTRICT " ) ;
2014-06-23 22:47:39 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* EXECUTE */
else if ( Matches1 ( " EXECUTE " ) )
2011-10-24 01:25:34 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_prepared_statements ) ;
2005-05-18 06:47:40 +02:00
/* EXPLAIN */
2005-10-15 04:49:52 +02:00
2000-04-12 19:17:23 +02:00
/*
2005-05-18 06:47:40 +02:00
* Complete EXPLAIN [ ANALYZE ] [ VERBOSE ] with list of EXPLAIN - able commands
2000-04-12 19:17:23 +02:00
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " EXPLAIN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST7 ( " SELECT " , " INSERT " , " DELETE " , " UPDATE " , " DECLARE " ,
" ANALYZE " , " VERBOSE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " EXPLAIN " , " ANALYZE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST6 ( " SELECT " , " INSERT " , " DELETE " , " UPDATE " , " DECLARE " ,
" VERBOSE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " EXPLAIN " , " VERBOSE " ) | |
Matches3 ( " EXPLAIN " , " ANALYZE " , " VERBOSE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " SELECT " , " INSERT " , " DELETE " , " UPDATE " , " DECLARE " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* FETCH && MOVE */
2000-04-12 19:17:23 +02:00
/* Complete FETCH with one of FORWARD, BACKWARD, RELATIVE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " FETCH|MOVE " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST4 ( " ABSOLUTE " , " BACKWARD " , " FORWARD " , " RELATIVE " ) ;
2000-04-12 19:17:23 +02:00
/* Complete FETCH <sth> with one of ALL, NEXT, PRIOR */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " FETCH|MOVE " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " ALL " , " NEXT " , " PRIOR " ) ;
2000-04-12 19:17:23 +02:00
/*
2005-10-15 04:49:52 +02:00
* Complete FETCH < sth1 > < sth2 > with " FROM " or " IN " . These are equivalent ,
* but we may as well tab - complete both : perhaps some users prefer one
* variant or the other .
2000-04-12 19:17:23 +02:00
*/
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " FETCH|MOVE " , MatchAny , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " FROM " , " IN " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2008-12-19 17:25:19 +01:00
/* FOREIGN DATA WRAPPER */
/* applies in ALTER/DROP FDW and in CREATE SERVER */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " FOREIGN " , " DATA " , " WRAPPER " ) & &
! TailMatches4 ( " CREATE " , MatchAny , MatchAny , MatchAny ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_fdws ) ;
2016-01-23 12:57:42 +01:00
/* applies in CREATE SERVER */
else if ( TailMatches4 ( " FOREIGN " , " DATA " , " WRAPPER " , MatchAny ) & &
HeadMatches2 ( " CREATE " , " SERVER " ) )
COMPLETE_WITH_CONST ( " OPTIONS " ) ;
2008-12-19 17:25:19 +01:00
2011-01-02 05:48:11 +01:00
/* FOREIGN TABLE */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " FOREIGN " , " TABLE " ) & &
! TailMatches3 ( " CREATE " , MatchAny , MatchAny ) )
2011-04-10 17:42:00 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_foreign_tables , NULL ) ;
2011-01-02 05:48:11 +01:00
2015-09-08 18:58:29 +02:00
/* FOREIGN SERVER */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " FOREIGN " , " SERVER " ) )
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_servers ) ;
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
/*
* GRANT and REVOKE are allowed inside CREATE SCHEMA and
* ALTER DEFAULT PRIVILEGES , so use TailMatches
*/
2012-01-21 18:46:55 +01:00
/* Complete GRANT/REVOKE with a list of roles and privileges */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " GRANT|REVOKE " ) )
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
/*
* With ALTER DEFAULT PRIVILEGES , restrict completion
* to grantable privileges ( can ' t grant roles )
*/
if ( HeadMatches3 ( " ALTER " , " DEFAULT " , " PRIVILEGES " ) )
COMPLETE_WITH_LIST10 ( " SELECT " , " INSERT " , " UPDATE " ,
" DELETE " , " TRUNCATE " , " REFERENCES " , " TRIGGER " ,
" EXECUTE " , " USAGE " , " ALL " ) ;
else
COMPLETE_WITH_QUERY ( Query_for_list_of_roles
2012-01-21 18:46:55 +01:00
" UNION SELECT 'SELECT' "
" UNION SELECT 'INSERT' "
" UNION SELECT 'UPDATE' "
" UNION SELECT 'DELETE' "
" UNION SELECT 'TRUNCATE' "
" UNION SELECT 'REFERENCES' "
" UNION SELECT 'TRIGGER' "
" UNION SELECT 'CREATE' "
" UNION SELECT 'CONNECT' "
" UNION SELECT 'TEMPORARY' "
" UNION SELECT 'EXECUTE' "
" UNION SELECT 'USAGE' "
" UNION SELECT 'ALL' " ) ;
2012-06-10 21:20:04 +02:00
/*
* Complete GRANT / REVOKE < privilege > with " ON " , GRANT / REVOKE < role > with
* TO / FROM
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " GRANT|REVOKE " , MatchAny ) )
2012-01-21 18:46:55 +01:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches1 ( " SELECT|INSERT|UPDATE|DELETE|TRUNCATE|REFERENCES|TRIGGER|CREATE|CONNECT|TEMPORARY|TEMP|EXECUTE|USAGE|ALL " ) )
2012-01-21 18:46:55 +01:00
COMPLETE_WITH_CONST ( " ON " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " GRANT " , MatchAny ) )
COMPLETE_WITH_CONST ( " TO " ) ;
2012-01-21 18:46:55 +01:00
else
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " FROM " ) ;
2012-01-21 18:46:55 +01:00
}
2000-04-12 19:17:23 +02:00
/*
2015-09-08 18:58:29 +02:00
* Complete GRANT / REVOKE < sth > ON with a list of tables , views , and
* sequences .
2002-08-10 05:56:24 +02:00
*
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* Keywords like DATABASE , FUNCTION , LANGUAGE and SCHEMA added to query
* result via UNION ; seems to work intuitively .
2003-08-04 02:43:34 +02:00
*
2005-10-15 04:49:52 +02:00
* Note : GRANT / REVOKE can get quite complex ; tab - completion as implemented
* here will only work if the privilege list contains exactly one
2015-09-08 18:58:29 +02:00
* privilege .
2000-04-12 19:17:23 +02:00
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " GRANT|REVOKE " , MatchAny , " ON " ) )
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
/*
* With ALTER DEFAULT PRIVILEGES , restrict completion
* to the kinds of objects supported .
*/
if ( HeadMatches3 ( " ALTER " , " DEFAULT " , " PRIVILEGES " ) )
COMPLETE_WITH_LIST4 ( " TABLES " , " SEQUENCES " , " FUNCTIONS " , " TYPES " ) ;
else
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tsvmf ,
2015-09-08 18:58:29 +02:00
" UNION SELECT 'ALL FUNCTIONS IN SCHEMA' "
" UNION SELECT 'ALL SEQUENCES IN SCHEMA' "
" UNION SELECT 'ALL TABLES IN SCHEMA' "
2003-10-29 00:35:52 +01:00
" UNION SELECT 'DATABASE' "
2011-12-19 23:05:19 +01:00
" UNION SELECT 'DOMAIN' "
2008-12-19 17:25:19 +01:00
" UNION SELECT 'FOREIGN DATA WRAPPER' "
" UNION SELECT 'FOREIGN SERVER' "
2003-10-29 00:35:52 +01:00
" UNION SELECT 'FUNCTION' "
" UNION SELECT 'LANGUAGE' "
2009-12-11 04:34:57 +01:00
" UNION SELECT 'LARGE OBJECT' "
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
" UNION SELECT 'SCHEMA' "
2015-09-08 18:58:29 +02:00
" UNION SELECT 'SEQUENCE' "
" UNION SELECT 'TABLE' "
2011-12-19 23:05:19 +01:00
" UNION SELECT 'TABLESPACE' "
" UNION SELECT 'TYPE' " ) ;
2015-09-08 18:58:29 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " GRANT|REVOKE " , MatchAny , " ON " , " ALL " ) )
COMPLETE_WITH_LIST3 ( " FUNCTIONS IN SCHEMA " , " SEQUENCES IN SCHEMA " ,
" TABLES IN SCHEMA " ) ;
2010-02-17 05:09:40 +01:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " GRANT|REVOKE " , MatchAny , " ON " , " FOREIGN " ) )
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " SERVER " ) ;
2003-03-27 17:45:01 +01:00
2015-09-08 18:58:29 +02:00
/*
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* Complete " GRANT/REVOKE * ON DATABASE/DOMAIN/... " with a list of
2015-09-08 18:58:29 +02:00
* appropriate objects .
*
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
* Complete " GRANT/REVOKE * ON * " with " TO/FROM " .
2015-09-08 18:58:29 +02:00
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " GRANT|REVOKE " , MatchAny , " ON " , MatchAny ) )
2003-03-27 17:45:01 +01:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches1 ( " DATABASE " ) )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_databases ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " DOMAIN " ) )
2011-12-19 23:05:19 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_domains , NULL ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " FUNCTION " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_functions , NULL ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " LANGUAGE " ) )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_languages ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " SCHEMA " ) )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_schemas ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " SEQUENCE " ) )
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_sequences , NULL ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " TABLE " ) )
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tsvmf , NULL ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " TABLESPACE " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_tablespaces ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " TYPE " ) )
2011-12-19 23:05:19 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_datatypes , NULL ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " GRANT " , MatchAny , MatchAny , MatchAny ) )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_CONST ( " TO " ) ;
2005-05-18 06:47:40 +02:00
else
COMPLETE_WITH_CONST ( " FROM " ) ;
2003-03-27 17:45:01 +01:00
}
2000-04-12 19:17:23 +02:00
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/*
* Complete " GRANT/REVOKE ... TO/FROM " with username , PUBLIC ,
* CURRENT_USER , or SESSION_USER .
*/
else if ( ( HeadMatches1 ( " GRANT " ) & & TailMatches1 ( " TO " ) ) | |
( HeadMatches1 ( " REVOKE " ) & & TailMatches1 ( " FROM " ) ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_grant_roles ) ;
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
2016-12-24 03:01:29 +01:00
/* Complete "ALTER DEFAULT PRIVILEGES ... GRANT/REVOKE ... TO/FROM */
else if ( HeadMatches3 ( " ALTER " , " DEFAULT " , " PRIVILEGES " ) & & TailMatches1 ( " TO|FROM " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_grant_roles ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
/* Complete "GRANT/REVOKE ... ON * *" with TO/FROM */
else if ( HeadMatches1 ( " GRANT " ) & & TailMatches3 ( " ON " , MatchAny , MatchAny ) )
COMPLETE_WITH_CONST ( " TO " ) ;
else if ( HeadMatches1 ( " REVOKE " ) & & TailMatches3 ( " ON " , MatchAny , MatchAny ) )
COMPLETE_WITH_CONST ( " FROM " ) ;
2015-09-08 18:58:29 +02:00
/* Complete "GRANT/REVOKE * ON ALL * IN SCHEMA *" with TO/FROM */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches8 ( " GRANT|REVOKE " , MatchAny , " ON " , " ALL " , MatchAny , " IN " , " SCHEMA " , MatchAny ) )
2010-02-17 05:09:40 +01:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches8 ( " GRANT " , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny ) )
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
2010-02-17 05:09:40 +01:00
else
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_CONST ( " FROM " ) ;
}
/* Complete "GRANT/REVOKE * ON FOREIGN DATA WRAPPER *" with TO/FROM */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches7 ( " GRANT|REVOKE " , MatchAny , " ON " , " FOREIGN " , " DATA " , " WRAPPER " , MatchAny ) )
2015-09-08 18:58:29 +02:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches7 ( " GRANT " , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_CONST ( " TO " ) ;
2015-09-08 18:58:29 +02:00
else
COMPLETE_WITH_CONST ( " FROM " ) ;
2010-02-17 05:09:40 +01:00
}
2015-09-08 18:58:29 +02:00
/* Complete "GRANT/REVOKE * ON FOREIGN SERVER *" with TO/FROM */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches6 ( " GRANT|REVOKE " , MatchAny , " ON " , " FOREIGN " , " SERVER " , MatchAny ) )
2010-02-17 05:09:40 +01:00
{
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches6 ( " GRANT " , MatchAny , MatchAny , MatchAny , MatchAny , MatchAny ) )
2015-09-08 18:58:29 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
2010-02-17 05:09:40 +01:00
else
COMPLETE_WITH_CONST ( " FROM " ) ;
}
2005-05-18 06:47:40 +02:00
/* GROUP BY */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " FROM " , MatchAny , " GROUP " ) )
2005-05-18 06:47:40 +02:00
COMPLETE_WITH_CONST ( " BY " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2014-07-10 21:01:31 +02:00
/* IMPORT FOREIGN SCHEMA */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " IMPORT " ) )
2014-07-10 21:01:31 +02:00
COMPLETE_WITH_CONST ( " FOREIGN SCHEMA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " IMPORT " , " FOREIGN " ) )
2014-07-10 21:01:31 +02:00
COMPLETE_WITH_CONST ( " SCHEMA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* INSERT --- can be inside EXPLAIN, RULE, etc */
2000-04-12 19:17:23 +02:00
/* Complete INSERT with "INTO" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " INSERT " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " INTO " ) ;
/* Complete INSERT INTO with table names */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " INSERT " , " INTO " ) )
2013-10-23 19:16:25 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_updatables , NULL ) ;
2002-07-30 18:35:05 +02:00
/* Complete "INSERT INTO <table> (" with attribute names */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " INSERT " , " INTO " , MatchAny , " ( " ) )
2010-02-17 05:09:40 +01:00
COMPLETE_WITH_ATTR ( prev2_wd , " " ) ;
2001-10-25 07:50:21 +02:00
/*
2010-02-26 03:01:40 +01:00
* Complete INSERT INTO < table > with " ( " or " VALUES " or " SELECT " or
* " TABLE " or " DEFAULT VALUES "
2001-10-25 07:50:21 +02:00
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " INSERT " , " INTO " , MatchAny ) )
COMPLETE_WITH_LIST5 ( " ( " , " DEFAULT VALUES " , " SELECT " , " TABLE " , " VALUES " ) ;
2009-06-11 16:49:15 +02:00
/*
* Complete INSERT INTO < table > ( attribs ) with " VALUES " or " SELECT " or
* " TABLE "
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " INSERT " , " INTO " , MatchAny , MatchAny ) & &
ends_with ( prev_wd , ' ) ' ) )
COMPLETE_WITH_LIST3 ( " SELECT " , " TABLE " , " VALUES " ) ;
2002-07-30 18:35:05 +02:00
2000-04-12 19:17:23 +02:00
/* Insert an open parenthesis after "VALUES" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " VALUES " ) & & ! TailMatches2 ( " DEFAULT " , " VALUES " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* LOCK */
2002-07-30 18:35:05 +02:00
/* Complete LOCK [TABLE] with a list of tables */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " LOCK " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables ,
" UNION SELECT 'TABLE' " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " LOCK " , " TABLE " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , " " ) ;
2002-07-30 18:35:05 +02:00
/* For the following, handle the case of a single table only for now */
/* Complete LOCK [TABLE] <table> with "IN" */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " LOCK " , MatchAnyExcept ( " TABLE " ) ) | |
Matches3 ( " LOCK " , " TABLE " , MatchAny ) )
2002-09-04 22:31:48 +02:00
COMPLETE_WITH_CONST ( " IN " ) ;
2002-07-30 18:35:05 +02:00
/* Complete LOCK [TABLE] <table> IN with a lock mode */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " LOCK " , MatchAny , " IN " ) | |
Matches4 ( " LOCK " , " TABLE " , MatchAny , " IN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST8 ( " ACCESS SHARE MODE " ,
" ROW SHARE MODE " , " ROW EXCLUSIVE MODE " ,
" SHARE UPDATE EXCLUSIVE MODE " , " SHARE MODE " ,
" SHARE ROW EXCLUSIVE MODE " ,
" EXCLUSIVE MODE " , " ACCESS EXCLUSIVE MODE " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2016-11-03 16:42:13 +01:00
/* Complete LOCK [TABLE] <table> IN ACCESS|ROW with rest of lock mode */
else if ( Matches4 ( " LOCK " , MatchAny , " IN " , " ACCESS|ROW " ) | |
Matches5 ( " LOCK " , " TABLE " , MatchAny , " IN " , " ACCESS|ROW " ) )
COMPLETE_WITH_LIST2 ( " EXCLUSIVE MODE " , " SHARE MODE " ) ;
/* Complete LOCK [TABLE] <table> IN SHARE with rest of lock mode */
else if ( Matches4 ( " LOCK " , MatchAny , " IN " , " SHARE " ) | |
Matches5 ( " LOCK " , " TABLE " , MatchAny , " IN " , " SHARE " ) )
COMPLETE_WITH_LIST3 ( " MODE " , " ROW EXCLUSIVE MODE " ,
" UPDATE EXCLUSIVE MODE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* NOTIFY --- can be inside EXPLAIN, RULE, etc */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " NOTIFY " ) )
2010-02-16 23:34:57 +01:00
COMPLETE_WITH_QUERY ( " SELECT pg_catalog.quote_ident(channel) FROM pg_catalog.pg_listening_channels() AS channel WHERE substring(pg_catalog.quote_ident(channel),1,%d)='%s' " ) ;
2005-05-18 06:47:40 +02:00
2008-12-19 17:25:19 +01:00
/* OPTIONS */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " OPTIONS " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_CONST ( " ( " ) ;
2006-04-02 11:02:41 +02:00
/* OWNER TO - complete with available roles */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " OWNER " , " TO " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2005-05-18 06:47:40 +02:00
/* ORDER BY */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches3 ( " FROM " , MatchAny , " ORDER " ) )
2005-05-18 06:47:40 +02:00
COMPLETE_WITH_CONST ( " BY " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " FROM " , MatchAny , " ORDER " , " BY " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev3_wd , " " ) ;
2005-05-18 06:47:40 +02:00
/* PREPARE xx AS */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " PREPARE " , MatchAny , " AS " ) )
COMPLETE_WITH_LIST4 ( " SELECT " , " UPDATE " , " INSERT " , " DELETE FROM " ) ;
2005-05-18 06:47:40 +02:00
2010-01-25 19:23:10 +01:00
/*
* PREPARE TRANSACTION is missing on purpose . It ' s intended for transaction
* managers , not for manual use in interactive sessions .
*/
2006-04-02 11:02:41 +02:00
/* REASSIGN OWNED BY xxx TO yyy */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " REASSIGN " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " OWNED BY " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " REASSIGN " , " OWNED " ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_CONST ( " BY " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " REASSIGN " , " OWNED " , " BY " ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " REASSIGN " , " OWNED " , " BY " , MatchAny ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " REASSIGN " , " OWNED " , " BY " , MatchAny , " TO " ) )
2006-04-02 11:02:41 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2005-05-18 06:47:40 +02:00
2013-03-04 01:23:31 +01:00
/* REFRESH MATERIALIZED VIEW */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " REFRESH " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " MATERIALIZED VIEW " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " REFRESH " , " MATERIALIZED " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " VIEW " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " REFRESH " , " MATERIALIZED " , " VIEW " ) )
2013-07-16 19:55:44 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews ,
" UNION SELECT 'CONCURRENTLY' " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " REFRESH " , " MATERIALIZED " , " VIEW " , " CONCURRENTLY " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews , NULL ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " REFRESH " , " MATERIALIZED " , " VIEW " , MatchAny ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " WITH " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " REFRESH " , " MATERIALIZED " , " VIEW " , " CONCURRENTLY " , MatchAny ) )
2016-01-26 15:45:08 +01:00
COMPLETE_WITH_CONST ( " WITH " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " REFRESH " , " MATERIALIZED " , " VIEW " , MatchAny , " WITH " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " NO DATA " , " DATA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " REFRESH " , " MATERIALIZED " , " VIEW " , " CONCURRENTLY " , MatchAny , " WITH " ) )
2016-01-26 15:45:08 +01:00
COMPLETE_WITH_LIST2 ( " NO DATA " , " DATA " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches6 ( " REFRESH " , " MATERIALIZED " , " VIEW " , MatchAny , " WITH " , " NO " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_CONST ( " DATA " ) ;
2016-01-26 15:45:08 +01:00
else if ( Matches7 ( " REFRESH " , " MATERIALIZED " , " VIEW " , " CONCURRENTLY " , MatchAny , " WITH " , " NO " ) )
COMPLETE_WITH_CONST ( " DATA " ) ;
2013-03-04 01:23:31 +01:00
2000-06-25 16:25:51 +02:00
/* REINDEX */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " REINDEX " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST5 ( " TABLE " , " INDEX " , " SYSTEM " , " SCHEMA " , " DATABASE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " REINDEX " , " TABLE " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm , NULL ) ;
else if ( Matches2 ( " REINDEX " , " INDEX " ) )
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes , NULL ) ;
else if ( Matches2 ( " REINDEX " , " SCHEMA " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_schemas ) ;
else if ( Matches2 ( " REINDEX " , " SYSTEM|DATABASE " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_databases ) ;
2000-06-25 16:25:51 +02:00
2010-09-28 02:55:27 +02:00
/* SECURITY LABEL */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " SECURITY " ) )
2010-09-28 02:55:27 +02:00
COMPLETE_WITH_CONST ( " LABEL " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " SECURITY " , " LABEL " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " ON " , " FOR " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " SECURITY " , " LABEL " , " FOR " , MatchAny ) )
2010-09-28 02:55:27 +02:00
COMPLETE_WITH_CONST ( " ON " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " SECURITY " , " LABEL " , " ON " ) | |
Matches5 ( " SECURITY " , " LABEL " , " FOR " , MatchAny , " ON " ) )
2010-09-28 02:55:27 +02:00
{
static const char * const list_SECURITY_LABEL [ ] =
2015-12-25 14:56:01 +01:00
{ " TABLE " , " COLUMN " , " AGGREGATE " , " DATABASE " , " DOMAIN " ,
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
" EVENT TRIGGER " , " FOREIGN TABLE " , " FUNCTION " , " LARGE OBJECT " ,
" MATERIALIZED VIEW " , " LANGUAGE " , " ROLE " , " SCHEMA " ,
" SEQUENCE " , " TABLESPACE " , " TYPE " , " VIEW " , NULL } ;
2010-09-28 02:55:27 +02:00
COMPLETE_WITH_LIST ( list_SECURITY_LABEL ) ;
}
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " SECURITY " , " LABEL " , " ON " , MatchAny , MatchAny ) )
2010-09-28 02:55:27 +02:00
COMPLETE_WITH_CONST ( " IS " ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* SELECT */
2000-04-12 19:17:23 +02:00
/* naah . . . */
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* SET, RESET, SHOW */
2000-04-12 19:17:23 +02:00
/* Complete with a variable name */
2016-02-01 14:19:51 +01:00
else if ( TailMatches1 ( " SET|RESET " ) & & ! TailMatches3 ( " UPDATE " , MatchAny , " SET " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_set_vars ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " SHOW " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_show_vars ) ;
2003-01-10 23:03:30 +01:00
/* Complete "SET TRANSACTION" */
2016-09-01 23:10:30 +02:00
else if ( Matches2 ( " SET " , " TRANSACTION " ) )
COMPLETE_WITH_LIST5 ( " SNAPSHOT " , " ISOLATION LEVEL " , " READ " , " DEFERRABLE " , " NOT DEFERRABLE " ) ;
else if ( Matches2 ( " BEGIN|START " , " TRANSACTION " ) | |
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
Matches2 ( " BEGIN " , " WORK " ) | |
2016-09-01 23:10:30 +02:00
Matches1 ( " BEGIN " ) | |
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
Matches5 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " ) )
2016-09-01 23:10:30 +02:00
COMPLETE_WITH_LIST4 ( " ISOLATION LEVEL " , " READ " , " DEFERRABLE " , " NOT DEFERRABLE " ) ;
else if ( Matches3 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " NOT " ) | |
Matches2 ( " BEGIN " , " NOT " ) | |
Matches6 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " NOT " ) )
COMPLETE_WITH_CONST ( " DEFERRABLE " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " ISOLATION " ) | |
2016-09-01 23:10:30 +02:00
Matches2 ( " BEGIN " , " ISOLATION " ) | |
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
Matches6 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " ISOLATION " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " LEVEL " ) ;
2016-09-01 23:10:30 +02:00
else if ( Matches4 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " ISOLATION " , " LEVEL " ) | |
Matches3 ( " BEGIN " , " ISOLATION " , " LEVEL " ) | |
Matches7 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " ISOLATION " , " LEVEL " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST3 ( " READ " , " REPEATABLE READ " , " SERIALIZABLE " ) ;
2016-09-01 23:10:30 +02:00
else if ( Matches5 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " ISOLATION " , " LEVEL " , " READ " ) | |
Matches4 ( " BEGIN " , " ISOLATION " , " LEVEL " , " READ " ) | |
Matches8 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " ISOLATION " , " LEVEL " , " READ " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " UNCOMMITTED " , " COMMITTED " ) ;
2016-09-01 23:10:30 +02:00
else if ( Matches5 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " ISOLATION " , " LEVEL " , " REPEATABLE " ) | |
Matches4 ( " BEGIN " , " ISOLATION " , " LEVEL " , " REPEATABLE " ) | |
Matches8 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " ISOLATION " , " LEVEL " , " REPEATABLE " ) )
2003-11-06 23:08:15 +01:00
COMPLETE_WITH_CONST ( " READ " ) ;
2016-09-01 23:10:30 +02:00
else if ( Matches3 ( " SET|BEGIN|START " , " TRANSACTION|WORK " , " READ " ) | |
Matches2 ( " BEGIN " , " READ " ) | |
Matches6 ( " SET " , " SESSION " , " CHARACTERISTICS " , " AS " , " TRANSACTION " , " READ " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " ONLY " , " WRITE " ) ;
2012-09-15 04:11:17 +02:00
/* SET CONSTRAINTS */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " SET " , " CONSTRAINTS " ) )
2012-09-15 04:11:17 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_constraints_with_schema , " UNION SELECT 'ALL' " ) ;
2000-06-25 16:25:51 +02:00
/* Complete SET CONSTRAINTS <foo> with DEFERRED|IMMEDIATE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " SET " , " CONSTRAINTS " , MatchAny ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " DEFERRED " , " IMMEDIATE " ) ;
2005-08-14 20:49:30 +02:00
/* Complete SET ROLE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " SET " , " ROLE " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2001-05-08 23:06:43 +02:00
/* Complete SET SESSION with AUTHORIZATION or CHARACTERISTICS... */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " SET " , " SESSION " ) )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST2 ( " AUTHORIZATION " , " CHARACTERISTICS AS TRANSACTION " ) ;
2001-05-08 23:06:43 +02:00
/* Complete SET SESSION AUTHORIZATION with username */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " SET " , " SESSION " , " AUTHORIZATION " ) )
2006-02-12 16:25:04 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles " UNION SELECT 'DEFAULT' " ) ;
2005-11-18 17:31:11 +01:00
/* Complete RESET SESSION with AUTHORIZATION */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches2 ( " RESET " , " SESSION " ) )
2005-11-18 17:31:11 +01:00
COMPLETE_WITH_CONST ( " AUTHORIZATION " ) ;
2000-04-12 19:17:23 +02:00
/* Complete SET <var> with "TO" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches2 ( " SET " , MatchAny ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " TO " ) ;
2016-02-01 14:19:51 +01:00
/* Complete ALTER DATABASE|FUNCTION|ROLE|USER ... SET <name> */
else if ( HeadMatches2 ( " ALTER " , " DATABASE|FUNCTION|ROLE|USER " ) & &
TailMatches2 ( " SET " , MatchAny ) )
COMPLETE_WITH_LIST2 ( " FROM CURRENT " , " TO " ) ;
2000-04-12 19:17:23 +02:00
/* Suggest possible variable values */
2016-02-01 14:19:51 +01:00
else if ( TailMatches3 ( " SET " , MatchAny , " TO|= " ) )
2000-04-12 19:17:23 +02:00
{
2015-09-08 20:57:35 +02:00
/* special cased code for individual GUCs */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
if ( TailMatches2 ( " DateStyle " , " TO|= " ) )
2000-04-12 19:17:23 +02:00
{
2004-08-29 07:07:03 +02:00
static const char * const my_list [ ] =
2003-10-30 22:37:38 +01:00
{ " ISO " , " SQL " , " Postgres " , " German " ,
2005-10-15 04:49:52 +02:00
" YMD " , " DMY " , " MDY " ,
" US " , " European " , " NonEuropean " ,
2004-08-29 07:07:03 +02:00
" DEFAULT " , NULL } ;
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_LIST ( my_list ) ;
}
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " search_path " , " TO|= " ) )
2014-07-12 15:44:39 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_schemas
" AND nspname not like 'pg \\ _toast%%' "
" AND nspname not like 'pg \\ _temp%%' "
" UNION SELECT 'DEFAULT' " ) ;
2000-04-12 19:17:23 +02:00
else
{
2015-09-08 20:57:35 +02:00
/* generic, type based, GUC support */
char * guctype = get_guctype ( prev2_wd ) ;
if ( guctype & & strcmp ( guctype , " enum " ) = = 0 )
{
char querybuf [ 1024 ] ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
snprintf ( querybuf , sizeof ( querybuf ) , Query_for_enum , prev2_wd ) ;
2015-09-08 20:57:35 +02:00
COMPLETE_WITH_QUERY ( querybuf ) ;
}
else if ( guctype & & strcmp ( guctype , " bool " ) = = 0 )
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_LIST9 ( " on " , " off " , " true " , " false " , " yes " , " no " ,
" 1 " , " 0 " , " DEFAULT " ) ;
2015-09-08 20:57:35 +02:00
else
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
COMPLETE_WITH_CONST ( " DEFAULT " ) ;
2015-09-08 20:57:35 +02:00
if ( guctype )
free ( guctype ) ;
2000-04-12 19:17:23 +02:00
}
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2003-11-06 23:08:15 +01:00
/* START TRANSACTION */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " START " ) )
2003-11-06 23:08:15 +01:00
COMPLETE_WITH_CONST ( " TRANSACTION " ) ;
2011-10-24 13:22:59 +02:00
/* TABLE, but not TABLE embedded in other commands */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " TABLE " ) )
2011-10-24 13:22:59 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_relations , NULL ) ;
2015-06-22 20:13:56 +02:00
/* TABLESAMPLE */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " TABLESAMPLE " ) )
2015-06-22 20:13:56 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_tablesample_methods ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " TABLESAMPLE " , MatchAny ) )
2015-06-22 20:13:56 +02:00
COMPLETE_WITH_CONST ( " ( " ) ;
2000-06-25 16:25:51 +02:00
/* TRUNCATE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " TRUNCATE " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
2000-06-25 16:25:51 +02:00
/* UNLISTEN */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches1 ( " UNLISTEN " ) )
2010-02-16 23:34:57 +01:00
COMPLETE_WITH_QUERY ( " SELECT pg_catalog.quote_ident(channel) FROM pg_catalog.pg_listening_channels() AS channel WHERE substring(pg_catalog.quote_ident(channel),1,%d)='%s' UNION SELECT '*' " ) ;
2000-06-25 16:25:51 +02:00
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* UPDATE --- can be inside EXPLAIN, RULE, etc */
2000-04-12 19:17:23 +02:00
/* If prev. word is UPDATE suggest a list of tables */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " UPDATE " ) )
2010-12-14 04:37:55 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_updatables , NULL ) ;
2000-04-12 19:17:23 +02:00
/* Complete UPDATE <table> with "SET" */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( " UPDATE " , MatchAny ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_CONST ( " SET " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Complete UPDATE <table> SET with list of attributes */
else if ( TailMatches3 ( " UPDATE " , MatchAny , " SET " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev2_wd , " " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* UPDATE <table> SET <attr> = */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches4 ( " UPDATE " , MatchAny , " SET " , MatchAny ) )
2005-05-18 06:47:40 +02:00
COMPLETE_WITH_CONST ( " = " ) ;
2008-12-19 17:25:19 +01:00
/* USER MAPPING */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches3 ( " ALTER|CREATE|DROP " , " USER " , " MAPPING " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_CONST ( " FOR " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " CREATE " , " USER " , " MAPPING " , " FOR " ) )
2010-04-07 05:51:19 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles
" UNION SELECT 'CURRENT_USER' "
" UNION SELECT 'PUBLIC' "
" UNION SELECT 'USER' " ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches4 ( " ALTER|DROP " , " USER " , " MAPPING " , " FOR " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_user_mappings ) ;
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
else if ( Matches5 ( " CREATE|ALTER|DROP " , " USER " , " MAPPING " , " FOR " , MatchAny ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_CONST ( " SERVER " ) ;
2016-01-23 12:57:42 +01:00
else if ( Matches7 ( " CREATE|ALTER " , " USER " , " MAPPING " , " FOR " , MatchAny , " SERVER " , MatchAny ) )
COMPLETE_WITH_CONST ( " OPTIONS " ) ;
2008-12-19 17:25:19 +01:00
2005-05-18 06:47:40 +02:00
/*
* VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ]
* VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ ( column [ , . . . ] ) ] ]
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " VACUUM " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2003-10-29 00:35:52 +01:00
" UNION SELECT 'FULL' "
2005-05-18 06:47:40 +02:00
" UNION SELECT 'FREEZE' "
2003-10-29 00:35:52 +01:00
" UNION SELECT 'ANALYZE' "
" UNION SELECT 'VERBOSE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches2 ( " VACUUM " , " FULL|FREEZE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2005-05-18 06:47:40 +02:00
" UNION SELECT 'ANALYZE' "
" UNION SELECT 'VERBOSE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches3 ( " VACUUM " , " FULL|FREEZE " , " ANALYZE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2005-05-18 06:47:40 +02:00
" UNION SELECT 'VERBOSE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches3 ( " VACUUM " , " FULL|FREEZE " , " VERBOSE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2005-05-18 06:47:40 +02:00
" UNION SELECT 'ANALYZE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches2 ( " VACUUM " , " VERBOSE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2005-05-18 06:47:40 +02:00
" UNION SELECT 'ANALYZE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches2 ( " VACUUM " , " ANALYZE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm ,
2005-05-18 06:47:40 +02:00
" UNION SELECT 'VERBOSE' " ) ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( HeadMatches1 ( " VACUUM " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tm , NULL ) ;
2005-05-18 06:47:40 +02:00
2008-10-04 23:56:55 +02:00
/* WITH [RECURSIVE] */
2012-06-10 21:20:04 +02:00
/*
* Only match when WITH is the first word , as WITH may appear in many
* other contexts .
*/
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( Matches1 ( " WITH " ) )
2008-10-04 23:56:55 +02:00
COMPLETE_WITH_CONST ( " RECURSIVE " ) ;
2005-08-14 20:49:30 +02:00
/* ANALYZE */
In psql's tab completion, change most TailMatches patterns to Matches.
In the refactoring in commit d37b816dc9e8f976c8913296781e08cbd45c5af1,
we mostly kept to the original design whereby only the last few words
on the line were matched to identify a completable pattern. However,
after commit d854118c8df8c413d069f7e88bb01b9e18e4c8ed, there's really
no reason to do it like that: where it's sensible, we can use patterns
that expect to match the entire input line. And mostly, it's sensible.
Matching the entire line greatly reduces the odds of a false match that
leads to offering irrelevant completions. Moreover (though I've not
tried to measure this), it should make tab completion faster since
many of the patterns will be discarded after a single integer comparison
that finds that the wrong number of words appear on the line.
There are certain identifiable places where we still need to use
TailMatches because the statement in question is allowed to appear
embedded in a larger statement. These are just a small minority of
the existing patterns, though, so the benefit of switching where
possible is large.
It's possible that this patch has removed some within-line matching
behaviors that are in fact desirable, but we can put those back when
we get complaints. Most of the removed behaviors are certainly silly.
Michael Paquier, with some further adjustments by me
2016-01-05 02:08:08 +01:00
/* Complete with list of tables */
else if ( Matches1 ( " ANALYZE " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tmf , NULL ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2002-07-30 18:35:05 +02:00
/* WHERE */
/* Simple case of the word before the where being the table name */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches2 ( MatchAny , " WHERE " ) )
2006-02-12 08:21:40 +01:00
COMPLETE_WITH_ATTR ( prev2_wd , " " ) ;
2002-07-30 18:35:05 +02:00
1999-12-10 04:59:30 +01:00
/* ... FROM ... */
2003-03-27 17:45:01 +01:00
/* TODO: also include SRF ? */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " FROM " ) & & ! Matches3 ( " COPY| \\ copy " , MatchAny , " FROM " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tsvmf , NULL ) ;
1999-12-10 04:59:30 +01:00
2011-03-03 08:42:02 +01:00
/* ... JOIN ... */
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
else if ( TailMatches1 ( " JOIN " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tsvmf , NULL ) ;
2011-03-03 08:42:02 +01:00
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* Backslash commands */
2003-03-27 17:45:01 +01:00
/* TODO: \dc \dd \dl */
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ ? " ) )
COMPLETE_WITH_LIST_CS3 ( " commands " , " options " , " variables " ) ;
else if ( TailMatchesCS1 ( " \\ connect| \\ c " ) )
psql: fix \connect with URIs and conninfo strings
This is the second try at this, after fcef1617295 failed miserably and
had to be reverted: as it turns out, libpq cannot depend on libpgcommon
after all. Instead of shuffling code in the master branch, make that one
just like 9.4 and accept the duplication. (This was all my own mistake,
not the patch submitter's).
psql was already accepting conninfo strings as the first parameter in
\connect, but the way it worked wasn't sane; some of the other
parameters would get the previous connection's values, causing it to
connect to a completely unexpected server or, more likely, not finding
any server at all because of completely wrong combinations of
parameters.
Fix by explicitely checking for a conninfo-looking parameter in the
dbname position; if one is found, use its complete specification rather
than mix with the other arguments. Also, change tab-completion to not
try to complete conninfo/URI-looking "dbnames" and document that
conninfos are accepted as first argument.
There was a weak consensus to backpatch this, because while the behavior
of using the dbname as a conninfo is nowhere documented for \connect, it
is reasonable to expect that it works because it does work in many other
contexts. Therefore this is backpatched all the way back to 9.0.
Author: David Fetter, Andrew Dunstan. Some editorialization by me
(probably earning a Gierth's "Sloppy" badge in the process.)
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,
Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
{
if ( ! recognized_connection_string ( text ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_databases ) ;
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS2 ( " \\ connect| \\ c " , MatchAny ) )
psql: fix \connect with URIs and conninfo strings
This is the second try at this, after fcef1617295 failed miserably and
had to be reverted: as it turns out, libpq cannot depend on libpgcommon
after all. Instead of shuffling code in the master branch, make that one
just like 9.4 and accept the duplication. (This was all my own mistake,
not the patch submitter's).
psql was already accepting conninfo strings as the first parameter in
\connect, but the way it worked wasn't sane; some of the other
parameters would get the previous connection's values, causing it to
connect to a completely unexpected server or, more likely, not finding
any server at all because of completely wrong combinations of
parameters.
Fix by explicitely checking for a conninfo-looking parameter in the
dbname position; if one is found, use its complete specification rather
than mix with the other arguments. Also, change tab-completion to not
try to complete conninfo/URI-looking "dbnames" and document that
conninfos are accepted as first argument.
There was a weak consensus to backpatch this, because while the behavior
of using the dbname as a conninfo is nowhere documented for \connect, it
is reasonable to expect that it works because it does work in many other
contexts. Therefore this is backpatched all the way back to 9.0.
Author: David Fetter, Andrew Dunstan. Some editorialization by me
(probably earning a Gierth's "Sloppy" badge in the process.)
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,
Robert Haas, Andrew Dunstan.
2015-04-02 17:30:57 +02:00
{
if ( ! recognized_connection_string ( prev_wd ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ da* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_aggregates , NULL ) ;
2016-06-07 23:59:34 +02:00
else if ( TailMatchesCS1 ( " \\ dA* " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_access_methods ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ db* " ) )
Attached is the third version of my patch that adds/fixes several things
to/in the psql-tabcomplete code. This diff includes the still missing
tab-complete support for TABLESPACE I already sent earlier. New in this
version of the patch is a small adaption of the tab-complete code to
support the adjusted SAVEPOINT-Syntax commited by Tom, as well as
completion of the only half working (and I think only by accident)
tabcomplete-suppport for "BEGIN [ TRANSACTION | WORK ]".
below is a complete list of the things I have changed with this patch:
*) add tablespace support for CREATE/DROP/ALTER and \db
*) sync the list of possible commands following ALTER with the docs (by
adding
AGGREGATE,CONVERSATION,DOMAIN,FUNCTION,LANGUAGE,OPERATOR,SEQUENCE,TABLESPACE
and TYPE)
*) provide a list of valid users after "OWNER TO"
*) tab-complete support for ALTER (AGGREGATE|CONVERSION|FUNCTION)
*) basic tab-complete support for ALTER DOMAIN
*) provide a list of suitable indexes following ALTER TABLE <sth>
CLUSTER ON(?)
*) add "CLUSTER ON" and "SET" to the ALTER TABLE <sth> - tab-complete
list(fixes incorrect/wrong tab-complete with ALTER TABLE <sth> SET
+<TAB> too)
*) provide a list of possible indexes following ALTER TABLE <sth> CLUSTER ON
*) provide list of possible commands(WITHOUT CLUSTER,WITHOUT OIDS,
TABLESPACE) following ALTER TABLE <sth> SET
*) sync "COMMENT ON" with docs by adding "CAST","CONVERSION","FUNCTION"
*) add ABSOLUT to the list of possible commands after FETCH
*) "END" was missing from the sql-commands overview (though it had
completion support!) - i know it's depreciated but we have ABORT and
others still in ...
*) fixes small buglet with ALTER (TRIGGER|CLUSTER) ON autocomplete
(CLUSTER ON +<TAB> would produce CLUSTER ON ON - same for TRIGGER ON)
*) adapt to new SAVEPOINT syntax
*) fix incomplete Support for BEGIN [ TRANSACTION | WORK ]
Stefan Kaltenbrunn
2004-08-20 21:24:59 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_tablespaces ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dD* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_domains , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ des* " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_servers ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ deu* " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_user_mappings ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dew* " ) )
2008-12-19 17:25:19 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_fdws ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ df* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_functions , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dFd* " ) )
2007-09-14 06:25:24 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_ts_dictionaries ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dFp* " ) )
2007-09-14 06:25:24 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_ts_parsers ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dFt* " ) )
2007-09-14 06:25:24 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_ts_templates ) ;
2016-01-05 18:00:13 +01:00
/* must be at end of \dF alternatives: */
else if ( TailMatchesCS1 ( " \\ dF* " ) )
2009-04-06 17:50:59 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_ts_configurations ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ di* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_indexes , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dL* " ) )
2011-01-20 06:00:30 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_languages ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dn* " ) )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_schemas ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dp " ) | | TailMatchesCS1 ( " \\ z " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tsvmf , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ ds* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_sequences , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dt* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_tables , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dT* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_datatypes , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ du* " ) | | TailMatchesCS1 ( " \\ dg* " ) )
2005-08-14 20:49:30 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dv* " ) )
2003-10-30 22:37:38 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_views , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dx* " ) )
2013-08-15 18:24:25 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_extensions ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dm* " ) )
2013-03-04 01:23:31 +01:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_matviews , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dE* " ) )
2015-07-07 16:34:18 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_foreign_tables , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ dy* " ) )
2015-07-07 16:34:18 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_event_triggers ) ;
2009-04-06 17:50:59 +02:00
2016-01-05 18:00:13 +01:00
/* must be at end of \d alternatives: */
else if ( TailMatchesCS1 ( " \\ d* " ) )
2011-06-14 22:45:00 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_relations , NULL ) ;
2009-04-06 17:50:59 +02:00
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ ef " ) )
2009-04-08 06:05:16 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_functions , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ ev " ) )
2015-07-03 21:48:18 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_views , NULL ) ;
2009-04-08 06:05:16 +02:00
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ encoding " ) )
2003-06-12 03:38:08 +02:00
COMPLETE_WITH_QUERY ( Query_for_list_of_encodings ) ;
2017-03-16 23:54:28 +01:00
else if ( TailMatchesCS1 ( " \\ h| \\ help " ) )
2000-04-12 19:17:23 +02:00
COMPLETE_WITH_LIST ( sql_commands ) ;
2017-03-16 23:54:28 +01:00
else if ( TailMatchesCS2 ( " \\ h| \\ help " , MatchAny ) )
{
if ( TailMatches1 ( " DROP " ) )
matches = completion_matches ( text , drop_command_generator ) ;
else if ( TailMatches1 ( " ALTER " ) )
matches = completion_matches ( text , alter_command_generator ) ;
/* CREATE is recognized by tail match elsewhere, so doesn't need to be
* repeated here */
}
else if ( TailMatchesCS3 ( " \\ h| \\ help " , MatchAny , MatchAny ) )
{
if ( TailMatches2 ( " CREATE|DROP " , " ACCESS " ) )
COMPLETE_WITH_CONST ( " METHOD " ) ;
else if ( TailMatches2 ( " ALTER " , " DEFAULT " ) )
COMPLETE_WITH_CONST ( " PRIVILEGES " ) ;
else if ( TailMatches2 ( " CREATE|ALTER|DROP " , " EVENT " ) )
COMPLETE_WITH_CONST ( " TRIGGER " ) ;
else if ( TailMatches2 ( " CREATE|ALTER|DROP " , " FOREIGN " ) )
COMPLETE_WITH_LIST2 ( " DATA WRAPPER " , " TABLE " ) ;
else if ( TailMatches2 ( " ALTER " , " LARGE " ) )
COMPLETE_WITH_CONST ( " OBJECT " ) ;
else if ( TailMatches2 ( " CREATE|ALTER|DROP " , " MATERIALIZED " ) )
COMPLETE_WITH_CONST ( " VIEW " ) ;
else if ( TailMatches2 ( " CREATE|ALTER|DROP " , " TEXT " ) )
COMPLETE_WITH_CONST ( " SEARCH " ) ;
else if ( TailMatches2 ( " CREATE|ALTER|DROP " , " USER " ) )
COMPLETE_WITH_CONST ( " MAPPING FOR " ) ;
}
else if ( TailMatchesCS4 ( " \\ h| \\ help " , MatchAny , MatchAny , MatchAny ) )
{
if ( TailMatches3 ( " CREATE|ALTER|DROP " , " FOREIGN " , " DATA " ) )
COMPLETE_WITH_CONST ( " WRAPPER " ) ;
else if ( TailMatches3 ( " CREATE|ALTER|DROP " , " TEXT " , " SEARCH " ) )
COMPLETE_WITH_LIST4 ( " CONFIGURATION " , " DICTIONARY " , " PARSER " , " TEMPLATE " ) ;
else if ( TailMatches3 ( " CREATE|ALTER|DROP " , " USER " , " MAPPING " ) )
COMPLETE_WITH_CONST ( " FOR " ) ;
}
2016-08-18 17:29:16 +02:00
else if ( TailMatchesCS1 ( " \\ l* " ) & & ! TailMatchesCS1 ( " \\ lo* " ) )
COMPLETE_WITH_QUERY ( Query_for_list_of_databases ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ password " ) )
2005-12-18 03:17:16 +01:00
COMPLETE_WITH_QUERY ( Query_for_list_of_roles ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ pset " ) )
2000-04-12 19:17:23 +02:00
{
2004-08-29 07:07:03 +02:00
static const char * const my_list [ ] =
2013-11-19 15:44:14 +01:00
{ " border " , " columns " , " expanded " , " fieldsep " , " fieldsep_zero " ,
2014-05-06 18:12:18 +02:00
" footer " , " format " , " linestyle " , " null " , " numericlocale " ,
2016-06-23 22:10:15 +02:00
" pager " , " pager_min_lines " , " recordsep " , " recordsep_zero " ,
" tableattr " , " title " , " tuples_only " , " unicode_border_linestyle " ,
2014-09-12 18:04:37 +02:00
" unicode_column_linestyle " , " unicode_header_linestyle " , NULL } ;
2000-04-12 19:17:23 +02:00
2012-02-01 19:16:40 +01:00
COMPLETE_WITH_LIST_CS ( my_list ) ;
2000-04-12 19:17:23 +02:00
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS2 ( " \\ pset " , MatchAny ) )
2011-03-16 22:46:15 +01:00
{
2016-01-05 18:00:13 +01:00
if ( TailMatchesCS1 ( " format " ) )
2011-03-16 22:46:15 +01:00
{
static const char * const my_list [ ] =
2015-03-31 17:33:25 +02:00
{ " unaligned " , " aligned " , " wrapped " , " html " , " asciidoc " ,
" latex " , " latex-longtable " , " troff-ms " , NULL } ;
2011-03-16 22:46:15 +01:00
2012-02-01 19:16:40 +01:00
COMPLETE_WITH_LIST_CS ( my_list ) ;
2011-03-16 22:46:15 +01:00
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " linestyle " ) )
COMPLETE_WITH_LIST_CS3 ( " ascii " , " old-ascii " , " unicode " ) ;
else if ( TailMatchesCS1 ( " unicode_border_linestyle| "
" unicode_column_linestyle| "
" unicode_header_linestyle " ) )
COMPLETE_WITH_LIST_CS2 ( " single " , " double " ) ;
2011-03-16 22:46:15 +01:00
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ unset " ) )
2014-08-12 04:57:39 +02:00
{
matches = complete_from_variables ( text , " " , " " , true ) ;
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ set " ) )
2010-10-11 00:42:35 +02:00
{
2014-08-12 04:57:39 +02:00
matches = complete_from_variables ( text , " " , " " , false ) ;
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS2 ( " \\ set " , MatchAny ) )
2014-08-12 04:57:39 +02:00
{
2016-01-05 18:00:13 +01:00
if ( TailMatchesCS1 ( " AUTOCOMMIT|ON_ERROR_STOP|QUIET| "
" SINGLELINE|SINGLESTEP " ) )
COMPLETE_WITH_LIST_CS2 ( " on " , " off " ) ;
else if ( TailMatchesCS1 ( " COMP_KEYWORD_CASE " ) )
COMPLETE_WITH_LIST_CS4 ( " lower " , " upper " ,
" preserve-lower " , " preserve-upper " ) ;
else if ( TailMatchesCS1 ( " ECHO " ) )
COMPLETE_WITH_LIST_CS4 ( " errors " , " queries " , " all " , " none " ) ;
else if ( TailMatchesCS1 ( " ECHO_HIDDEN " ) )
COMPLETE_WITH_LIST_CS3 ( " noexec " , " off " , " on " ) ;
else if ( TailMatchesCS1 ( " HISTCONTROL " ) )
COMPLETE_WITH_LIST_CS4 ( " ignorespace " , " ignoredups " ,
" ignoreboth " , " none " ) ;
else if ( TailMatchesCS1 ( " ON_ERROR_ROLLBACK " ) )
COMPLETE_WITH_LIST_CS3 ( " on " , " off " , " interactive " ) ;
else if ( TailMatchesCS1 ( " SHOW_CONTEXT " ) )
COMPLETE_WITH_LIST_CS3 ( " never " , " errors " , " always " ) ;
else if ( TailMatchesCS1 ( " VERBOSITY " ) )
COMPLETE_WITH_LIST_CS3 ( " default " , " verbose " , " terse " ) ;
2010-10-11 00:42:35 +02:00
}
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ sf* " ) )
2010-08-14 15:59:49 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_functions , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ sv* " ) )
2015-07-03 21:48:18 +02:00
COMPLETE_WITH_SCHEMA_QUERY ( Query_for_list_of_views , NULL ) ;
2016-01-05 18:00:13 +01:00
else if ( TailMatchesCS1 ( " \\ cd| \\ e| \\ edit| \\ g| \\ i| \\ include| "
" \\ ir| \\ include_relative| \\ o| \\ out| "
" \\ s| \\ w| \\ write| \\ lo_import " ) )
2012-02-28 05:06:29 +01:00
{
completion_charp = " \\ " ;
matches = completion_matches ( text , complete_from_files ) ;
}
2000-04-12 19:17:23 +02:00
2005-11-14 18:48:43 +01:00
/*
* Finally , we look through the list of " things " , such as TABLE , INDEX and
* check if that was the previous word . If so , execute the query to get a
* list of them .
*/
2000-04-12 19:17:23 +02:00
else
{
int i ;
for ( i = 0 ; words_after_create [ i ] . name ; i + + )
2003-10-30 22:37:38 +01:00
{
2004-05-07 02:24:59 +02:00
if ( pg_strcasecmp ( prev_wd , words_after_create [ i ] . name ) = = 0 )
2000-04-12 19:17:23 +02:00
{
2003-10-30 22:37:38 +01:00
if ( words_after_create [ i ] . query )
2003-03-27 17:45:01 +01:00
COMPLETE_WITH_QUERY ( words_after_create [ i ] . query ) ;
2003-10-30 22:37:38 +01:00
else if ( words_after_create [ i ] . squery )
COMPLETE_WITH_SCHEMA_QUERY ( * words_after_create [ i ] . squery ,
NULL ) ;
2000-04-12 19:17:23 +02:00
break ;
}
2003-10-30 22:37:38 +01:00
}
2000-04-12 19:17:23 +02:00
}
2005-11-14 18:48:43 +01:00
/*
* If we still don ' t have anything to match we have to fabricate some sort
* of default list . If we were to just return NULL , readline automatically
* attempts filename completion , and that ' s usually no good .
*/
if ( matches = = NULL )
{
COMPLETE_WITH_CONST ( " " ) ;
2000-01-22 00:32:36 +01:00
# ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
2005-11-14 18:48:43 +01:00
rl_completion_append_character = ' \0 ' ;
2000-01-22 00:32:36 +01:00
# endif
2005-11-14 18:48:43 +01:00
}
/* free storage */
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
free ( previous_words ) ;
free ( words_buffer ) ;
2005-11-14 18:48:43 +01:00
/* Return our Grand List O' Matches */
return matches ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2010-10-11 00:42:35 +02:00
/*
* GENERATOR FUNCTIONS
*
* These functions do all the actual work of completing the input . They get
* passed the text so far and the count how many times they have been called
* so far with the same text .
* If you read the above carefully , you ' ll see that these don ' t get called
* directly but through the readline interface .
* The return value is expected to be the full completion of the text , going
* through a list each time , or NULL if there are no more matches . The string
* will be free ( ) ' d by readline , so you must run it through strdup ( ) or
* something of that sort .
*/
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2010-10-11 00:42:35 +02:00
/*
2011-02-24 02:13:27 +01:00
* Common routine for create_command_generator and drop_command_generator .
* Entries that have ' excluded ' flags are not returned .
2010-10-11 00:42:35 +02:00
*/
2005-11-14 18:48:43 +01:00
static char *
2011-02-24 02:13:27 +01:00
create_or_drop_command_generator ( const char * text , int state , bits32 excluded )
2005-11-14 18:48:43 +01:00
{
2007-11-15 22:14:46 +01:00
static int list_index ,
string_length ;
2005-11-14 18:48:43 +01:00
const char * name ;
/* If this is the first time for this completion, init some values */
if ( state = = 0 )
{
list_index = 0 ;
string_length = strlen ( text ) ;
}
/* find something that matches */
while ( ( name = words_after_create [ list_index + + ] . name ) )
2007-09-14 06:25:24 +02:00
{
2010-10-11 00:42:35 +02:00
if ( ( pg_strncasecmp ( name , text , string_length ) = = 0 ) & &
2011-02-24 02:13:27 +01:00
! ( words_after_create [ list_index - 1 ] . flags & excluded ) )
2012-05-08 20:03:45 +02:00
return pg_strdup_keyword_case ( name , text ) ;
2007-09-14 06:25:24 +02:00
}
2005-11-14 18:48:43 +01:00
/* if nothing matches, return NULL */
return NULL ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2011-02-24 02:13:27 +01:00
/*
* This one gives you one from a list of things you can put after CREATE
* as defined above .
*/
static char *
create_command_generator ( const char * text , int state )
{
return create_or_drop_command_generator ( text , state , THING_NO_CREATE ) ;
}
2006-04-02 11:02:41 +02:00
/*
* This function gives you a list of things you can put after a DROP command .
*/
static char *
drop_command_generator ( const char * text , int state )
{
2011-02-24 02:13:27 +01:00
return create_or_drop_command_generator ( text , state , THING_NO_DROP ) ;
2006-04-02 11:02:41 +02:00
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2017-03-16 23:54:28 +01:00
/*
* This function gives you a list of things you can put after an ALTER command .
*/
static char *
alter_command_generator ( const char * text , int state )
{
return create_or_drop_command_generator ( text , state , THING_NO_ALTER ) ;
}
2003-03-27 17:45:01 +01:00
/* The following two functions are wrappers for _complete_from_query */
2005-11-14 18:48:43 +01:00
static char *
complete_from_query ( const char * text , int state )
{
return _complete_from_query ( 0 , text , state ) ;
}
2003-03-27 17:45:01 +01:00
2005-11-14 18:48:43 +01:00
static char *
complete_from_schema_query ( const char * text , int state )
{
return _complete_from_query ( 1 , text , state ) ;
}
2003-03-27 17:45:01 +01:00
2010-10-11 00:42:35 +02:00
/*
* This creates a list of matching things , according to a query pointed to
* by completion_charp .
* The query can be one of two kinds :
*
* 1. A simple query which must contain a % d and a % s , which will be replaced
* by the string length of the text and the text itself . The query may also
* have up to four more % s in it ; the first two such will be replaced by the
* value of completion_info_charp , the next two by the value of
* completion_info_charp2 .
*
* 2. A schema query used for completion of both schema and relation names .
* These are more complex and must contain in the following order :
* % d % s % d % s % d % s % s % d % s
* where % d is the string length of the text and % s the text itself .
*
* It is assumed that strings should be escaped to become SQL literals
* ( that is , what is in the query is actually . . . ' % s ' . . . )
*
* See top of file for examples of both kinds of query .
*/
2005-11-14 18:48:43 +01:00
static char *
_complete_from_query ( int is_schema_query , const char * text , int state )
{
static int list_index ,
2016-03-04 17:53:20 +01:00
byte_length ;
2005-11-14 18:48:43 +01:00
static PGresult * result = NULL ;
2016-06-10 00:02:36 +02:00
2005-11-14 18:48:43 +01:00
/*
* If this is the first time for this completion , we fetch a list of our
* " things " from the backend .
*/
if ( state = = 0 )
{
PQExpBufferData query_buffer ;
char * e_text ;
char * e_info_charp ;
2008-03-29 20:19:14 +01:00
char * e_info_charp2 ;
2016-03-04 17:53:20 +01:00
const char * pstr = text ;
int char_length = 0 ;
2005-11-14 18:48:43 +01:00
list_index = 0 ;
2016-03-04 17:53:20 +01:00
byte_length = strlen ( text ) ;
2016-06-10 00:02:36 +02:00
/*
* Count length as number of characters ( not bytes ) , for passing to
* substring
*/
2016-03-04 17:53:20 +01:00
while ( * pstr )
{
char_length + + ;
pstr + = PQmblen ( pstr , pset . encoding ) ;
}
2005-11-14 18:48:43 +01:00
/* Free any prior result */
PQclear ( result ) ;
result = NULL ;
/* Set up suitably-escaped copies of textual inputs */
2015-09-08 20:57:35 +02:00
e_text = escape_string ( text ) ;
2005-11-14 18:48:43 +01:00
if ( completion_info_charp )
2015-09-08 20:57:35 +02:00
e_info_charp = escape_string ( completion_info_charp ) ;
2005-11-14 18:48:43 +01:00
else
e_info_charp = NULL ;
2008-03-29 20:19:14 +01:00
if ( completion_info_charp2 )
2015-09-08 20:57:35 +02:00
e_info_charp2 = escape_string ( completion_info_charp2 ) ;
2008-03-29 20:19:14 +01:00
else
e_info_charp2 = NULL ;
2005-11-14 18:48:43 +01:00
initPQExpBuffer ( & query_buffer ) ;
if ( is_schema_query )
{
/* completion_squery gives us the pieces to assemble */
const char * qualresult = completion_squery - > qualresult ;
if ( qualresult = = NULL )
qualresult = completion_squery - > result ;
/* Get unqualified names matching the input-so-far */
appendPQExpBuffer ( & query_buffer , " SELECT %s FROM %s WHERE " ,
completion_squery - > result ,
completion_squery - > catname ) ;
if ( completion_squery - > selcondition )
appendPQExpBuffer ( & query_buffer , " %s AND " ,
completion_squery - > selcondition ) ;
appendPQExpBuffer ( & query_buffer , " substring(%s,1,%d)='%s' " ,
completion_squery - > result ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
appendPQExpBuffer ( & query_buffer , " AND %s " ,
completion_squery - > viscondition ) ;
/*
* When fetching relation names , suppress system catalogs unless
2014-05-06 18:12:18 +02:00
* the input - so - far begins with " pg_ " . This is a compromise
2005-11-14 18:48:43 +01:00
* between not offering system catalogs for completion at all , and
* having them swamp the result when the input is just " p " .
*/
if ( strcmp ( completion_squery - > catname ,
" pg_catalog.pg_class c " ) = = 0 & &
strncmp ( text , " pg_ " , 3 ) ! = 0 )
{
2013-11-18 17:29:01 +01:00
appendPQExpBufferStr ( & query_buffer ,
" AND c.relnamespace <> (SELECT oid FROM "
2005-11-14 18:48:43 +01:00
" pg_catalog.pg_namespace WHERE nspname = 'pg_catalog') " ) ;
}
/*
* Add in matching schema names , but only if there is more than
* one potential match among schema names .
*/
appendPQExpBuffer ( & query_buffer , " \n UNION \n "
" SELECT pg_catalog.quote_ident(n.nspname) || '.' "
" FROM pg_catalog.pg_namespace n "
" WHERE substring(pg_catalog.quote_ident(n.nspname) || '.',1,%d)='%s' " ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
appendPQExpBuffer ( & query_buffer ,
" AND (SELECT pg_catalog.count(*) "
" FROM pg_catalog.pg_namespace "
" WHERE substring(pg_catalog.quote_ident(nspname) || '.',1,%d) = "
" substring('%s',1,pg_catalog.length(pg_catalog.quote_ident(nspname))+1)) > 1 " ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
/*
* Add in matching qualified names , but only if there is exactly
* one schema matching the input - so - far .
*/
appendPQExpBuffer ( & query_buffer , " \n UNION \n "
" SELECT pg_catalog.quote_ident(n.nspname) || '.' || %s "
" FROM %s, pg_catalog.pg_namespace n "
" WHERE %s = n.oid AND " ,
qualresult ,
completion_squery - > catname ,
completion_squery - > namespace ) ;
if ( completion_squery - > selcondition )
appendPQExpBuffer ( & query_buffer , " %s AND " ,
completion_squery - > selcondition ) ;
appendPQExpBuffer ( & query_buffer , " substring(pg_catalog.quote_ident(n.nspname) || '.' || %s,1,%d)='%s' " ,
qualresult ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
/*
* This condition exploits the single - matching - schema rule to
* speed up the query
*/
appendPQExpBuffer ( & query_buffer ,
" AND substring(pg_catalog.quote_ident(n.nspname) || '.',1,%d) = "
" substring('%s',1,pg_catalog.length(pg_catalog.quote_ident(n.nspname))+1) " ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
appendPQExpBuffer ( & query_buffer ,
" AND (SELECT pg_catalog.count(*) "
" FROM pg_catalog.pg_namespace "
" WHERE substring(pg_catalog.quote_ident(nspname) || '.',1,%d) = "
" substring('%s',1,pg_catalog.length(pg_catalog.quote_ident(nspname))+1)) = 1 " ,
2016-03-04 17:53:20 +01:00
char_length , e_text ) ;
2005-11-14 18:48:43 +01:00
/* If an addon query was provided, use it */
if ( completion_charp )
appendPQExpBuffer ( & query_buffer , " \n %s " , completion_charp ) ;
}
else
{
/* completion_charp is an sprintf-style format string */
appendPQExpBuffer ( & query_buffer , completion_charp ,
2016-03-04 17:53:20 +01:00
char_length , e_text ,
2008-03-29 20:19:14 +01:00
e_info_charp , e_info_charp ,
e_info_charp2 , e_info_charp2 ) ;
2005-11-14 18:48:43 +01:00
}
/* Limit the number of records in the result */
appendPQExpBuffer ( & query_buffer , " \n LIMIT %d " ,
completion_max_records ) ;
result = exec_query ( query_buffer . data ) ;
termPQExpBuffer ( & query_buffer ) ;
free ( e_text ) ;
if ( e_info_charp )
free ( e_info_charp ) ;
2008-03-29 20:19:14 +01:00
if ( e_info_charp2 )
free ( e_info_charp2 ) ;
2005-11-14 18:48:43 +01:00
}
/* Find something that matches */
if ( result & & PQresultStatus ( result ) = = PGRES_TUPLES_OK )
{
const char * item ;
while ( list_index < PQntuples ( result ) & &
( item = PQgetvalue ( result , list_index + + , 0 ) ) )
2016-03-04 17:53:20 +01:00
if ( pg_strncasecmp ( text , item , byte_length ) = = 0 )
2005-11-14 18:48:43 +01:00
return pg_strdup ( item ) ;
}
/* If nothing matches, free the db structure and return null */
PQclear ( result ) ;
result = NULL ;
return NULL ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2010-10-11 00:42:35 +02:00
/*
* This function returns in order one of a fixed , NULL pointer terminated list
* of strings ( if matching ) . This can be used if there are only a fixed number
* SQL words that can appear at certain spot .
*/
2005-11-14 18:48:43 +01:00
static char *
complete_from_list ( const char * text , int state )
{
static int string_length ,
list_index ,
matches ;
static bool casesensitive ;
const char * item ;
/* need to have a list */
2012-12-15 00:03:07 +01:00
Assert ( completion_charpp ! = NULL ) ;
2005-11-14 18:48:43 +01:00
/* Initialization */
if ( state = = 0 )
{
list_index = 0 ;
string_length = strlen ( text ) ;
2012-02-01 19:16:40 +01:00
casesensitive = completion_case_sensitive ;
2005-11-14 18:48:43 +01:00
matches = 0 ;
}
while ( ( item = completion_charpp [ list_index + + ] ) )
{
/* First pass is case sensitive */
if ( casesensitive & & strncmp ( text , item , string_length ) = = 0 )
{
matches + + ;
return pg_strdup ( item ) ;
}
/* Second pass is case insensitive, don't bother counting matches */
if ( ! casesensitive & & pg_strncasecmp ( text , item , string_length ) = = 0 )
2012-02-01 19:16:40 +01:00
{
if ( completion_case_sensitive )
return pg_strdup ( item ) ;
else
2012-06-10 21:20:04 +02:00
/*
* If case insensitive matching was requested initially ,
* adjust the case according to setting .
*/
2012-05-08 20:03:45 +02:00
return pg_strdup_keyword_case ( item , text ) ;
2012-02-01 19:16:40 +01:00
}
2005-11-14 18:48:43 +01:00
}
/*
* No matches found . If we ' re not case insensitive already , lets switch to
* being case insensitive and try again
*/
if ( casesensitive & & matches = = 0 )
{
casesensitive = false ;
list_index = 0 ;
state + + ;
2006-01-11 09:43:13 +01:00
return complete_from_list ( text , state ) ;
2005-11-14 18:48:43 +01:00
}
/* If no more matches, return null. */
return NULL ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2010-10-11 00:42:35 +02:00
/*
* This function returns one fixed string the first time even if it doesn ' t
* match what ' s there , and nothing the second time . This should be used if
* there is only one possibility that can appear at a certain spot , so
* misspellings will be overwritten . The string to be passed must be in
* completion_charp .
*/
2005-11-14 18:48:43 +01:00
static char *
complete_from_const ( const char * text , int state )
{
2012-12-15 00:03:07 +01:00
Assert ( completion_charp ! = NULL ) ;
2005-11-14 18:48:43 +01:00
if ( state = = 0 )
2012-02-01 19:16:40 +01:00
{
if ( completion_case_sensitive )
return pg_strdup ( completion_charp ) ;
else
2012-06-10 21:20:04 +02:00
/*
* If case insensitive matching was requested initially , adjust
* the case according to setting .
*/
2012-05-08 20:03:45 +02:00
return pg_strdup_keyword_case ( completion_charp , text ) ;
2012-02-01 19:16:40 +01:00
}
2005-11-14 18:48:43 +01:00
else
return NULL ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2014-08-12 04:57:39 +02:00
/*
* This function appends the variable name with prefix and suffix to
* the variable names array .
*/
static void
append_variable_names ( char * * * varnames , int * nvars ,
int * maxvars , const char * varname ,
const char * prefix , const char * suffix )
{
if ( * nvars > = * maxvars )
{
* maxvars * = 2 ;
2014-11-18 19:28:06 +01:00
* varnames = ( char * * ) pg_realloc ( * varnames ,
( ( * maxvars ) + 1 ) * sizeof ( char * ) ) ;
2014-08-12 04:57:39 +02:00
}
( * varnames ) [ ( * nvars ) + + ] = psprintf ( " %s%s%s " , prefix , varname , suffix ) ;
}
2010-10-11 00:42:35 +02:00
/*
* This function supports completion with the name of a psql variable .
* The variable names can be prefixed and suffixed with additional text
Clean up psql's behavior for a few more control variables.
Modify FETCH_COUNT to always have a defined value, like other control
variables, mainly so it will always appear in "\set" output.
Add hooks to force HISTSIZE to be defined and require it to have an
integer value. (I don't see any point in allowing it to be set to
non-integral values.)
Add hooks to force IGNOREEOF to be defined and require it to have an
integer value. Unlike the other cases, here we're trying to be
bug-compatible with a rather bogus externally-defined behavior, so I think
we need to continue to allow "\set IGNOREEOF whatever". Fix it so that
the substitution hook silently replace non-numeric values with "10",
so that the stored value always reflects what we're really doing.
Add a dummy assign hook for HISTFILE, just so it's always in
variables.c's list. We can't require it to be defined always, because
that would break the interaction with the PSQL_HISTORY environment
variable, so there isn't any change in visible behavior here.
Remove tab-complete.c's private list of known variable names, since that's
really a maintenance nuisance. Given the preceding changes, there are no
control variables it won't show anyway. This does mean that if for some
reason you've unset one of the status variables (DBNAME, HOST, etc), that
variable would not appear in tab completion for \set. But I think that's
fine, for at least two reasons: we shouldn't be encouraging people to use
those variables as regular variables, and if someone does do so anyway,
why shouldn't it act just like a regular variable?
Remove ugly and no-longer-used-anywhere GetVariableNum(). In general,
future additions of integer-valued control variables should follow the
paradigm of adding an assign hook using ParseVariableNum(), so there's
no reason to expect we'd need this again later.
Discussion: https://postgr.es/m/17516.1485973973@sss.pgh.pa.us
2017-02-03 02:16:17 +01:00
* to support quoting usages . If need_value is true , only variables
* that are currently set are included ; otherwise , special variables
* ( those that have hooks ) are included even if currently unset .
2010-10-11 00:42:35 +02:00
*/
static char * *
2014-08-12 04:57:39 +02:00
complete_from_variables ( const char * text , const char * prefix , const char * suffix ,
bool need_value )
2010-10-11 00:42:35 +02:00
{
char * * matches ;
2012-01-31 20:23:17 +01:00
char * * varnames ;
2010-10-11 00:42:35 +02:00
int nvars = 0 ;
int maxvars = 100 ;
int i ;
struct _variable * ptr ;
2012-01-31 20:23:17 +01:00
varnames = ( char * * ) pg_malloc ( ( maxvars + 1 ) * sizeof ( char * ) ) ;
2010-10-11 00:42:35 +02:00
for ( ptr = pset . vars - > next ; ptr ; ptr = ptr - > next )
{
2014-08-12 04:57:39 +02:00
if ( need_value & & ! ( ptr - > value ) )
continue ;
append_variable_names ( & varnames , & nvars , & maxvars , ptr - > name ,
prefix , suffix ) ;
2010-10-11 00:42:35 +02:00
}
varnames [ nvars ] = NULL ;
2012-06-10 21:20:04 +02:00
COMPLETE_WITH_LIST_CS ( ( const char * const * ) varnames ) ;
2010-10-11 00:42:35 +02:00
for ( i = 0 ; i < nvars ; i + + )
2012-01-31 20:23:17 +01:00
free ( varnames [ i ] ) ;
2010-10-11 00:42:35 +02:00
free ( varnames ) ;
return matches ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2012-02-28 05:06:29 +01:00
/*
* This function wraps rl_filename_completion_function ( ) to strip quotes from
* the input before searching for matches and to quote any matches for which
* the consuming command will require it .
*/
static char *
complete_from_files ( const char * text , int state )
{
static const char * unquoted_text ;
char * unquoted_match ;
char * ret = NULL ;
if ( state = = 0 )
{
/* Initialization: stash the unquoted input. */
unquoted_text = strtokx ( text , " " , NULL , " ' " , * completion_charp ,
false , true , pset . encoding ) ;
/* expect a NULL return for the empty string only */
if ( ! unquoted_text )
{
2012-12-15 00:03:07 +01:00
Assert ( * text = = ' \0 ' ) ;
2012-02-28 05:06:29 +01:00
unquoted_text = text ;
}
}
unquoted_match = filename_completion_function ( unquoted_text , state ) ;
if ( unquoted_match )
{
/*
* Caller sets completion_charp to a zero - or one - character string
* containing the escape character . This is necessary since \ copy has
* no escape character , but every other backslash command recognizes
* " \" as an escape character. Since we have only two callers, don't
* bother providing a macro to simplify this .
*/
ret = quote_if_needed ( unquoted_match , " \t \r \n \" ` " ,
' \' ' , * completion_charp , pset . encoding ) ;
if ( ret )
free ( unquoted_match ) ;
else
ret = unquoted_match ;
}
return ret ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
/* HELPER FUNCTIONS */
2012-02-01 19:16:40 +01:00
/*
2012-05-08 20:03:45 +02:00
* Make a pg_strdup copy of s and convert the case according to
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
* COMP_KEYWORD_CASE setting , using ref as the text that was already entered .
2012-02-01 19:16:40 +01:00
*/
static char *
2012-05-08 20:03:45 +02:00
pg_strdup_keyword_case ( const char * s , const char * ref )
2012-02-01 19:16:40 +01:00
{
2012-06-10 21:20:04 +02:00
char * ret ,
* p ;
2012-02-01 19:16:40 +01:00
unsigned char first = ref [ 0 ] ;
2012-05-08 20:03:45 +02:00
ret = pg_strdup ( s ) ;
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
if ( pset . comp_case = = PSQL_COMP_CASE_LOWER | |
( ( pset . comp_case = = PSQL_COMP_CASE_PRESERVE_LOWER | |
2015-05-24 03:35:49 +02:00
pset . comp_case = = PSQL_COMP_CASE_PRESERVE_UPPER ) & & islower ( first ) ) | |
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
( pset . comp_case = = PSQL_COMP_CASE_PRESERVE_LOWER & & ! isalpha ( first ) ) )
{
2012-05-08 20:03:45 +02:00
for ( p = ret ; * p ; p + + )
* p = pg_tolower ( ( unsigned char ) * p ) ;
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
}
2012-02-01 19:16:40 +01:00
else
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
{
2012-05-08 20:03:45 +02:00
for ( p = ret ; * p ; p + + )
* p = pg_toupper ( ( unsigned char ) * p ) ;
Improve consistency of parsing of psql's magic variables.
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
2014-12-31 18:16:53 +01:00
}
2012-05-08 20:03:45 +02:00
return ret ;
2012-02-01 19:16:40 +01:00
}
2015-09-08 20:57:35 +02:00
/*
* escape_string - Escape argument for use as string literal .
*
* The returned value has to be freed .
*/
static char *
escape_string ( const char * text )
{
size_t text_length ;
char * result ;
text_length = strlen ( text ) ;
result = pg_malloc ( text_length * 2 + 1 ) ;
PQescapeStringConn ( pset . db , result , text , text_length , NULL ) ;
return result ;
}
2003-10-30 22:37:38 +01:00
/*
* Execute a query and report any errors . This should be the preferred way of
* talking to the database in this file .
*/
2005-11-14 18:48:43 +01:00
static PGresult *
exec_query ( const char * query )
{
PGresult * result ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2005-11-14 18:48:43 +01:00
if ( query = = NULL | | ! pset . db | | PQstatus ( pset . db ) ! = CONNECTION_OK )
return NULL ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2005-11-14 18:48:43 +01:00
result = PQexec ( pset . db , query ) ;
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2008-08-16 03:36:35 +02:00
if ( PQresultStatus ( result ) ! = PGRES_TUPLES_OK )
2005-11-14 18:48:43 +01:00
{
2010-10-11 00:42:35 +02:00
# ifdef NOT_USED
2008-08-16 03:36:35 +02:00
psql_error ( " tab completion query failed: %s \n Query was: \n %s \n " ,
PQerrorMessage ( pset . db ) , query ) ;
2000-01-12 20:36:36 +01:00
# endif
2005-11-14 18:48:43 +01:00
PQclear ( result ) ;
result = NULL ;
}
2000-04-12 19:17:23 +02:00
2005-11-14 18:48:43 +01:00
return result ;
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2005-05-18 07:01:10 +02:00
/*
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* Parse all the word ( s ) before point .
*
* Returns a malloc ' d array of character pointers that point into the malloc ' d
* data array returned to * buffer ; caller must free ( ) both of these when done .
* * nwords receives the number of words found , ie , the valid length of the
* return array .
*
* Words are returned right to left , that is , previous_words [ 0 ] gets the last
* word before point , previous_words [ 1 ] the next - to - last , etc .
2005-05-18 07:01:10 +02:00
*/
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
static char * *
get_previous_words ( int point , char * * buffer , int * nwords )
2005-11-14 18:48:43 +01:00
{
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
char * * previous_words ;
char * buf ;
2015-12-21 21:08:56 +01:00
char * outptr ;
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
int words_found = 0 ;
2011-10-20 21:38:57 +02:00
int i ;
2010-02-17 05:09:40 +01:00
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
2015-12-21 21:08:56 +01:00
* If we have anything in tab_completion_query_buf , paste it together with
* rl_line_buffer to construct the full query . Otherwise we can just use
* rl_line_buffer as the input string .
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
*/
2015-12-21 21:08:56 +01:00
if ( tab_completion_query_buf & & tab_completion_query_buf - > len > 0 )
{
i = tab_completion_query_buf - > len ;
buf = pg_malloc ( point + i + 2 ) ;
memcpy ( buf , tab_completion_query_buf - > data , i ) ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
buf [ i + + ] = ' \n ' ;
2015-12-21 21:08:56 +01:00
memcpy ( buf + i , rl_line_buffer , point ) ;
i + = point ;
buf [ i ] = ' \0 ' ;
/* Readjust point to reference appropriate offset in buf */
point = i ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
}
2015-12-21 21:08:56 +01:00
else
buf = rl_line_buffer ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
2015-12-21 21:08:56 +01:00
* Allocate an array of string pointers and a buffer to hold the strings
* themselves . The worst case is that the line contains only
* non - whitespace WORD_BREAKS characters , making each one a separate word .
* This is usually much more space than we need , but it ' s cheaper than
* doing a separate malloc ( ) for each word .
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
*/
2015-12-21 21:08:56 +01:00
previous_words = ( char * * ) pg_malloc ( point * sizeof ( char * ) ) ;
* buffer = outptr = ( char * ) pg_malloc ( point * 2 ) ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
* First we look for a non - word char before the current point . ( This is
* probably useless , if readline is on the same page as we are about what
* is a word , but if so it ' s cheap . )
*/
2010-02-17 05:09:40 +01:00
for ( i = point - 1 ; i > = 0 ; i - - )
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
{
2010-02-17 05:09:40 +01:00
if ( strchr ( WORD_BREAKS , buf [ i ] ) )
break ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
}
2010-02-17 05:09:40 +01:00
point = i ;
2005-11-14 18:48:43 +01:00
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/*
* Now parse words , working backwards , until we hit start of line . The
* backwards scan has some interesting but intentional properties
* concerning parenthesis handling .
*/
while ( point > = 0 )
2005-11-14 18:48:43 +01:00
{
2011-10-20 21:38:57 +02:00
int start ,
end ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
bool inquotes = false ;
int parentheses = 0 ;
2005-11-14 18:48:43 +01:00
/* now find the first non-space which then constitutes the end */
2011-10-20 21:38:57 +02:00
end = - 1 ;
2010-02-17 05:09:40 +01:00
for ( i = point ; i > = 0 ; i - - )
2011-10-20 21:38:57 +02:00
{
if ( ! isspace ( ( unsigned char ) buf [ i ] ) )
2005-11-14 18:48:43 +01:00
{
end = i ;
break ;
}
2011-10-20 21:38:57 +02:00
}
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/* if no end found, we're done */
if ( end < 0 )
break ;
2005-11-14 18:48:43 +01:00
/*
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* Otherwise we now look for the start . The start is either the last
* character before any word - break character going backwards from the
* end , or it ' s simply character 0. We also handle open quotes and
* parentheses .
2005-11-14 18:48:43 +01:00
*/
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
for ( start = end ; start > 0 ; start - - )
2011-10-20 21:38:57 +02:00
{
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
if ( buf [ start ] = = ' " ' )
inquotes = ! inquotes ;
if ( ! inquotes )
2010-02-17 05:09:40 +01:00
{
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
if ( buf [ start ] = = ' ) ' )
parentheses + + ;
else if ( buf [ start ] = = ' ( ' )
2010-02-17 05:09:40 +01:00
{
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
if ( - - parentheses < = 0 )
2010-02-17 05:09:40 +01:00
break ;
}
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
else if ( parentheses = = 0 & &
strchr ( WORD_BREAKS , buf [ start - 1 ] ) )
break ;
2010-02-17 05:09:40 +01:00
}
2011-10-20 21:38:57 +02:00
}
2005-11-14 18:48:43 +01:00
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/* Return the word located at start to end inclusive */
2015-12-21 21:08:56 +01:00
previous_words [ words_found + + ] = outptr ;
i = end - start + 1 ;
memcpy ( outptr , & buf [ start ] , i ) ;
outptr + = i ;
* outptr + + = ' \0 ' ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
/* Continue searching */
point = start - 1 ;
2011-10-20 21:38:57 +02:00
}
Adopt a more compact, less error-prone notation for tab completion code.
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
2015-12-19 22:03:14 +01:00
2015-12-21 21:08:56 +01:00
/* Release parsing input workspace, if we made one above */
if ( buf ! = rl_line_buffer )
free ( buf ) ;
Teach psql's tab completion to consider the entire input string.
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.
2015-12-20 19:28:11 +01:00
* nwords = words_found ;
return previous_words ;
2005-11-14 18:48:43 +01:00
}
* Includes tab completion. It's not magic, but it's very cool. At any
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
1999-11-26 05:24:17 +01:00
2015-09-08 20:57:35 +02:00
/*
* Look up the type for the GUC variable with the passed name .
*
* Returns NULL if the variable is unknown . Otherwise the returned string ,
* containing the type , has to be freed .
*/
static char *
get_guctype ( const char * varname )
{
PQExpBufferData query_buffer ;
char * e_varname ;
PGresult * result ;
char * guctype = NULL ;
e_varname = escape_string ( varname ) ;
initPQExpBuffer ( & query_buffer ) ;
appendPQExpBuffer ( & query_buffer ,
" SELECT vartype FROM pg_catalog.pg_settings "
" WHERE pg_catalog.lower(name) = pg_catalog.lower('%s') " ,
e_varname ) ;
result = exec_query ( query_buffer . data ) ;
termPQExpBuffer ( & query_buffer ) ;
free ( e_varname ) ;
if ( PQresultStatus ( result ) = = PGRES_TUPLES_OK & & PQntuples ( result ) > 0 )
guctype = pg_strdup ( PQgetvalue ( result , 0 , 0 ) ) ;
PQclear ( result ) ;
return guctype ;
}
2010-10-11 00:42:35 +02:00
# ifdef NOT_USED
2000-01-12 20:36:36 +01:00
2000-01-19 00:30:24 +01:00
/*
* Surround a string with single quotes . This works for both SQL and
2003-12-01 23:14:40 +01:00
* psql internal . Currently disabled because it is reported not to
2000-01-19 00:30:24 +01:00
* cooperate with certain versions of readline .
*/
2005-11-14 18:48:43 +01:00
static char *
quote_file_name ( char * text , int match_type , char * quote_pointer )
{
char * s ;
size_t length ;
( void ) quote_pointer ; /* not used */
length = strlen ( text ) + ( match_type = = SINGLE_MATCH ? 3 : 2 ) ;
s = pg_malloc ( length ) ;
s [ 0 ] = ' \' ' ;
strcpy ( s + 1 , text ) ;
if ( match_type = = SINGLE_MATCH )
s [ length - 2 ] = ' \' ' ;
s [ length - 1 ] = ' \0 ' ;
return s ;
}
static char *
dequote_file_name ( char * text , char quote_char )
{
char * s ;
size_t length ;
if ( ! quote_char )
return pg_strdup ( text ) ;
length = strlen ( text ) ;
s = pg_malloc ( length - 2 + 1 ) ;
2007-02-07 01:52:35 +01:00
strlcpy ( s , text + 1 , length - 2 + 1 ) ;
2005-11-14 18:48:43 +01:00
return s ;
}
2010-10-11 00:42:35 +02:00
# endif /* NOT_USED */
2001-10-28 07:26:15 +01:00
2001-11-05 18:46:40 +01:00
# endif /* USE_READLINE */