+++ /dev/null
-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);
-
-
-
-
-
+++ /dev/null
-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.
+++ /dev/null
-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);
-
-
-
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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.
+++ /dev/null
-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
+++ /dev/null
-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.
-
+++ /dev/null
-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.
OSDN Git Service
