PPOOSSTTGGRREESS VVeerrssiioonn 33..11
                       RReelleeaassee NNootteess

                          9911//1122//0022



11..  IInnttrroodduuccttiioonn
   These  are the release notes for version 3.1 of the POST-
 GRES database system from UC Berkeley.  The database system
 and its installation procedure are covered in detail in the
 setup document for this release, which can be found in  the
 file  ~postgres/doc/postgres-setup.me.  Here, we cover only
 the most important differences from release 3.0 and earlier
 versions of the system.

22..  AAiimm
   The  main focus of this release was an attempt to fix the
 reported bugs in version 3.0.  Because of this very  little
 new functionality has been added to the system.  One of the
 primary development efforts was in the push towards  "ansi-
 fication"  of  the  source code.  This manifested itself in
 the creation and clean up of POSTGRES function  prototypes.
 All  DEC  platforms  now compile with -DPROTOTYPES defined.
 In the future we intend to  continue  this  effort  in  the
 hopes of substantially cleaning up the code.

33..  CChhaannggeess ttoo PPOOSSTTQQUUEELL
   The  POSTQUEL  query  language  has  been  modified  only
 slightly.

  33..11..  ddeeffiinnee ffuunnccttiioonn
     The syntax for defining function has been changed in  a
   move  to  make  functions  more orthogonal.  Where before
   there were two separate queries, one for c functions  and
   one  for  postquel,  now  there is a single command.  The
   language in which the function is  defined  must  now  be
   specified as a parameter.  The syntax is as follows:

   define function <function-name>
   (language = <lang>, returntype = <typename>
       [, arch_pct = <percentage | pre-defined>]
       [, disk_pct = <percentage | pre-defined>]
       [, byte_pct = <percentage | pre-defined>]
       [, perbyte_cpu = <int | pre-defined>]
       [, percall_cpu = <int | pre-defined>]
       [, iscachable])
    arg is (<type-1> [ , <type-n>])
    as <filename or code in language as appropriate>

   Both  the  demo  and  the video demo give examples.  Cur-
   rently the only languages supported are CC and PPOOSSTTQQUUEELL..











PPOOSSTTGGRREESS VV33..00 RReelleeaassee NNootteess   22                     9911//1122//0022


44..  GGeenneerraall SSyysstteemm CChhaannggeess

  44..11..  AAggggrreeggaatteess
     Aggregate (or column-valued functions) support  is  now
   much  more general.  The type of values aggregated can be
   of completely arbitrary type.  Due to this generalization
   the  initial  values for aggregates are now stored in the
   pg_aggregate system catalog as type text.  This  requires
   a  slight change of syntax in aggregate definitions.  The
   initial values must now be enclosed in double quotes (See
   the Reference Manual).  There are also many more built-in
   aggregate functions. The Reference Manual  describes  how
   to  define  and use aggregates in detail.  The demo gives
   some simple examples.
  44..22..  FFuunnccttiioonnaall IInnddiicceess
     POSTGRES now supports secondary indices defined on  the
   resultant values of functions.  The syntax for functional
   indices is similar to that of standard secondary indices.
   The  difference  is  where  you would normally specify an
   attribute, you now give a function call:

   define index foo on bar using btree  (f([att1]  [,  att2]
   ...) int4_ops)

   Only  attributes defined in the specified relation can be
   used  in  the  function.   Functional  index  support  is
   restricted  to cachable functions only.  Defining a func-
   tional index on a non-cachable function  (e.g.  one  that
   depends  on  current database state) can result in incor-
   rect behavior.
  44..33..  MMaannuuaall rreeoorrggaanniizzaattiioonn
     The POSTGRES tutorials have been merged into  a  single
   user manual and largely rewritten.  This manual is recom-
   mended reading for new users.   The  old  manual  is  now
   called  the  Reference,  and  is  still  included  in its
   entirety.  The new manual is in
        ~postgres/doc/manual.me
55..  KKnnoowwnn BBuuggss
   There are a few known bugs that we did  not  fix  in  the
 current release.

  55..11..  IInnddiicceess aanndd tthhee IInnssttaannccee LLeevveell RRuullee SSyysstteemm
     The  Instance  Level  Rule  System  essentially ignores
   indices, so if you are defining  a  rule  on  an  indexed
   attribute,  you should use the Query Rewrite rule system.

  55..22..  RReettrriieevvee IInnttoo aanndd ffaaiilleedd bbaacckkeennddss
     If a backend fails while in the course of  executing  a
   Retrieve  Into query, a spurious file, with the same name
   as the target class of the Retrieve Into, will be left in
   the  database directory.  This file can be safely deleted
   by the database DBA.











PPOOSSTTGGRREESS VV33..00 RReelleeaassee NNootteess   33                     9911//1122//0022


  55..33..  LLaarrggee OObbjjeeccttss aanndd ffaaiilleedd bbaacckkeennddss
     If a backend  fails  while  it  is  manipulating  large
   objects,  spurious large object files will be left in the
   database directory.  Also, there is no mechanism for get-
   ting rid of large objects which are returned by functions
   but not stored in instances.

  55..44..  PPoossttggrreess UUsseerr IIdd''ss aanndd UUnniixx UUIIDD''ss
     The userid of a Postgres registered user mmuusstt match the
   user's  UNIX user id.  In the release, the user id of the
   Postgres user in /etc/passwd is presumed to be 6.  If  it
   is  not,  Postgres  will  not  run properly.  This can be
   overcome for those who do not wish to renumber the userid
   field in their password files by editing the file
   ssrrcc//lliibb//HH//ccaattaalloogg//ppgg__uusseerr..hh
   and  changing  the "usesysid" field for the Postgres user
   to the one used in /etc/passwd at your site  bbeeffoorree  com-
   piling  and  installing  Postgres.  The line in this file
   you wish to change looks like this:

   DATA(insert OID =    6 ( postgres 6 t t t t ));

   If you change the two 6's above to the value used for the
   "postgres"  user  in  your /etc/passwd file, this problem
   can be avoided.

  55..55..  KKnnoowwnn bbuuggss lliisstt
     A list of known bugs and suggested work-arounds can  be
   anonymously  ftp'ed.   This  list  is  kept  in  the file
   ~ftp/pub/postgres-v3r1.bugs.  We will make every  attempt
   to keep this list up to date.
66..  MMaacchhiinnee--ddeeppeennddeenntt PPrroobblleemmss
  66..11..  SSppaarrccssttaattiioonnss rruunnnniinngg SSuunnOOSS 44..00..33
     Postgres  has been known to crash SunOS 4.0.3 on Sparc-
   stations, due to  a  SunOS  bug  in  shared  memory.   It
   appears  to  work on SunOS 4.1 and higher, so any reports
   of crashes on SunOS 4.1 and higher are appreciated.

  66..22..  TThhee vvaaccuuuumm cclleeaanneerr oonn SSppaarrccssttaattiioonnss
     The vacuum cleaner has been reported in some  cases  to
   crash  the  backend on Sparcstations.  We have reproduced
   this problem, but unfortunately were unable  to  fix  the
   error prior to this release going out.