mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-10-01 23:33:26 +02:00
Information moved to doc/src/sgml/release.sgml.
This commit is contained in:
Thomas G. Lockhart
parent
596731dcf8
commit
10aaff0a40
@ -1,73 +0,0 @@
|
||||
From scrappy@ki.net Wed Aug 14 20:41:08 1996
|
||||
Status: RO
|
||||
X-Status:
|
||||
Received: from candle.pha.pa.us (maillist@s1-03.ppp.op.net [206.84.209.132]) by quagmire.ki.net (8.7.5/8.7.5) with ESMTP id UAA01234 for <scrappy@ki.net>; Wed, 14 Aug 1996 20:41:00 -0400 (EDT)
|
||||
Received: (from maillist@localhost) by candle.pha.pa.us (8.7.4/8.7.3) id UAA13966 for scrappy@ki.net; Wed, 14 Aug 1996 20:40:48 -0400 (EDT)
|
||||
From: Bruce Momjian <maillist@candle.pha.pa.us>
|
||||
Message-Id: <199608150040.UAA13966@candle.pha.pa.us>
|
||||
Subject: New migration file
|
||||
To: scrappy@ki.net (Marc G. Fournier)
|
||||
Date: Wed, 14 Aug 1996 20:40:47 -0400 (EDT)
|
||||
X-Mailer: ELM [version 2.4 PL25]
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 7bit
|
||||
|
||||
Here is a new migratoin file for 1.02.1. It includes the 'copy' change
|
||||
and a script to convert old ascii files.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
The following notes are for the benefit of users who want to migrate
|
||||
databases from postgres95 1.01 and 1.02 to postgres95 1.02.1.
|
||||
|
||||
If you are starting afresh with postgres95 1.02.1 and do not need
|
||||
to migrate old databases, you do not need to read any further.
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
In order to upgrade older postgres95 version 1.01 or 1.02 databases to
|
||||
version 1.02.1, the following steps are required:
|
||||
|
||||
1) start up a new 1.02.1 postmaster
|
||||
|
||||
2) Add the new built-in functions and operators of 1.02.1 to 1.01 or 1.02
|
||||
databases. This is done by running the new 1.02.1 server against
|
||||
your own 1.01 or 1.02 database and applying the queries attached at
|
||||
the end of thie file. This can be done easily through psql. If your
|
||||
1.01 or 1.02 database is named "testdb" and you have cut the commands
|
||||
from the end of this file and saved them in addfunc.sql:
|
||||
|
||||
% psql testdb -f addfunc.sql
|
||||
|
||||
Those upgrading 1.02 databases will get a warning when executing the
|
||||
last two statements because they are already present in 1.02. This is
|
||||
not a cause for concern.
|
||||
|
||||
* * *
|
||||
|
||||
If you are trying to reload a pg_dump or text-mode 'copy tablename to
|
||||
stdout' generated with a previous version, you will need to run the
|
||||
attached sed script on the ASCII file before loading it into the
|
||||
database. The old format used '.' as end-of-data, while '\.' is now the
|
||||
end-of-data marker. Also, empty strings are now loaded in as '' rather
|
||||
than NULL. See the copy manual page for full details.
|
||||
|
||||
sed 's/^\.$/\\./g' <in_file >out_file
|
||||
|
||||
If you are loading an older binary copy or non-stdout copy, there is no
|
||||
end-of-data character, and hence no conversion necessary.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
-- following lines added by agc to reflect the case-insensitive
|
||||
-- regexp searching for varchar (in 1.02), and bpchar (in 1.02.1)
|
||||
create operator ~* (leftarg = bpchar, rightarg = text, procedure = texticregexeq);
|
||||
create operator !~* (leftarg = bpchar, rightarg = text, procedure = texticregexne);
|
||||
create operator ~* (leftarg = varchar, rightarg = text, procedure = texticregexeq);
|
||||
create operator !~* (leftarg = varchar, rightarg = text, procedure = texticregexne);
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
This migration requires a complete dump of the 1.09 database and a
|
||||
restore of the database in 6.0.
|
||||
|
||||
Those migrating from earlier 1.* releases should first upgrade to 1.09
|
||||
because the COPY output format was improved from the 1.02 release.
|
||||
@ -1,94 +0,0 @@
|
||||
The following notes are for the benefit of users who want to migrate
|
||||
databases from postgres95 1.0 to postgres95 1.01.
|
||||
|
||||
If you are starting afresh with postgres95 1.01 and do not need
|
||||
to migrate old databases, you do not need to read any further.
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
In order to postgres95 version 1.01 with databases created with
|
||||
postgres95 version 1.0, the following steps are required:
|
||||
|
||||
1) Set the definition of NAMEDATALEN in src/Makefile.global to 16
|
||||
and OIDNAMELEN to 20.
|
||||
|
||||
2) Decide whether you want to use Host based authentication.
|
||||
|
||||
A) If you do, you must create a file name "pg_hba" in your top-level data
|
||||
directory (typically the value of your $PGDATA). src/libpq/pg_hba
|
||||
shows an example syntax.
|
||||
|
||||
B) If you do not want host-based authentication, you can comment out
|
||||
the line
|
||||
HBA = 1
|
||||
in src/Makefile.global
|
||||
|
||||
Note that host-based authentication is turned on by default, and if
|
||||
you do not take steps A or B above, the out-of-the-box 1.01 will
|
||||
not allow you to connect to 1.0 databases.
|
||||
|
||||
3) compile and install 1.01, but DO NOT do the initdb step.
|
||||
|
||||
4) before doing anything else, terminate your 1.0 postmaster, and
|
||||
backup your existing $PGDATA directory.
|
||||
|
||||
5) set your PGDATA environment variable to your 1.0 databases, but set up
|
||||
path up so that 1.01 binaries are being used.
|
||||
|
||||
6) modify the file $PGDATA/PG_VERSION from 5.0 to 5.1
|
||||
|
||||
7) start up a new 1.01 postmaster
|
||||
|
||||
5) Add the new built-in functions and operators of 1.01 to 1.0
|
||||
databases. This is done by running the new 1.01 server against
|
||||
your own 1.0 database and applying the queries attached and saving
|
||||
in the file 1.0_to_1.01.sql. This can be done easily through psql.
|
||||
If your 1.0 database is name "testdb":
|
||||
|
||||
% psql testdb -f 1.0_to_1.01.sql
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
-- add builtin functions that are new to 1.01
|
||||
|
||||
create function int4eqoid (int4, oid) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function oideqint4 (oid, int4) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char2icregexeq (char2, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char2icregexne (char2, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char4icregexeq (char4, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char4icregexne (char4, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char8icregexeq (char8, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char8icregexne (char8, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char16icregexeq (char16, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function char16icregexne (char16, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function texticregexeq (text, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
create function texticregexne (text, text) returns bool as 'foo'
|
||||
language 'internal';
|
||||
|
||||
-- add builtin functions that are new to 1.01
|
||||
|
||||
create operator = (leftarg = int4, rightarg = oid, procedure = int4eqoid);
|
||||
create operator = (leftarg = oid, rightarg = int4, procedure = oideqint4);
|
||||
create operator ~* (leftarg = char2, rightarg = text, procedure = char2icregexeq);
|
||||
create operator !~* (leftarg = char2, rightarg = text, procedure = char2icregexne);
|
||||
create operator ~* (leftarg = char4, rightarg = text, procedure = char4icregexeq);
|
||||
create operator !~* (leftarg = char4, rightarg = text, procedure = char4icregexne);
|
||||
create operator ~* (leftarg = char8, rightarg = text, procedure = char8icregexeq);
|
||||
create operator !~* (leftarg = char8, rightarg = text, procedure = char8icregexne);
|
||||
create operator ~* (leftarg = char16, rightarg = text, procedure = char16icregexeq);
|
||||
create operator !~* (leftarg = char16, rightarg = text, procedure = char16icregexne);
|
||||
create operator ~* (leftarg = text, rightarg = text, procedure = texticregexeq);
|
||||
create operator !~* (leftarg = text, rightarg = text, procedure = texticregexne);
|
||||
|
||||
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
This migration requires a complete dump of the 6.0 database and a
|
||||
restore of the database in 6.1.
|
||||
|
||||
Those migrating from earlier 1.* releases should first upgrade to 1.09
|
||||
because the COPY output format was improved from the 1.02 release.
|
||||
@ -1,6 +0,0 @@
|
||||
This is a minor bug-fix release. A dump/reload is not required from v6.2,
|
||||
but is required from any release prior to v6.2.
|
||||
|
||||
In upgrading from v6.2, if you choose to dump/reload you will find that
|
||||
avg(money) is now calculated correctly. All other bug fixes take effect
|
||||
upon updating the executables.
|
||||
@ -1,8 +0,0 @@
|
||||
This migration requires a complete dump of the 6.1 database and a
|
||||
restore of the database in 6.2.
|
||||
|
||||
Note that the pg_dump and pg_dumpall utility from 6.2 should be used
|
||||
to dump the 6.1 database.
|
||||
|
||||
Those migrating from earlier 1.* releases should first upgrade to 1.09
|
||||
because the COPY output format was improved from the 1.02 release.
|
||||
@ -1,65 +0,0 @@
|
||||
This migration requires a complete dump of the 6.2 or 6.2.1 database and a
|
||||
restore of the database in 6.3.
|
||||
|
||||
There are some general 6.3 issues that I want to mention. These are
|
||||
only the big items that can not be described in one sentence. A review
|
||||
of the HISTORY files is still needed.
|
||||
|
||||
First, we now have subselects. Now that we have them, I would like to
|
||||
mention that without subselects, SQL is a very limited language.
|
||||
Subselects are a major feature, and you should review your code for
|
||||
places where subselects provide a better solution for your queries. I
|
||||
think you will find that there are more uses for subselects than you may
|
||||
think. Vadim has put us on the big SQL map with subselects, and fully
|
||||
functional ones too. The only thing you can't do with subselects is to
|
||||
use them in the target list.
|
||||
|
||||
Second, 6.3 uses unix domain sockets rather than TCP/IP by default. To
|
||||
enable connections from other machines, you have to use the new
|
||||
postmaster -i option, and of course edit pg_hba.conf. Also, for this
|
||||
reason, the format of pg_hba.conf has changed.
|
||||
|
||||
Third, char() fields will now allow faster access than varchar() or
|
||||
text. Specifically, the text and varchar() have a penalty for access to
|
||||
any columns after the first column of this type. char() used to also
|
||||
have this access penalty, but it no longer does. This may suggest that
|
||||
you redesign some of your tables, especially if you have short character
|
||||
columns that you have defined as varchar() or text. This and other
|
||||
changes make 6.3 even faster than earlier releases.
|
||||
|
||||
We now have passwords definable independent of any Unix file. There are
|
||||
new SQL USER commands. See the pg_hba.conf manual page for more
|
||||
information. There is a new table, pg_shadow, which is used to store
|
||||
user information and user passwords, and it by default only SELECT-able
|
||||
by the postgres super-user. pg_user is now a view of pg_shadow, and is
|
||||
SELECT-able by PUBLIC. You should keep using pg_user in your
|
||||
application without changes.
|
||||
|
||||
User-created tables now no longer have SELECT permission to PUBLIC by
|
||||
default. This was done because the ANSI standard requires it. You can
|
||||
of course GRANT any permissions you want after the table is created.
|
||||
System tables continue to be SELECT-able by PUBLIC.
|
||||
|
||||
We also have real deadlock detection code. No more sixty-second
|
||||
timeouts. And the new locking code implements a FIFO better, so there
|
||||
should be less resource starvation during heavy use.
|
||||
|
||||
Many complaints have been made about inadequate documenation in previous
|
||||
releases. Thomas has put much effort into many new manuals for this
|
||||
release. Check out the /doc directory.
|
||||
|
||||
For performance reasons, time travel is gone, but can be implemented
|
||||
using triggers (see pgsql/contrib/spi/README). Please check out the new
|
||||
\d command for types, operators, etc. Also, views have their own
|
||||
permissions now, not based on the underlying tables, so permissions on
|
||||
them have to be set separately. Check /pgsql/interfaces for some new
|
||||
ways to talk to PostgreSQL.
|
||||
|
||||
This is the first release that really required an explaination for
|
||||
existing users. In many ways, this was necessary because the new
|
||||
release removes many limitations, and the work-arounds people were using
|
||||
are no longer needed.
|
||||
|
||||
Long live PostgreSQL.
|
||||
|
||||
-- Bruce Momjian
|
||||
@ -1,15 +0,0 @@
|
||||
This is a minor bug-fix release. A dump/reload is not required from v6.2,
|
||||
but is required from any release prior to v6.2.
|
||||
|
||||
In upgrading from v6.2, if you choose to dump/reload you will find that
|
||||
avg(money) is now calculated correctly. All other bug fixes take effect
|
||||
upon updating the executables.
|
||||
|
||||
Another way to avoid dump/reload is to use the following SQL command
|
||||
from psql to update the existing system table:
|
||||
|
||||
update pg_aggregate set aggfinalfn = 'cash_div_flt8'
|
||||
where aggname = 'avg' and aggbasetype = 790;
|
||||
|
||||
This will need to be done to every existing database, including template1.
|
||||
|
||||
@ -1,4 +0,0 @@
|
||||
A dump/restore is NOT required for those running 6.3. A
|
||||
'make distclean', 'make', and 'make install' is all that is required.
|
||||
This last step should be performed while the postmaster is not running.
|
||||
You should re-link any custom applications that use PostgreSQL libraries.
|
||||
Loading…
Reference in New Issue
Block a user