places --- that risks corrupting data structures, losing sync with the
backend, etc.  We now longjmp only from calls to readline, fgets, and
fread, which we assume are coded to protect themselves against interrupts
at undesirable times.  This requires adding explicit tests for
cancel_pressed in long-running loops, but on the whole it's far cleaner.
Martijn van Oosterhout and Tom Lane.

failure to enter commands in history if canceled by control-C, other
infelicities.

	o  remove many WIN32_CLIENT_ONLY defines
	o  add WIN32_ONLY_COMPILER define
	o  add 3rd argument to open() for portability
	o  add include/port/win32_msvc directory for
	   system includes

Magnus Hagander

than only if there is already history.

making it volatile.

executed, like it did for 8.1.X.

the query.

E'...' syntax for strings in order to track the backend.

and there's only one place that's a kluge, ie, appendStringLiteralConn.
Note that pg_dump itself doesn't use appendStringLiteralConn, so its
behavior is not affected; only the other utility programs care.

NOT the thing to use here.

        o  turns off escape_string_warning in pg_dumpall.c
        o  optionally use E'' for \password (undocumented option?)
        o  honor standard_conforming-strings for \copy (but not
           support literal E'' strings)
        o  optionally use E'' for \d commands
        o  turn off escape_string_warning for createdb, createuser,
           droplang

and standard_conforming_strings; likewise for the other client programs
that need it.  As per previous discussion, a pg_dump dump now conforms
to the standard_conforming_strings setting of the source database.
We don't use E'' syntax in the dump, thereby improving portability of
the SQL.  I added a SET escape_strings_warning = off command to keep
the dumps from getting a lot of back-chatter from that.

in place though, so that it plays nicely with older servers.

Per discussion.

'off'. This allows pg_dump output with standard_conforming_strings =
'on' to generate proper strings that can be loaded into other databases
without the backslash doubling we typically do.  I have added the
dumping of the standard_conforming_strings value to pg_dump.

I also added standard backslash handling for plpgsql.

during COPY OUT.  Andreas Pflug, some editorialization by moi.

throw warnings for 100%-SQL-standard constructs, clean up some minor
infelicities, try to un-break ecpg to the best of my ability.  (It's not clear
how ecpg is going to find out the setting of standard_conforming_strings,
though.)  I think pg_dump still needs work, too.

CONNECTION, fix a number of places that were missed (eg pg_dump support),
avoid executing an extra search of pg_database during startup.

Philip Yarra

Per Martijn van Oosterhout.

to fix regressions introduced in the recent patch adding additional
\connect options. This is based on work by Volkan YAZICI, although
this version of the patch doesn't bear much resemblance to Volkan's
version.

\connect takes 4 optional arguments: database name, user name, host
name, and port number. If any of those parameters are omitted or
specified as "-", the value of that parameter from the previous
connection is used instead; if there is no previous connection,
the libpq default is used. Note that this behavior makes it
impossible to reuse the libpq defaults without quitting psql and
restarting it; I don't really see the use case for needing to do
that.

whitespace issues nearby.

DROP OWNED BY is actually a bit kludgy, but it seems better to do it this way
rather than duplicating the words_after_create list just to add a single
element.

> 1) Fix the problems with the \s command.
> When the saveHistory is executed by the \s command we must not do the
> conversion \n -> \x01  (per
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg00317.php )
>
> 2) Fix the handling of Ctrl+C
>
> Now when you do
> wsdb=# select 'your long query here '
> wsdb-#
> and press afterwards the CtrlC the line "select 'your long query here
'"
> will be in the history
>
> (partly per
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg00297.php )
>
> 3) Fix the handling of commands with not closed brackets, quotes,
double
> quotes. (now those commands are not splitted in parts...)
>
> 4) Fix the behaviour when SINGLELINE mode is used. (before it was
almost
> broken ;(

Sergey E. Koposov

during parse analysis, not only errors detected in the flex/bison stages.
This is per my earlier proposal.  This commit includes all the basic
infrastructure, but locations are only tracked and reported for errors
involving column references, function calls, and operators.  More could
be done later but this seems like a good set to start with.  I've also
moved the ReportSyntaxErrorPosition logic out of psql and into libpq,
which should make it available to more people --- even within psql this
is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.

Kevin Grittner

remain as part of the multi-line query.

statements before the multi-line statement, rather than inside the
multi-line statement.

/dev/tty, but it isn't a device file and doesn't work as expected.

This fixes a known bug where psql does not prompt for a password on some
Win32 systems.

Backpatch to 8.1.X.

Robert Kinberg

instead of the old deprecated ones.
Volkan Yazici, with some editorializing by moi.

Hiroshi Saito

> True, but they're not being used where you'd expect. This seems to be
> something to do with the fact that it's not pg_authid which is being
> accessed, but rather the view pg_roles.

I looked into this and it seems the problem is that the view doesn't
get flattened into the main query because of the has_nullable_targetlist
limitation in prepjointree.c.  That's triggered because pg_roles has
        '********'::text AS rolpassword
which isn't nullable, meaning it would produce wrong behavior if
referenced above the outer join.

Ultimately, the reason this is a problem is that the planner deals only
in simple Vars while processing joins; it doesn't want to think about
expressions.  I'm starting to think that it may be time to fix this,
because I've run into several related restrictions lately, but it seems
like a nontrivial project.

In the meantime, reducing the LEFT JOIN to pg_roles to a JOIN as per
Peter's suggestion seems like the best short-term workaround.

Joachim Wieland

used by multi-byte sequences, but futher invesetigation might prove this
to be false.