database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00
Code Activity

* Includes tab completion. It's not magic, but it's very cool. At any

Browse Source 
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
This commit is contained in:
Bruce Momjian
1999-11-26 04:24:17 +00:00
parent c83b4d1cd8
commit 78bc83fedf
22 changed files with 1763 additions and 788 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
doc/src/sgml/ref/psql-ref.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.17 1999/11/05 18:21:08 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.18 1999/11/26 04:24:16 momjian Exp $
Postgres documentation
-->
@ -90,6 +90,11 @@ Postgres documentation
to be run at the start of every session.
</para>
<para>
<application>psql</application> can be used in a pipe sequence, and
automatically detects when it is not used interactively.
</para>
<refsect2 id="R2-APP-PSQL-3">
<refsect2info>
<date>1998-09-26</date>
@ -104,7 +109,7 @@ Postgres documentation
<application>libpq</application> client library, upon which
<application>psql</application> is built, will choose defaults.
(This will usually mean the environment variables <envar>PGDATABASE</envar>,
<envar>PGHOST</envar>, <envar>PGPORT</envar>, <envar>PQUSER</envar>,
<envar>PGHOST</envar>, <envar>PGPORT</envar>, <envar>PGUSER</envar>,
respectively, if they are set. Otherwise the default host is the local host
via Unix domain sockets, the default port is decided at compile time,
the default user is the system user name, and the default database is
@ -129,7 +134,7 @@ Postgres documentation
In normal operation, <application>psql</application> provides a prompt with
the name of the database that <application>psql</application> is currently
connected to followed by the string "=>". For example,
<programlisting>
<programlisting>
$ <userinput>psql testdb</userinput>
Welcome to psql, the PostgreSQL interactive terminal.
@ -140,7 +145,7 @@ Type: \copyright for distribution terms
\q to quit
testdb=>
</programlisting>
</programlisting>
</para>
<para>
@ -156,11 +161,6 @@ testdb=>
<xref linkend="SQL-LISTEN" endterm="SQL-LISTEN-title"> and
<xref linkend="SQL-NOTIFY" endterm="SQL-NOTIFY-title">.
</para>
<para>
<application>psql</application> can be used in a pipe sequence, and
automatically detects when it is not used interactively.
</para>
</refsect2>
</refsect1>
@ -343,17 +343,17 @@ testdb=>
<listitem>
<para>
Shows all column of <replaceable class="parameter">relation</replaceable>
Shows all columns of <replaceable class="parameter">relation</replaceable>
(which could be a table, view, index, or sequence),
their types, and any special attributes such as <literal>NOT NULL</literal>
or defaults, if any.
If the relation is, in fact, a table, any defined indices are also listed.
If the relation is a view, the view definition is also shown.
</para>
<para>
If the relation is, in fact, a table, any defined indices are also listed.
If the relation is a view, the view definition is also shown.
If the variable <envar>description</envar> is set, any comments associated
with a table columns are shown as well.
The command form <literal>\d?</literal> is identical, but any comments
associated with the table columns are shown as well.
</para>
<note>
@ -375,8 +375,10 @@ testdb=>
Lists all available aggregate functions, together with the data type they operate on.
If <replaceable class="parameter">pattern</replaceable>
(a regular expression) is specified, only matching aggregates are shown.
If the variable <envar>description</envar> is set, comments are listed for
each function as well.
If the alternative command form <literal>\da?</literal> is used,
comments are listed for each function as well. The command form
<literal>\da+</literal> will show more information about each aggregate
function, which is usually not of general interest.
</para>
</listitem>
</varlistentry>
@ -389,14 +391,14 @@ testdb=>
(which can be a regular expression), or of all objects if no argument is given.
(<quote>Object</quote> covers aggregates, functions, operators, types, relations
(tables, views, indices, sequences, large objects), rules, and triggers.) For example:
<programlisting>
<programlisting>
=> <userinput>\dd version</userinput>
Object descriptions
Name | What | Description
---------+----------+---------------------------
version | function | PostgreSQL version string
(1 row)
</programlisting>
</programlisting>
</para>
<para>
@ -423,8 +425,9 @@ testdb=>
Lists available functions, together with their argument and return types.
If <replaceable class="parameter">pattern</replaceable>
(a regular expression) is specified, only matching functions are shown.
If the variable <envar>description</envar> is set, comments are listed for
each function as well.
If the form <literal>\df+</literal> is used, additional information about
each function is shown. Comments for each function can be shown with
the <literal>\df?</literal> form.
</para>
</listitem>
</varlistentry>
@ -444,7 +447,7 @@ testdb=>
<para>
If <replaceable class="parameter">pattern</replaceable> is specified,
it is a regular expression restricts the listing to those objects
whose name matches. If the variable <envar>description</envar> is set,
whose name matches. If one appends a <quote>?</quote> to the command name,
each object is listed with its associated description, if any.
</para>
</listitem>
@ -462,18 +465,19 @@ testdb=>
<varlistentry>
<term><literal>\do [ <replaceable class="parameter">name</replaceable> ]</literal></term>
<term><literal>\do [ <replaceable class="parameter">pattern</replaceable> ]</literal></term>
<listitem>
<para>
Lists available operators with their operand and return types.
If <replaceable class="parameter">name</replaceable>
If <replaceable class="parameter">pattern</replaceable>
is specified, only operators with that name will be shown.
(Note that, unlike with similar commands, this is not a regular expression
because operator names were likely to interfere with regular expression
meta-characters.)
(Since this is a regular expression, be sure to quote all special
characters in you operator name with backslashes. To prevent
interpretation of the backslash as a new command, you might also
wish to quote the argument.)
</para>
<para>
If the variable <envar>description</envar> is set, comments are listed for
If the form <literal>\do?</literal> is used, comments are listed for
each operator.
</para>
</listitem>
@ -495,9 +499,9 @@ testdb=>
<term><literal>\dT [ <replaceable class="parameter">pattern</replaceable> ]</literal></term>
<listitem>
<para>
List all data types or only those that match <replaceable class="parameter">pattern</replaceable>.
If the variable <envar>description</envar> is set, each type is listed with
its associated description.
Lists all data types or only those that match <replaceable class="parameter">pattern</replaceable>.
The command forms <literal>\dT+</literal> and <literal>\dT?</literal> show extra information
and the associated descriptions of the types, respectively.
</para>
</listitem>
</varlistentry>
@ -519,8 +523,8 @@ testdb=>
The new query buffer is then re-parsed according to the normal rules of
<application>psql</application>, where the whole buffer is treated as
a single line. (Thus you cannot make <quote>scripts</quote> this way,
use <command>\i</command> for that.) In particular, this means that
if the query ends (or rather contains) a semicolon, it is immediately
use <command>\i</command> for that.) This means also that
if the query ends with (or rather contains) a semicolon, it is immediately
executed. In other cases it will merely wait in the query buffer.
</para>
@ -542,10 +546,10 @@ testdb=>
<para>
Prints the arguments to the standard output. This can be useful to
intersperse information in the output of scripts. For example:
<programlisting>
<programlisting>
=> <userinput>\echo `date`</userinput>
Tue Oct 26 21:40:57 CEST 1999
</programlisting>
</programlisting>
</para>
<tip>
@ -579,7 +583,7 @@ Tue Oct 26 21:40:57 CEST 1999
Sends the current query input buffer to the backend and optionally
saves the output in <replaceable class="parameter">filename</replaceable>
or pipes the output into a separate Unix shell to execute
<replaceable class="parameter">command</replaceable>. A blank <literal>\g</literal>
<replaceable class="parameter">command</replaceable>. A bare <literal>\g</literal>
is virtually equivalent to a semicolon. A <literal>\g</literal> with argument
is a <quote>one-shot</quote> alternative to the <command>\o</command> command.
</para>
@ -591,8 +595,7 @@ Tue Oct 26 21:40:57 CEST 1999
<listitem>
<para>
Give syntax help on the specified <acronym>SQL</acronym> command.
If <replaceable class="parameter">command</replaceable> is not a defined <acronym>SQL</acronym> command
or if <replaceable class="parameter">command</replaceable> is not specified,
If <replaceable class="parameter">command</replaceable> is not specified,
then <application>psql</application> will
list all the commands for which syntax help is
available. If <replaceable class="parameter">command</replaceable>
@ -628,7 +631,7 @@ Tue Oct 26 21:40:57 CEST 1999
<listitem>
<para>
Reads input from the file <replaceable class="parameter">filename</replaceable>
and executes it as though it has been typed on the keyboard.
and executes it as though it had been typed on the keyboard.
</para>
<note>
<para>
@ -644,9 +647,9 @@ Tue Oct 26 21:40:57 CEST 1999
<term><literal>\l</literal> (or <literal>\list</literal>)</term>
<listitem>
<para>
List all the databases in the server as well as their owners. If the
variable <envar>description</envar> is set, any descriptions for
the databases are shown as well. If your <productname>PostgreSQL</productname>
List all the databases in the server as well as their owners. Append a
<quote>?</quote> (question mark) to the command name to see any descriptions
for the databases as well. If your <productname>PostgreSQL</productname>
installation was
compiled with multibyte encoding support, the encoding scheme of each
database is shown as well.
@ -688,15 +691,15 @@ Tue Oct 26 21:40:57 CEST 1999
<para>
Stores the file into a <productname>PostgreSQL</productname> <quote>large object</quote>.
Optionally, it associates the given comment with the object. Example:
<programlisting>
<programlisting>
foo=> <userinput>\lo_import '/home/me/pictures/photo.xcf' 'a picture of me'</userinput>
lo_import 152801
</programlisting>
</programlisting>
The response indicates that the large object received object id 152801
which one ought to remember if one wants to access the object every again.
which one ought to remember if one wants to access the object ever again.
For that reason it is recommended to always associate a human-readable
comment with every object. Those can then be seen with the
<command>\lo_list</command> command.
<command>\lo_list?</command> command.
</para>
<para>
@ -720,8 +723,8 @@ lo_import 152801
<para>
Shows a list of all <productname>PostgreSQL</productname> <quote>large
objects</quote> currently stored in the database along with their owners.
If the variable <envar>description</envar> is set, the associated
comments are shown as well.
Append a question mark to the command name (<literal>\lo_list?</literal>) to
see the the associated comments as well.
</para>
</listitem>
</varlistentry>
@ -863,7 +866,7 @@ lo_import 152801
<para>
The second argument is a string that should be printed whenever a field
is null. The default is not to print anything, which can easily be mistaken
for, say, an empty string. There one might choose to write
for, say, an empty string. Thus, one might choose to write
<literal>\pset null "(null)"</literal>.
</para>
</listitem>
@ -1015,7 +1018,7 @@ lo_import 152801
<note>
<para>
As of <application>psql</application> version 6.6 it is no longer
As of <application>psql</application> version 7.0 it is no longer
necessary, in fact, to save the command history as that will be done
automatically on program termination. The history is then
also automatically loaded every time <application>psql</application>
@ -1034,17 +1037,14 @@ lo_import 152801
Sets the internal variable <replaceable class="parameter">name</replaceable>
to <replaceable class="parameter">value</replaceable>. If no second argument
is given, the variable is unset (which is different from setting it to,
for example, and empty string: <literal>\set foo ''</literal>). If no
for example, an empty string: <literal>\set foo ''</literal>). If no
arguments are given, all currently defined variables are listed with their
values.
</para>
<para>
Valid variable names can contain lower-case characters, digits, and
underscores. In particular, no upper-case characters are allowed, as
those are reserved for certain <quote>magic</quote> variables and
environment variables. See the section about <application>psql</application>
variables for details.
Valid variable names can contain characters, digits, and underscores.
See the section about <application>psql</application> variables for details.
</para>
<para>
@ -1119,14 +1119,14 @@ lo_import 152801
</para>
<para>
<programlisting>
<programlisting>
test=> <userinput>\z</userinput>
Access permissions for database "test"
Relation | Access permissions
----------+-------------------------------------
my_table | {"=r","joe=arwR", "group staff=ar"}
(1 row )
</programlisting>
</programlisting>
Read this as follows:
<itemizedlist>
@ -1170,7 +1170,10 @@ Access permissions for database "test"
<listitem>
<para>
Escapes to a separate Unix shell or executes the Unix command
<replaceable class="parameter">command</replaceable>.
<replaceable class="parameter">command</replaceable>. The arguments
are not further interpreted, the shell will see them as is. If you wish
to capture the output of a shell command and/or use <application>psql</application>'s
variable substitution features, use the backticks (<literal>`</literal>).
</para>
</listitem>
</varlistentry>
@ -1290,7 +1293,7 @@ Access permissions for database "test"
<para>
Use the file <replaceable class="parameter">filename</replaceable>
as the source of queries instead of reading queries interactively.
After the file is processed, <application>terminates</application>.
After the file is processed, <application>psql</application> terminates.
This in many ways equivalent to the internal command <command>\i</command>.
</para>
</listitem>
@ -1514,12 +1517,12 @@ Access permissions for database "test"
<para>
The output looks similar to this:
<programlisting>
<programlisting>
~$ <userinput>psql -V</userinput>
Server: PostgreSQL 6.5.2 on i586-pc-linux-gnu, compiled by egcs
psql 6.6.0 on i586-pc-linux-gnu, compiled by gcc 2.8.1 (Oct 27 1999 15:15:04), long options,
readline, history, locale, assert checks
</programlisting>
</programlisting>
The <quote>Server</quote> line is identical to the one returned by the
backend function <function>version()</function> and thus might vary
if you query different servers by using different connection
@ -1553,7 +1556,7 @@ readline, history, locale, assert checks
</para>
<para>
As of version 6.6, <application>psql</application> automatically issues a
As of version 7.0, <application>psql</application> automatically issues a
password prompt whenever the backend requests password authentication.
Because this is currently based on a <quote>hack</quote> the automatic
recognition might mysteriously fail, hence this option to force a prompt.
@ -1606,37 +1609,38 @@ readline, history, locale, assert checks
<para>
<application>psql</application> provides variable substitution features
similar to common Unix command shells. Variables are simply name/values
similar to common Unix command shells. Variables are simply name/value
pairs, where the value can be any string of any length. To set variables,
use the <application>psql</application> meta-command <command>\set</command>:
<programlisting>
<programlisting>
testdb=> <userinput>\set foo bar</userinput>
</programlisting>
</programlisting>
sets the variable <quote>foo</quote> to the value <quote>bar</quote>. To retrieve
the content of the variable, precede the name with a dollar-sign and use it
as the argument of any slash command:
<programlisting>
<programlisting>
testdb=> <userinput>\echo $foo</userinput>
bar
</programlisting>
</programlisting>
Alternatively, the value can also be interpolated into a double-quoted (or backtick-quoted)
string, like so:
<programlisting>
<programlisting>
testdb=> <userinput>\echo "foo is now ${foo}."</userinput>
foo is now bar.
</programlisting>
</programlisting>
(The curly braces are required. This is not <productname>Perl</productname>.) No variable substitution
will be performed in single-quoted strings or in any of the backslash commands
that have special parsing rules (<command>\copy</command>, <command>\help</command>).
that have special parsing rules (e.g., <command>\copy</command>).
</para>
<note>
<para>
The arguments of <command>\set</command> are subject to the same substitution
rules as with other commands. Thus you can construct interesting references
such as <literal>\set "${foo}bar" 'something'</literal> and get <quote>variable
variables</quote> of <productname>Perl</productname> or <productname><acronym>PHP</acronym></productname>
fame. Unfortunately (or fortunately?), there is not way to do anything useful
such as <literal>\set "${foo}bar" 'something'</literal> and get <quote>soft
links</quote> or <quote>variable variables</quote> of <productname>Perl</productname>
or <productname><acronym>PHP</acronym></productname> fame, respectively.
Unfortunately (or fortunately?), there is not way to do anything useful
with these constructs. (<literal>\echo ${${foo}}</literal> doesn't work.) On the
other hand, <literal>\set bar $foo</literal> is a perfectly valid way to copy
a variable.
@ -1645,14 +1649,21 @@ foo is now bar.
<para>
<application>psql</application>'s internal variable names can consist of
lower-case letters, numbers, and underscores in any order and any number of
them. Upper-case letters are not allowed. (There is a reason for that. Keep reading.)
If you attempt to refer to a variable that does not consist of those
characters <application>psql</application> first checks if it is the name of
one of several defined <quote>magic</quote> variables. Those variables you cannot
set but they always have a value. By convention they all start with an
upper-case letter. Finally, if no match is found that way, the value of
the respective environment variable is substituted.
letters, numbers, and underscores in any order and any number of them.
It is recommended, however, that you stick to lower-case letters and do not
begin with a digit. The partial rationale for this follows.
</para>
<para>
If you attempt to refer to a variable that is not set,
<application>psql</application> first checks if it is the name of one of
several defined <quote>magic</quote> variables. Those variables are
maintained internally and always have a value (at least when their semantics
permit it). By convention they all start with an upper-case letter. You can
set those variables manually, but that will <quote>shadow</quote> their
special meaning, until you unset your personal copy. Finally, if no match is
found that way, the value of the respective environment variable is
substituted.
</para>
<para>
@ -1660,7 +1671,10 @@ foo is now bar.
<envar>Version</envar> which contains a string with the version of
<application>psql</application>; <envar>Database</envar>, <envar>Host</envar>,
<envar>Port</envar>, <envar>User</envar> are the currently active
connection options.
connection options. <envar>LastOid</envar> contains the oid that was the
result of the last <command>INSERT</command> or <command>\lo_import</command>
command. If the last command was not one of those two, the value
is undefined.
</para>
<para>
@ -1673,19 +1687,6 @@ foo is now bar.
only care whether or not are they set, not what to. A list of all specially
treated variables follows.
<variablelist>
<varlistentry>
<term><envar>description</envar></term>
<listitem>
<para>
If set, the various <command>\d*</command> commands as well as
<command>\l</command> and <command>\lo_list</command> show object
descriptions along with the normal information. (Except for
<command>\dd</command> which always shows descriptions as this
is its very purpose.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><envar>die_on_error</envar></term>
<listitem>
@ -1731,25 +1732,29 @@ foo is now bar.
<term><envar>lo_transaction</envar></term>
<listitem>
<para>
If you use the <productname>PostgreSQL</productname> large object interface to store
data that does not fit into one tuple specially all the operations must be contained
in a transaction block. (See the documentation of the large object interface for
more information.) Since <application>psql</application> has no way to keep track if
you already have a transaction in progress when you call one of its internal commands
<command>\lo_export</command>, <command>\lo_import</command>, <command>\lo_unlink</command>
it must take some arbitrary action. This action could either be to roll back any transaction
that might already be in progress, or to commit any such transaction, or to do nothing
at all. In the latter case you must provide you own <command>BEGIN</command>/<command>END</command>
block or the results are unpredictable (usually resulting in the desired action not being
performed anyway).
If you use the <productname>PostgreSQL</productname> large object
interface to specially store data that does not fit into one tuple,
all the operations must be contained in a transaction block. (See the
documentation of the large object interface for more information.) Since
<application>psql</application> has no way to keep track if you already
have a transaction in progress when you call one of its internal
commands <command>\lo_export</command>, <command>\lo_import</command>,
<command>\lo_unlink</command> it must take some arbitrary action. This
action could either be to roll back any transaction that might already
be in progress, or to commit any such transaction, or to do nothing at
all. In the latter case you must provide you own
<command>BEGIN TRANSACTION</command>/<command>COMMIT</command> block or
the results will be unpredictable (usually resulting in the desired
action not being performed anyway).
</para>
<para>
To choose what you want to do you set this variable to one of
<quote>rollback</quote>, <quote>commit</quote>, or <quote>nothing</quote>. The default is
to roll back the transaction. If you just want to load one or a few objects this is fine.
However, if you intend to transfer many large objects, it might be advisable to
provide one explicit transaction block around all commands.
<quote>rollback</quote>, <quote>commit</quote>, or <quote>nothing</quote>.
The default is to roll back the transaction. If you just want to load one
or a few objects this is fine. However, if you intend to transfer many
large objects, it might be advisable to provide one explicit transaction
block around all commands.
</para>
</listitem>
</varlistentry>
@ -1794,16 +1799,6 @@ foo is now bar.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><envar>sql_interpol</envar></term>
<listitem>
<para>
The escape character for <acronym>SQL</acronym> variable interpolation. See below.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
@ -1817,48 +1812,37 @@ foo is now bar.
<para>
An additional useful feature of <application>psql</application> variables
is that you can substitute (<quote>interpolate</quote>) them into
regular <acronym>SQL</acronym> statements. In order not to break existing
<acronym>SQL</acronym> statements, you must choose your own special
character that tells <application>psql</application> that you wish to
interpolate the value of a variable here. You do this by setting the
variable <envar>sql_interpol</envar>. Only the first character will be
looked at. You can set this variable to anything you want but, for instance,
letters, numbers, semicolons, or backslashes will not make your life easier.
Reasonable choices include the dollar (<quote>$</quote>) and pound
(<quote>#</quote>) signs.
<programlisting>
testdb=> <userinput>\set sql_interpol '#'</userinput>
</programlisting>
</para>
<para>
Once this is set up, whenever <application>psql</application> sees the
magic character where it would expect a query, it will continue scanning
until it sees the same character again and will interpret anything in
between as a variable name.
<programlisting>
regular <acronym>SQL</acronym> statements. The syntax for this is to prepend
the variable name with a colon (<literal>:</literal>).
<programlisting>
testdb=> <userinput>\set foo 'my_table'</userinput>
testdb=> <userinput>SELECT * FROM #foo#;</userinput>
</programlisting>
testdb=> <userinput>SELECT * FROM :foo;</userinput>
</programlisting>
would then query the table <literal>my_table</literal>. The value of the
variable is copied literally, so it can even contain unbalanced quotes or
backslash commands. You must make sure that it makes sense where you put it.
Variable interpolation will not be performed into quoted <acronym>SQL</acronym>
entities.
</para>
<para>
One possible application of this mechanism is to copy the contents of a file
A popular application of this facility is to refer to the last inserted
<acronym>OID</acronym> in subsequent statement to build a foreign key
scenario.
Another possible use of this mechanism is to copy the contents of a file
into a field. First load the file into a variable and then proceed as above.
<programlisting>
<programlisting>
testdb=> <userinput>\set content `cat my_file.txt`</userinput>
testdb=> <userinput>INSERT INTO my_table VALUES ('#content#');</userinput>
</programlisting>
testdb=> <userinput>\set content "'${content}'"</userinput>
testdb=> <userinput>INSERT INTO my_table VALUES (:content);</userinput>
</programlisting>
One possible problem with this approach is that <filename>my_file.txt</filename>
might contain single quotes. These need to be escaped so that
they don't cause a syntax error when the second line is processed. This
they don't cause a syntax error when the third line is processed. This
could be done with the program <application>sed</application>:
<programlisting>
<programlisting>
testdb=> <userinput>\set content `sed -e "s/'/\\\\\\'/g" < my_file.txt`</userinput>
</programlisting>
</programlisting>
Observe the correct number of backslashes (6)! You can resolve it this way: After
<application>psql</application> has parsed this line, it passes
<literal>sed -e "s/'/\\\'/g" < my_file.txt</literal> to the shell. The shell
@ -2003,15 +1987,15 @@ testdb=> <userinput>\set content `sed -e "s/'/\\\\\\'/g" < my_file.txt`</userinp
<para>
The first example shows how to spread a query over several lines of input.
Notice the changing prompt.
<programlisting>
<programlisting>
testdb=> <userinput>CREATE TABLE my_table (</userinput>
testdb-> <userinput> first int4 not null default 0,</userinput>
testdb-> <userinput> second text</userinput>
testdb-> <userinput>);</userinput>
CREATE
</programlisting>
</programlisting>
Now look at the table definition again:
<programlisting>
<programlisting>
testdb=> <userinput>\d my_table</userinput>
Table "my_table"
Attribute | Type | Info
@ -2019,15 +2003,15 @@ testdb=> <userinput>\d my_table</userinput>
first | int4 | not null default 0
second | text |
</programlisting>
</programlisting>
At this point you decide to change the prompt to something more
interesting:
<programlisting>
<programlisting>
testdb=> <userinput>\set prompt1 '%n@%m %~%R%# '</userinput>
peter@localhost testdb=>
</programlisting>
</programlisting>
Let's assume you have filled the table with data and want to take a look at it:
<programlisting>
<programlisting>
peter@localhost testdb=> SELECT * FROM my_table;
first | second
-------+--------
@ -2037,11 +2021,11 @@ peter@localhost testdb=> SELECT * FROM my_table;
4 | four
(4 rows)
</programlisting>
</programlisting>
Notice how the int4 colums in right aligned while the text column in left aligned.
You can make this table look differently by using the <command>\pset</command>
command.
<programlisting>
<programlisting>
peter@localhost testdb=> <userinput>\pset border 2</userinput>
Border style is 2.
peter@localhost testdb=> <userinput>SELECT * FROM my_table;</userinput>
@ -2079,9 +2063,9 @@ one,1
two,2
three,3
four,4
</programlisting>
</programlisting>
Alternatively, use the short commands:
<programlisting>
<programlisting>
peter@localhost testdb=> <userinput>\a \t \x</userinput>
Output format is aligned.
Tuples only is off.
@ -2099,7 +2083,7 @@ second | three
-[ RECORD 4 ]-
first | 4
second | four
</programlisting>
</programlisting>
</para>
</refsect1>
@ -2123,10 +2107,10 @@ second | four
compatibility this is still supported to some extent but I am not
going to explain the details here as this use is discouraged. But
if you get strange messages, keep this in mind. For example
<programlisting>
<programlisting>
testdb=> <userinput>\foo</userinput>
Field separator is "oo".
</programlisting>
</programlisting>
is perhaps not what one would expect.
</para>
</listitem>
@ -2138,7 +2122,8 @@ Field separator is "oo".
and attempting to get along with each other. Sometimes they do, sometimes
they don't. An excellent example of this can be seen in section
<quote><xref linkend="APP-PSQL-sql-interpol" endterm="APP-PSQL-sql-interpol-title"></quote>.
Changing this situation, however, is beyond feasability.
There are vague dreams of using <application>flex</application> in the future,
but it won't happen soon.
</para>
</listitem>
@ -2151,6 +2136,15 @@ Field separator is "oo".
these limits sooner rather than later.
</para>
</listitem>
<listitem>
<para>
The number of options for a backslash command is limited, probably to 16.
You can easily change this in the source code, and perhaps I will get around
to fixing this one day (see previous item). Not that there is any command
that actually uses that many options though.
</para>
</listitem>
</itemizedlist>
</refsect2>
@ -2169,9 +2163,9 @@ Field separator is "oo".
<para>
The present version is the result of a major clean-up and re-write in 1999 by
<ulink URL="mailto:peter_e@gmx.net">Peter Eisentraut</ulink> in preparation for release 7.0.
Many people had again contributed their ideas. The author would also like
to recognize the influence of <application>tcsh</application> at a number
of places.
Many people had again contributed their ideas. A bunch of features were stolen
from various shells (in case you hadn't noticed), in particular
<application>tcsh</application>.
</para>
</refsect2>
@ -2197,9 +2191,9 @@ Field separator is "oo".
<filename>readline/history.h</filename>) in appropriate directories. If
you have the library and header files installed in an obscure place you
must tell <filename>configure</filename> about them, for example:
<programlisting>
<programlisting>
$ ./configure --with-includes=/opt/gnu/include --with-libraries=/opt/gnu/lib ...
</programlisting>
</programlisting>
Then you have to recompile <application>psql</application> (not necessarily
the entire code tree).
</para>