Skip to content

P
Postgres FD Implementation
Commit 10aaff0a authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

Information moved to doc/src/sgml/release.sgml.

parent 596731dc
Show whitespace changes
Inline Side-by-side
Showing with 0 additions and 275 deletions
migration/1.02_to_1.02.1 deleted 100644 → 0
View file @ 596731dc
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);
migration/1.09_to_6.0 deleted 100644 → 0
View file @ 596731dc
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.
migration/1.0_to_1.01 deleted 100644 → 0
View file @ 596731dc
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);
migration/6.0_to_6.1 deleted 100644 → 0
View file @ 596731dc
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.
migration/6.1_to_6.1.1 deleted 100644 → 0
View file @ 596731dc
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.
migration/6.1_to_6.2 deleted 100644 → 0
View file @ 596731dc
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.
migration/6.2.1_to_6.3 deleted 100644 → 0
View file @ 596731dc
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
migration/6.2_to_6.2.1 deleted 100644 → 0
View file @ 596731dc
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.
migration/6.3.1_to_6.3.2 deleted 100644 → 0
View file @ 596731dc
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.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment