Re: [HACKERS] Boolean casting in 7.3 -> changed?
On Wednesday 27 November 2002 06:23, Tom Lane wrote: (B> Ian Barwick <[EMAIL PROTECTED]> writes: (B> > in 7.3 the following no longer works: (B> > template1=> select 0::bool; (B> > ERROR: Cannot cast type integer to boolean (B> (B> Note that both old and new versions reject (B> select 0::int4::bool; (B> (B> I believe the behavioral change is a consequence of Rod Taylor's (B> DOMAIN patch: it essentially eliminated the old parser_typecast_constant() (B> routine in order to ensure that constraints associated with a domain (B> would get applied in examples like "select 0::domaintypename". (B> (B> I wasn't totally happy with Rod's patch, for reasons that I couldn't put (B> my finger on at the time, but perhaps my hindbrain understood that there (B> would be noticeable behavioral changes. But be that as it may, the code (B> is in there now and is unlikely to get reverted. There isn't any place (B> in our docs that promises that you can coerce an integer-looking literal (B> to bool --- and one could argue that allowing such is just opening the (B> door for typos. (B (BThanks for the explanation. I'm not screaming for a reversion ;-), but (Bchanging behaviour which was implicitly valid in previous (Bversions is bound to cause a few people a little head scratching (Bwhen converting applications to 7.3 (I'm sure I can't be the only one). (B (BHow about a line in HISTORY under "Migration to version 7.3" along (Bthe lines of: (B (B"Casting integers to boolean (for example, 0::bool) is no longer allowed, (Buse '0'::bool instead". (B (B (BIan Barwick ([EMAIL PROTECTED] (B (B (B---(end of broadcast)--- (BTIP 5: Have you checked our extensive FAQ? (B (Bhttp://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Boolean casting in 7.3 -> changed?
A quick question: in 7.3 the following no longer works: template1=> select 0::bool; ERROR: Cannot cast type integer to boolean The statement must be rewritten as this: template1=> select '0'::bool; bool -- f (1 row) Is there a reason for this? I ask because the former query works in 7.1.3 and 7.2.1, but I haven't seen any mention of a change in 7.3 (at least not in the release notes). Apologies if this has been discussed to death previously, but it might be worth mentioning somewhere as a "gotcha". Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Request for supported platforms
On Tuesday 29 October 2002 01:56, Bruce Momjian wrote: > Sorry, Ian, here is the patch I applied. You can apply this to whatever > version you are using and test Irix with that, rather than having to > grab CVS. OK, I have carried out make check with the updated tests but got FAILED on the same four tests (abstime, tinterval, horology, join). The failures are subtly different (see here for new regression diff): http://home.akademie.de/~IBarwick/IRIX_65_1.regression.diffs Having looked at them again I see the following: - in horology the timestamp tests seem to have succeeded (presumably the previous failures were triggered by the change to winter time); - the tests which are still failing in abstime, tinterval and horology all refer to dates before 1970, where AFAICS they are all out by one hour; possibly this explanation?: "Some systems using older time zone libraries fail to apply daylight-saving corrections to dates before 1970, causing pre-1970 PDT times to be displayed in PST instead. This will result in localized differences in the test results." (cf. http://www.postgresql.org/idocs/index.php?regress-evaluation.html ); - the join tests are failing slightly differently; I would suggest that this is because the ORDER BY is still not explicit enough, and for what ever reason under IRIX the undefined result row orderings are in a different order to every other platform... e.g. with this statement: SELECT '' AS "xxx", J1_TBL.i, j, t, k FROM J1_TBL LEFT OUTER JOIN J2_TBL USING (i) ORDER BY i; xxx | i | j | t | k -+---+---+---+ | 0 | | zero | | 1 | 4 | one | -1 | 2 | 3 | two | 2 | 2 | 3 | two | 4 | 3 | 2 | three | -3 | 4 | 1 | four | | 5 | 0 | five | -5 | 5 | 0 | five | -5 | 6 | 6 | six | | 7 | 7 | seven | | 8 | 8 | eight | | | 0 | zero | | | | null | (13 rows) the order of the last two rows is not defined. The expected order according to the regression tests is: | | | null | | | 0 | zero | Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
On Tuesday 29 October 2002 00:08, Bruce Momjian wrote: > Neil Conway wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Ports list updated: > > > > Shouldn't the "join" regression test failure be fixed? > > OK, I have updated the join regression test to add ORDER BY in the > queries Irix differed. Ian, would you retest the CVS version of > PostgreSQL to see if all the regression tests pass now? For confirmation: IIRC CVS now requires the latest Bison (1.75)? (The Irix machine has 1.35). Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Request for supported platforms
On Saturday 26 October 2002 04:17, Bruce Momjian wrote: > > OK, Tom will be away next week, and Thomas will too. I can do it. > Folks. start sending in those plaform reports, OS name and version > number please. > > The current platform list is: > > http://developer.postgresql.org/docs/postgres/supported-platforms.html ianb > uname -a IRIX64 Komma 6.5 07121148 IP27 ianb > gcc -v Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix6.5/3.2/specs Configured with: ../configure --with-ld=/usr/bin/ld Thread model: single gcc version 3.2 Building 7.3b3; failed on four tests: abstime, tinterval, horology, join The first three are I presume due to the change to winter time (CET) earlier today (27.10), see http://www.postgresql.org/idocs/index.php?regress-evaluation.html#AEN18382 ; the join failure is a row ordering difference. Should it be of any use the regression.diffs file is here: http://home.akademie.de/~IBarwick/IRIX_65_regression.diffs Otherwise no apparent problems and the server started fine. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Please help
On Monday 21 October 2002 15:42, Olivier PRENANT wrote: > Hi all, > > Without modifying anything, postgresql (since today) has a strange > behavior: > > All connections are rejected with No space left on device. > > There's plenty of space in shm, disk... I have no idea whether it's relevant, but maybe you have a problem with semaphores? See: http://www.ca.postgresql.org/docs/faq-english.html#3.4 (A lack of available semaphores can also produce the message "No space left on device.") Sorry I can't help any further. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] No bison and NAMEDATALEN > 31: initdb failure?
On Tuesday 30 July 2002 00:23, Tom Lane wrote: > Ian Barwick <[EMAIL PROTECTED]> writes: > > - Does src/include/postgres_ext.h count as a parser definition file? > > No, it doesn't. Your experience sounds like you may have neglected to > do a full rebuild after altering NAMEDATALEN. (By default, we don't > compute object-file dependencies, so it's up to you to do "make clean" > after changing fundamental parameters.) Exactly what I thought. I actually deleted the source tree and unpacked at a different location, several times. It was only after installing initdb Bison that initdb suddenly worked... > It's unlikely that installing > Bison per se affected anything --- unless possibly you had corrupted > copies of gram.c etc. ... tried the same with a fresh source download on a Linux machine and got similar results. Clearly something odd is happening, but I assume it's a local problem. As it's not the most important issue right now, will see if I can make any sense (and report back should I find anything of interest). Thanks, Ian Barwick [EMAIL PROTECTED] PS The subject should have read "(...) NAMEDATELEN > 32 (...)", i.e. the default value. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] No bison and NAMEDATALEN > 31: initdb failure?
I had occasion (and a perfectly good reason) to install 7.1.3 on a fresh server [1]. Installation succeeded as normal, data failed to load because some relation names go beyond 31 characters. , alter NAMEDATALEN, recompile. initdb fails immediately after the message "creating template1 database in...". There followed much wrinkling of brows, gnashing of directories, recompilation from afresh etcera, during the course of which I noticed the following output from configure: configure: warning: *** Without Bison you will not be able to build PostgreSQL from CVS or *** change any of the parser definition files. You can obtain Bison from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Bison *** output is pre-generated.) To use a different yacc program (possible, *** but not recommended), set the environment variable YACC before running *** 'configure'. This being because I had omitted to install Bison. As I wasn't building from CVS, and mucking around with the parser definition files was not high on my list of priorities, it was only much later I hit on the idea of installing Bison, then rebuilding with higher NAMEDATALEN. And as if by magic initdb succeeded. (Note: initdb with no Bison but unchanged NAMEDATALEN also succeeded). For reference, 7.2.1 exhibits exactly the same behaviour [2]. I have poked around but have no idea what I'm looking for, so I'm not sure if this is intended behaviour. Questions: - Does src/include/postgres_ext.h count as a parser definition file? - If not shouldn't the above warning include something like "And don't even think about changing NAMEDATALEN"? Apologies if I've missed something obvious. Ian Barwick [EMAIL PROTECTED] [1] FreeBSD 4.6, installing from source [2] Sample output from initdb: ian > /home/ian/devel/postgres/pg721a/bin/initdb -D /tmp/pg721 The files belonging to this database system will be owned by user "ian". This user must also own the server process. creating directory /tmp/pg721... ok creating directory /tmp/pg721/base... ok creating directory /tmp/pg721/global... ok creating directory /tmp/pg721/pg_xlog... ok creating directory /tmp/pg721/pg_clog... ok creating template1 database in /tmp/pg721/base/1... initdb failed. Removing /tmp/pg721. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Schemas: status report, call for developers
On Wednesday 01 May 2002 06:38, Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> writes:
> > How can I restrict the query to the schemas in the
> > current search path, i.e. the schema names returned
> > by SELECT current_schemas() ?
>
> Well, this is the issue open for public discussion.
>
> We could define some function along the lines of
> "is_visible_table(oid) returns bool", and then you could use
> that as a WHERE clause in your query. But I'm worried about
> the performance implications --- is_visible_table() would have
> to do several retail probes of the system tables, and I don't
> see any way to optimize that across hundreds of table OIDs.
>
> I have a nagging feeling that this could be answered by defining
> a view on pg_class that only shows visible tables ... but I don't
> quite see how to define that efficiently, either. Ideas anyone?
(time passes...)
How about a function such as the one attached: "select_schemas_setof()"
which returns the OIDs of the schemas in the current search path as
a set. (Note: "select_schemas_setof()" as shown is a userspace C function.)
It works like this:
template1=# CREATE DATABASE schema_test;
CREATE DATABASE
template1=# \c schema_test
You are now connected to database schema_test.
schema_test=# CREATE OR REPLACE FUNCTION current_schemas_setof()
schema_test-# RETURNS setof OID
schema_test-# as '/path/to/current_schemas_setof.so'
schema_test-# LANGUAGE 'C';
CREATE FUNCTION
I can then do this:
schema_test=# CREATE SCHEMA foo;
CREATE SCHEMA
schema_test=# CREATE TABLE foo.mytab(col1 int, col2 text);
CREATE TABLE
schema_test=# CREATE SCHEMA bar;
CREATE SCHEMA
schema_test=# CREATE TABLE bar.mytab(col1 int, col2 text);
CREATE TABLE
schema_test=# SET search_path = public, foo, bar;
SET
schema_test=# SELECT current_schemas();
current_schemas
--
{public,foo,bar}
(1 row)
schema_test=# SELECT current_schemas_setof, n.nspname
schema_test-# FROM public.current_schemas_setof() cs, pg_namespace n
schema_test-# WHERE cs.current_schemas_setof = n.oid;
current_schemas_setof | nspname
--+
16563 | pg_temp_1
11 | pg_catalog
2200 | public
24828 | foo
24835 | bar
(3 rows)
With the function in place I can then create an SQL function like this:
CREATE OR REPLACE FUNCTION public.first_visible_namespace(name)
RETURNS oid
AS
'SELECT n.oid
FROM pg_namespace n, pg_class c, public.current_schemas_setof() cs
WHERE c.relname= $1
AND c.relnamespace=n.oid
AND n.oid= cs.current_schemas_setof
LIMIT 1'
LANGUAGE 'sql';
which can be used like this:
schema_test=# select public.first_visible_namespace('mytab');
first_visible_namespace
-
24828
(1 row)
i.e. finds the first visible schema containing an unqualified relation name.
24828 corresponds to the OID of schema "foo".
The following VIEW:
CREATE VIEW public.desc_table_view AS
SELECT n.nspname AS "Schema",
c.relname AS "Table",
a.attname AS "Column",
format_type (a.atttypid, a.atttypmod) AS "Type"
FROM pg_class c, pg_attribute a, pg_namespace n
WHERE a.attnum > 0
AND c.relkind IN ('r', 'v', 'S')
AND a.attrelid = c.oid
AND c.relnamespace=n.oid
AND n.oid IN (SELECT first_visible_namespace(c.relname))
ORDER BY a.attnum;
then provides a simplified simulation of psql's slash command \d [NAME] for
unqualified relation names, e.g.:
schema_test=# SELECT * FROM public.desc_table_view WHERE "Table" = 'mytab';
Schema | Table | Column | Type
+---++-
foo| mytab | col1 | integer
foo| mytab | col2 | text
(2 rows)
schema_test=# SET search_path= bar, foo, public;
SET
schema_test=# SELECT * FROM public.desc_table_view WHERE "Table" = 'mytab';
Schema | Table | Column | Type
+---++-
bar| mytab | col1 | integer
bar| mytab | col2 | text
(2 rows)
schema_test=# SET search_path= public;
SET
schema_test=# SELECT * FROM public.desc_table_view WHERE "Table" = 'mytab';
Schema | Table | Column | Type
+---++--
(0 rows)
which I think is the desired behaviour. Currently \d [NAME] produces this:
schema_test=# SET search_path= bar, foo, public;
SET
schema_test=# \d mytab
Table "mytab"
Column | Type | Modifiers
+-+---
col1 | integer |
col1 | integer |
col2 | text|
col2 | text|
i.e. finds and desc
Re: [HACKERS] Q: unexpected result from SRF in SQL
On Sunday 26 May 2002 17:58, Tom Lane wrote: (...) > If anyone does someday resurrect fjoin-like functionality, a reasonable > SQL-style syntax for invoking it would be > > SELECT (bar(1)).*; > > which would still leave us wanting to raise an error if you just write > "SELECT bar(1)". The reason why I posted the question is that I had defined a function that should have worked, but kept giving me back strange numbers, so I spent a whole five minutes trying to debug the function before I realised I was calling it in the wrong way (doh). An error here would be a Good Idea, IMHO. Ian Barwick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Q: unexpected result from SRF in SQL
Using a recent build (22.5) from CVS, if I create a set returning function in SQL like this: func_test=# CREATE TABLE foo (id INT, txt1 TEXT, txt2 TEXT); CREATE TABLE func_test=# INSERT INTO foo VALUES(1, 'Hello','World'); INSERT 24819 1 func_test=# func_test=# CREATE OR REPLACE FUNCTION bar(int) func_test-# RETURNS SETOF foo func_test-# AS 'SELECT * FROM foo WHERE id = $1' func_test-# LANGUAGE 'sql'; CREATE FUNCTION I can do this (expected result): func_test=# SELECT txt1, txt2 FROM bar(1); txt1 | txt2 ---+--- Hello | World (1 row) but also this: func_test=# select bar(1); bar --- 139059784 (1 row) What is this number? It often varies from query to query. Possibly an error-in-disguise because of something to do with the calling context? Just curious ;-) Ian Barwick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Set Returning Functions (SRF) - request for patch review
> > See contrib/dblink. The version in cvs HEAD has two that return sets -- > dblink() which returns an int, and dblink_get_pkey() which returns text. Thanks, now I can see what I was doing wrong Yours Ian Barwick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Set Returning Functions (SRF) - request for patch review and comment
On Monday 06 May 2002 18:51, Joe Conway wrote: (...) > Request for help: > - > So far I've tested with SQL and C functions. (...) Can you post an example of a function in C? (I'm trying out your patch from Friday). Thanks, Ian Barwick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Schemas: status report, call for developers
On Thursday 02 May 2002 05:33, Tom Lane wrote:
[on establishing whether a relation is in the search path]
> This doesn't yield much insight about cases where the match pattern
> includes a (partial?) schema-name specification, though. If I'm
> allowed to write something like "\z s*.t*" to find tables beginning
> with t in schemas beginning with s, should that include all schemas
> beginning with s? Only those in my search path (probably wrong)?
> Only those that I have USAGE privilege on? Not sure.
If namespace privileges are based around the Unix directory/file protection
model (as you stated in another thread, see:
http://geocrawler.com/archives/3/10/2002/4/450/8433871/ ), then
a wildcard search on the schema name should logically include
all visible schemas, not just the ones where the user has USAGE privilege.
Or put it another way, is there any reason to exclude information from
say \z which the user can find out by querying pg_class? At the moment
(at least in CVS from 30.4.02) a user can see permissions on tables in schemas
on which he/she has no USAGE privileges:
template1=# create database schema_test;
CREATE DATABASE
template1=# \c schema_test
You are now connected to database schema_test.
schema_test=# create schema foo;
CREATE
schema_test=# create table foo.bar (pk int, txt text);
CREATE
schema_test=# create schema foo2;
CREATE
schema_test=# create table foo2.bar (pk int, txt text);
CREATE
schema_test=# create user joe;
CREATE USER
schema_test=# grant usage on schema foo to joe;
GRANT
schema_test=# \c - joe
You are now connected as new user joe.
schema_test=> SELECT nspname AS schema,
schema_test->relname AS object,
schema_test->relkind AS type,
schema_test->relacl AS access
schema_test-> FROM pg_class c
schema_test-> INNER JOIN pg_namespace n
schema_test-> ON c.relnamespace=n.oid
schema_test-> WHERE relkind in ('r', 'v', 'S') AND
schema_test->relname NOT LIKE 'pg$_%%' ESCAPE '$' AND
schema_test->nspname || '.' || relname LIKE 'f%.b%';
schema | object | type | access
++--+
foo| bar| r|
foo2 | bar| r|
(2 rows)
i.e. user "joe" can see which objects exist in schema "foo2", even though
he has no USAGE privilege. (Is this behaviour intended?)
Yours
Ian Barwick
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Schemas: status report, call for developers
Tom Lane wrote:
> psql's \d command hasn't the foggiest idea that there might now be more
> than one pg_class entry with the same relname. It needs to be taught
> about that --- but even before that, we need to work out schema-aware
> definitions of the wildcard expansion rules for psql's backslash
> commands that accept wildcarded names. In the above example, probably
> "\d mytab" should have said "no such table" --- because neither foo nor
> bar were in my search path, so I should not see them unless I give a
> qualified name (eg, "\d foo.mytab" or "\d bar.mytab").
(and also in mail to Bill Cunningham)
> My gut feeling is that "\d mytab" should tell you about the same
> table that "select * from mytab" would find. Anything else is
> probably noise to you --
General consistency with SELECT behaviour sounds right to me.
> For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my*"
> sensible to support? I dunno yet.
My digestive organs tell me: an unqualified wildcard pattern should
stick to the search path; the search path should only be overridden
when the user explicitly provides a wildcard pattern for schema names.
This would be consistent with the behaviour of \d etc., i.e.
"\d mytab" should look for 'mytab' in the current search path;
"\dt my*" should look for tables beginning with "my" in the current
search path; "\dt f*.my*" would look for same in all schemas beginning
with "f"; and "\dt *.my*" would look in all schemas.
Problem: "wildcard pattern" is a bit of a misnomer, the relevant
commands take regular expressions, which means the dot in "\z f*.my*"
won't necessarily be the dot in "\z foo.mytab" - it would have to
be written "\z f*\\.my*". Though technically correct this
strikes me as counterintuitive, especially with the double escaping
(once for psql, once for the regex literal).
An alternative solution would be to allow the pattern matching
commands to accept either one ("\z my*") or two ("\z f* my*") regular
expressions; in the latter case the first regex is for the schema name,
the second for the object name. However, doing away with the dot altogether
is also counterintuitive and breaks with the usual schema denotation.
Proposal: in "wildcard" slash commands drop regular expressions and
use LIKE for pattern matching. This would enable commands such as
"\z f%.my%". (Would this mean major breakage? Is there an installed
base of scripts which rely on psql slash commands and regular expressions?)
I can't personally recall ever having needed to use a regular expression
any more complex than the wildcard pattern matching which could be implemented
just as well with LIKE. (Anyone requiring regular expression matching could
still create appropriate views).
Question - which output format is preferable?:
schema_test=# \z
Access privileges for database "schema_test"
Schema | Object | Access privileges
++---
public | bar|
foo| bar|
(2 rows)
or
schema_test=# \z
Access privileges for database "schema_test"
Object | Access privileges
+---
public.bar |
foo.bar|
(2 rows)
> If you've got time to work on fixing frontend code, or even helping
> to work out definitional questions like these (...)
Hmm, time for "ask not what your database can do for you but what
you can do for your database". I'm willing to put my keyboard where
my mouth is and take on psql once any outstanding questions are
cleared up, if noone better qualified than me comes
forward and provided someone takes a critical look at anything I do.
Yours
Ian Barwick
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Schemas: status report, call for developers
> For commands
> that accept wildcard patterns, what should happen --- should "\z my*"
> find these tables, if they're not in my search path? Is "\z f*.my*"
> sensible to support? I dunno yet.
Technical question - this query:
SELECT nspname AS schema,
relname AS object
FROM pg_class c
INNER JOIN pg_namespace n
ON c.relnamespace=n.oid
WHERE relkind in ('r', 'v', 'S') AND
relname NOT LIKE 'pg$_%%' ESCAPE '$'
produces a result like this:
schema | object
+
public | abc
foo| abc
foo| xyz
bar| xyz
(4 rows)
How can I restrict the query to the schemas in the
current search path, i.e. the schema names returned
by SELECT current_schemas() ?
Ian Barwick
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and output from \?
On Thursday 14 March 2002 22:40, Bruce Momjian wrote:
> > > I guess some of these weren't introduces by you, but if someone is
> > > going to fix this, he might as well take care of these.
> >
> > Will submit another patch in the morning (it's late here).
>
> Ian, do you have another version of this patch ready?
Patch attached (diff against CVS, replacing previous patch).
Ian Barwick
Index: help.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/help.c,v
retrieving revision 1.48
diff -c -r1.48 help.c
*** help.c 2002/03/11 18:26:20 1.48
--- help.c 2002/03/14 22:25:22
***
*** 177,183
if (pset.notty == 0 &&
(pagerenv = getenv("PAGER")) &&
(pagerenv[0] != '\0') &&
! screen_size.ws_row <= 39 &&
(fout = popen(pagerenv, "w")))
{
usePipe = true;
--- 177,183
if (pset.notty == 0 &&
(pagerenv = getenv("PAGER")) &&
(pagerenv[0] != '\0') &&
! screen_size.ws_row <= 46 &&
(fout = popen(pagerenv, "w")))
{
usePipe = true;
***
*** 189,242
fout = stdout;
/* if you add/remove a line here, change the row test above */
fprintf(fout, _(" \\a toggle between unaligned and aligned output mode\n"));
fprintf(fout, _(" \\c[onnect] [DBNAME|- [USER]]\n"
! "connect to new database (currently \"%s\")\n"),
PQdb(pset.db));
! fprintf(fout, _(" \\C [TITLE] set table title, or unset with no title\n"));
fprintf(fout, _(" \\cd [DIR] change the current working directory\n"));
fprintf(fout, _(" \\copy ... perform SQL COPY with data stream to the client host\n"));
fprintf(fout, _(" \\copyright show PostgreSQL usage and distribution terms\n"));
! fprintf(fout, _(" \\d [TABLE] describe table (or view, index, sequence)\n"));
! fprintf(fout, _(" \\d{t|i|s|v}... list tables/indexes/sequences/views\n"));
! fprintf(fout, _(" \\d{p|S|l} list access privileges, system tables, or large objects\n"));
! fprintf(fout, _(" \\dalist aggregate functions\n"));
! fprintf(fout, _(" \\dd [NAME] show comment for table, type, function, or operator\n"));
! fprintf(fout, _(" \\dflist functions\n"));
! fprintf(fout, _(" \\dolist operators\n"));
! fprintf(fout, _(" \\dTlist data types\n"));
! fprintf(fout, _(" \\du [PATTERN] lists all configured users or only those that match pattern\n"));
! fprintf(fout, _(" \\e [FILE] edit the query buffer or file with external editor\n"));
! fprintf(fout, _(" \\echo TEXT write text to standard output\n"));
! fprintf(fout, _(" \\encoding ENCODING set client encoding\n"));
! fprintf(fout, _(" \\f [SEPARATOR] set field separator, or unset if none\n"));
! fprintf(fout, _(" \\g [FILE] send SQL command to server (and write results to file or |pipe)\n"));
! fprintf(fout, _(" \\h NAMEhelp on syntax of SQL commands, * for all commands\n"));
fprintf(fout, _(" \\H toggle HTML output mode (currently %s)\n"),
ON(pset.popt.topt.format == PRINT_HTML));
fprintf(fout, _(" \\i FILEexecute commands from file\n"));
fprintf(fout, _(" \\l list all databases\n"));
fprintf(fout, _(" \\lo_export, \\lo_import, \\lo_list, \\lo_unlink\n"
! " large object operations\n"));
fprintf(fout, _(" \\o FILEsend all query results to file or |pipe\n"));
! fprintf(fout, _(" \\p show the content of the query buffer\n"));
! fprintf(fout, _(" \\pset VAR set table output option (VAR := {format|border|expanded|\n"
! " fieldsep|null|recordsep|tuples_only|title|tableattr|pager})\n"));
fprintf(fout, _(" \\q quit psql\n"));
! fprintf(fout, _(" \\qecho TEXTwrite text to query output stream (see \\o)\n"));
fprintf(fout, _(" \\r reset (clear) the query buffer\n"));
! fprintf(fout, _(" \\s [FILE] print history or save it to file\n"));
! fprintf(fout, _(" \\set NAME VALUE set internal variable\n"));
fprintf(fout, _(" \\t show only rows (currently %s)\n"),
ON(pset.popt.topt.tuples_only));
! fprintf(fout, _(" \\T [TAG_ATTR] set HTML table tag attributes, or unset if none\n"));
fprintf(fout, _(" \\timingtoggle timing of queries (currently %s)\n"),
ON(pset.timing));
fprintf(fout, _(" \\unset
