> * Add database name and user name to logging options

wait for the postmaster to actually exit.  Otherwise running repeated
'make check's tends to misbehave, because we try to remove and recreate
the data directory while the old PM is still alive.

bottom.  Otherwise we fail to moveright when the root page was split while
we were "in flight" to it.  This is not a significant problem when the root
is above the leaf level, but if the root was also a leaf (ie, a single-page
index just got split) we may return the wrong leaf page to the caller,
resulting in failure to find a key that is in fact present.  Bug has existed
at least since 7.1, probably forever.

CREATE TABLE (or ALTER TABLE SET DEFAULT), rather than postponing it to
the time that the default is inserted into an INSERT command by the
rewriter.  This reverses an old decision that was intended to make the
world safe for writing
	f1 timestamp default 'now'
but in fact merely made the failure modes subtle rather than obvious.
Per recent trouble report and followup discussion.

initdb forced since there is a chance that stored default expressions
will change.

reason not to: it fails for an 'invalid' abstime.  Per bug report
of today's date.

heuristic determination of day vs month in date/time input.  Add the
ability to specify that input is interpreted as yy-mm-dd order (which
formerly worked, but only for yy greater than 31).  DateStyle's input
component now has the preferred spellings DMY, MDY, or YMD; the older
keywords European and US are now aliases for the first two of these.
Per recent discussions on pgsql-general.

these things were added at different times by different people ;-).
Includes Aizaz Ahmed's patch to remove duplicate array in help_config.c.

materialized.

New items have been added to GucContext and GucSource enums, but of
course they were not added to the corresponding GucContextName[] and
GucSourceName[] arrays in the patch. Here's a new patch to fix the
resulting bugs.

Joe Conway

internal errors.

I'd have to disagree with regards to the memory leaks not being worth
a mention - any such leak can cause problems when the PostgreSQL
installation is either unattended, long-living andor has very high
connection levels. Half a kilobyte on start-up isn't negligible in
this light.

Regards, Lee.

Tom Lane writes:
 > Lee Kindness <lkindness@csl.co.uk> writes:
 > > Guys, attached is a patch to fix two memory leaks on start-up.
 >
 > I do not like the changes to miscinit.c.  In the first place, it is not
 > a "memory leak" to do a one-time allocation of state for a proc_exit
 > function.  A bigger complaint is that your proposed change introduces
 > fragile coupling between CreateLockFile and its callers, in order to
 > save no resources worth mentioning.  More, it introduces an assumption
 > that the globals directoryLockFile and socketLockFile don't change while
 > the postmaster is running.  UnlinkLockFile should unlink the file that
 > it was originally told to unlink, regardless of what happens to those
 > globals.
 >
 > If you are intent on spending code to free stuff just before the
 > postmaster exits, a better fix would be for UnlinkLockFile to free its
 > string argument after using it.

Lee Kindness

the bulk of the heavy lifting ...

the new timetravel.c,
new timetravel.README (cut from spi/README and modified),
modified timetravel.sql.in
and modified timetravel.example.

Features:
- optionally 3 parameter for insert/update/delete user name

- work with CREATE UNIQUE INDEX ixxx on table xxx
(unique_field,time_off);
    (the  original version was work with unique index on 6.5.0-6.5.3,
and not work on 7.3.2,7.3.3)
     (before 6.5.0 and between 6.5.3 and 7.3.2 I dont know)

- get_timetravel(tablename) function for check timetravel-status.

- timetravel trigger not change  oid of the active record. (it is not a
good feature, because the  old version is automatice prevent the paralel
update with "where oid=nnn")

B?jthe Zolt?n

>>ISTM that "source" is worth knowing.
>
> Hm, possibly.  Any other opinions?

This version has the seven fields I proposed, including "source". Here's
an example that shows why I think it's valuable:

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name    | enable_seqscan
setting | on
context | user
vartype | bool
source  | default
min_val |
max_val |

regression=# update pg_settings set setting = 'off' where name =
'enable_seqscan';
-[ RECORD 1 ]---
set_config | off

regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name    | enable_seqscan
setting | off
context | user
vartype | bool
source  | session
min_val |
max_val |

regression=# alter user postgres set enable_seqscan to 'off';
ALTER USER

(log out and then back in again)

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name    | enable_seqscan
setting | off
context | user
vartype | bool
source  | user
min_val |
max_val |

In the first case, enable_seqscan is set to its default value. After
setting it to off, it is obvious that the value has been changed for the
session only. In the third case, you can see that the value has been set
specifically for the user.

Joe Conway

>>Sounds like all that's needed for your case. But to be complete, in
>>addition to changing tablefunc.c we'd have to:
>>1) come up with a new function call signature that makes sense and does
>>not cause backward compatibility problems for other people
>>2) make needed changes to tablefunc.sql.in
>>3) adjust the README.tablefunc appropriately
>>4) adjust the regression test for new functionality
>>5) be sure we don't break any of the old cases
>>
>>If you want to submit a complete patch, it would be gratefully accepted
>>-- for review at least ;-)
>
> Here's the patch, at least for steps 1-3

Nabil Sayegh
Joe Conway

annoyed me the other day while I was documenting my current project. It
makes pg_dump use the same layout for types as for tables, by putting "\n\t"
before the first field and "\n" before the final ");"

Can't really justify this too much except to say I had an itch and I
scratched it ;-)

Andrew Dunstan

  psql4win32.patch  - changes in the psql source code
  psql-ref.patch    - changes in the documentation psql-ref.sgml
                      (for new builtin variable WIN32_CONSOLE)

To apply them use "patch -p 1" in the root directory of the
postgres source directory.

These patches fix the following problems of psql on Win32
(all changes only have effect #ifdef WIN32):

  a) Problem:  Static library libpq.a did not work
     Solution: Added WSAStartup() in fe-connect.c

  b) Problem:  Secret Password was echoed by psql
     Solution: Password echoing disabled in sprompt.c

  c) Problem:  8bit characters were displayed/interpreted wrong in psql
               This is due to the fact that the Win32 "console" uses a
               different encoding than the rest of the Windows system
     Solution: Introduced a new psql variable WIN32_CONSOLE
               When set with "\set WIN32_console", the function OemToChar()
               is applied after reading input and CharToOem() before
               displaying Output

Christoph Dalitz

tested on both redhat 8 and FreebSD.
--
Mike Nolan

that the regression tests for foreign keys didn't seem to test
a deferred constraint that was not satisified by a later
statement and was not made immediate by set constraints,
so here's a simple added test with a single invalid insert and
a commit.

Stephan Szabo

>>that you cannot change the value, similar to the argument variables:
>
> Perhaps you shouldn't mark it isconst; then it would actually have some
> usefulness (you could use it directly as a temporary variable to hold
> the intended result).  I can't see much value in aliasing it if it's
> const, either.

OK; the only change in this version is "isconst = false;". Now you can
use $0 as a result placeholder if desired. E.g.:

create or replace function tmp(anyelement, anyelement) returns anyarray as '
declare
  v_ret alias for $0;
  v_el1 alias for $1;
  v_el2 alias for $2;
begin
  v_ret := ARRAY[v_el1, v_el2];
  return v_ret;
end;
' language 'plpgsql';

create table f(f1 text, f2 text, f3 int, f4 int);
insert into f values ('a','b',1,2);
insert into f values ('z','x',3,4);

select tmp(f1,f2) from f;
select tmp(f3,f4) from f;


Joe Conway

Slawomir Sudnik

doing '2003-07-30' -> '2003-04-01', '2003-11-30' ->'2003-07-01'

B?jthe Zolt?n

modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:

http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php

My original less-flexible patch and the ensuing thread are archived at:

http://dbforums.com/t623845.html

Attached is a new patch, including documentation.

To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:

sslmode   description
-------   -----------
disable   Unencrypted non-SSL only
allow     Negotiate, prefer non-SSL
prefer    Negotiate, prefer SSL (default)
require   Require SSL

The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:

pg_hba.conf line types
----------------------
host       applies to either SSL or regular connections
hostssl    applies only to SSL connections
hostnossl  applies only to regular connections

These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.

I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)

Jon Jensen

look ... I'm not real certain which errors are strictly internal and which
are likely to be provoked by users.

> * -Allow SSL-enabled clients to turn off SSL transfers