Thread

1. Upgrades for 6.4.1

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-18T05:33:43Z

   I have made the needed changes for 6.4.1.
   
   Would people please review the attached TODO list, and tell me what TODO
   items can be removed, and if the attached 6.4.1 changes are correct.
   
   I suspect a few of the TODO items I added after 6.4 was release have
   been fixed, but am not sure.
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026  
   

2. Re: [HACKERS] Upgrades for 6.4.1

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-12-18T07:08:32Z

   > * Two and three dimmensional arrays display improperly, missing {}
   
   My simple test case shows as many brackets as I expect. Can someone
   remember what this was about? Or at least take the extra "m" out of
   "dimensional"? :)
   
   > * SELECT * FROM table WHERE int4_column = '1' fails
   
   postgres=> select * from x where i = '1';
   i
   -
   1
   (1 row)
   
   Works now, no? The new type coersion stuff...
   
   > * default char() value not to full length crashes server on some OS's
   
   postgres=> create table x (c char(10) default 'abc');
   CREATE
   postgres=> insert into x default values;
   INSERT 901452 1
   postgres=> select * from x;
   c
   ---
   abc
   (1 row)
   
   I distinctly recall fixing this, or watching someone else do it...
   
   > * SELECT DISTINCT i FROM dtest ORDER BY j generates strange output
   
   In my simple test case, it orders by j, then only shows i. Is that
   strange? What did it used to do? The current behavior makes sense, if it
   should be allowed at all...
   
   > * views with spaces in view name fail when referenced
   
   Still a problem.
   
   > * plpgsql does not handle quoted mixed-case identifiers
   
   Ditto.
   
   > * do not allow bpchar column creation without length
   
   ? char is now the same as char(1), which should solve this, if that's
   what it means...
   
   > ENHANCEMENTS
   > ------------
   > * Add full ANSI SQL capabilities
   >         * add OUTER joins, left and right (Thomas)
   >         * add INTERSECTS, SUBTRACTS(Stephan)
   >         * add temporary tables
   >         * add sql3 recursive unions
   >         * add the concept of dataspaces
   >         * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
   
   We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are
   brain-damaged though)
   
   >         * add CONSTRAINT
   
   Already here, from Vadim.
   
   > * Full set of text operations and functions
   >         * word searches, concat,max() on text, char
   
   Not sure about "word searches", others are done. v6.4.1 will require a
   dump/reload to find min/max for string types. In fact, can someone test
   to make sure it is ok that I added these to the pg_aggregate system
   table? And a couple of support functions to pg_proc? Since they weren't
   available before, and since everything else still works, I thought it
   might be OK to include them. But I can rip them out of the system tables
   if that would be best for v6.4.1.
   
   > * Add word index for text fields, maybe with trigrams, i.e.:
   >   * ' (cat | dog) & ! fox ' meaning text has cat aor dog, but not fox
   
   How is this different from the "word searches" above?
   
   > * Allow INSERT INTO ... SELECT to convert column types
   
   Probably does. The new type coersion stuff :)
   
   > * remove non-standard types from the system, and make them loadable
   
   This made the ToDo list, but I'm not sure we want to do it. Native types
   still have a few advantages over loadable types, and our types are one
   of our strongest features...
   
   > * Allow variable casts with BETWEEN 'today'::asbtime AND 'today'::abstime
   
   postgres=> select 'yes' where 'now'::datetime 
      between 'today'::datetime and 'tomorrow'::datetime;
   ?column?
   --------
   yes
   (1 row)
   
   What did this item mean??
   
   > * Change all references of Postgres to PostgreSQL, including binary 
   >     names
   
   I've standardized all Postgres docs to use "Postgres" within the body,
   and "PostgreSQL" for titles and in the introduction.
   
   > * Change LOCK tablename to LOCK TABLE tablename(?)
   
   Both syntaxes are now legal and accepted.
   
   > * Generate error on CREATE OPERATOR of ~~, ~ and and ~*
   
   ? Because gram.y mucks around with them?
   
   > * Allow constraint NULL just as we honor NOT NULL
   
   Fundamental yacc problem with this as I recall. Gives rise to
   shift/reduce problems since it is ambiguous with other uses of "NULL" in
   the same area.
   
   > * do autocommit so always in a transaction block
   
   This is already the case, right? Every statement has an implicit
   begin/end around it, unless it is within an explicit begin/end. Or does
   this mean something else?
   
   > * no min/max for oid type
   
   Fixed. New type coersion stuff.
   
   > * remove un-needed conversion functions
   
   ? An explicit conversion function is always/usually faster than one
   which requires multiple steps.
   
   > DOCUMENTATION
   > -------------
   > * Add keyword list to documentation, already in /tools
   
   Done. In the User's Guide chapter on "Syntax".
   
   > CHANGES IN THE 6.4.1 RELEASE
   > ----------------------------
   > Add pg_dump -N flag to force double quotes around identifiers.  This is
   >         the default
   
   (Thomas) in case you have room :)
   
   > Fix test for table existance to allow mixed-case and whitespace in
   >         the table name
   
   Ditto. At least when combined with Billy's fixes to make a complete set.
   
   > Fix for creating tables with constraints when table name is mixed-case(Billy)
   > Fixes for mixed-case table names(Billy)
   
   These all sure sound similar...
   
   > contrib/linux/postgres.init.csh/sh fix
   
   (Thomas)
   
   > Change exp() behavior to generate error on underflow
   
   (Tom), right?
   
   > Timezone fixes(Tom)
   
   ? Not sure we see an improvement yet, if this is the date->datetime
   conversion problem reported by Oleg.
   
   > Use implicit type coersion for matching DEFAULT values
   
   (Thomas) but wasn't this mentioned above somewhere? Maybe not...
   
                       - Tom
   
   

3. Re: [HACKERS] Upgrades for 6.4.1

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-18T07:30:42Z

   > > * Two and three dimmensional arrays display improperly, missing {}
   > 
   > My simple test case shows as many brackets as I expect. Can someone
   > remember what this was about? Or at least take the extra "m" out of
   > "dimensional"? :)
   
   Bug report attached.  It is an old one.
   
   > 
   > > * SELECT * FROM table WHERE int4_column = '1' fails
   > 
   > postgres=> select * from x where i = '1';
   > i
   > -
   > 1
   > (1 row)
   > 
   > Works now, no? The new type coersion stuff...
   
   Item removed.
   
   > 
   > > * default char() value not to full length crashes server on some OS's
   > 
   > postgres=> create table x (c char(10) default 'abc');
   > CREATE
   > postgres=> insert into x default values;
   > INSERT 901452 1
   > postgres=> select * from x;
   > c
   > ---
   > abc
   > (1 row)
   > 
   > I distinctly recall fixing this, or watching someone else do it...
   
   Removed.
   
   > 
   > > * SELECT DISTINCT i FROM dtest ORDER BY j generates strange output
   > 
   > In my simple test case, it orders by j, then only shows i. Is that
   > strange? What did it used to do? The current behavior makes sense, if it
   > should be allowed at all...
   
   Removed.
   
   > 
   > > * views with spaces in view name fail when referenced
   > 
   > Still a problem.
   
   Ok.
   
   > 
   > > * plpgsql does not handle quoted mixed-case identifiers
   > 
   > Ditto.
   
   Ok.
   
   > 
   > > * do not allow bpchar column creation without length
   > 
   > ? char is now the same as char(1), which should solve this, if that's
   > what it means...
   
   Try:
   	create table x(y bpchar);
   
   and try pg_dumping it.
   
   > 
   > > ENHANCEMENTS
   > > ------------
   > > * Add full ANSI SQL capabilities
   > >         * add OUTER joins, left and right (Thomas)
   > >         * add INTERSECTS, SUBTRACTS(Stephan)
   > >         * add temporary tables
   > >         * add sql3 recursive unions
   > >         * add the concept of dataspaces
   > >         * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
   > 
   > We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are
   > brain-damaged though)
   
   Removed.
   
   > 
   > >         * add CONSTRAINT
   > 
   > Already here, from Vadim.
   
   Removed.
   
   > 
   > > * Full set of text operations and functions
   > >         * word searches, concat,max() on text, char
   > 
   > Not sure about "word searches", others are done. v6.4.1 will require a
   > dump/reload to find min/max for string types. In fact, can someone test
   > to make sure it is ok that I added these to the pg_aggregate system
   > table? And a couple of support functions to pg_proc? Since they weren't
   > available before, and since everything else still works, I thought it
   > might be OK to include them. But I can rip them out of the system tables
   > if that would be best for v6.4.1.
   
   Removed.
   
   > 
   > > * Add word index for text fields, maybe with trigrams, i.e.:
   > >   * ' (cat | dog) & ! fox ' meaning text has cat aor dog, but not fox
   > 
   > How is this different from the "word searches" above?
   
   Removed.
   
   > 
   > > * Allow INSERT INTO ... SELECT to convert column types
   > 
   > Probably does. The new type coersion stuff :)
   
   Removed.
   
   > 
   > > * remove non-standard types from the system, and make them loadable
   > 
   > This made the ToDo list, but I'm not sure we want to do it. Native types
   > still have a few advantages over loadable types, and our types are one
   > of our strongest features...
   
   Removed.
   
   > 
   > > * Allow variable casts with BETWEEN 'today'::asbtime AND 'today'::abstime
   > 
   > postgres=> select 'yes' where 'now'::datetime 
   >    between 'today'::datetime and 'tomorrow'::datetime;
   > ?column?
   > --------
   > yes
   > (1 row)
   > 
   > What did this item mean??
   
   Some problem with OR gram.y processing.  Fixed, I guess.
   
   > 
   > > * Change all references of Postgres to PostgreSQL, including binary 
   > >     names
   > 
   > I've standardized all Postgres docs to use "Postgres" within the body,
   > and "PostgreSQL" for titles and in the introduction.
   
   Removed.
   
   > 
   > > * Change LOCK tablename to LOCK TABLE tablename(?)
   > 
   > Both syntaxes are now legal and accepted.
   
   Removed.
   
   > 
   > > * Generate error on CREATE OPERATOR of ~~, ~ and and ~*
   > 
   > ? Because gram.y mucks around with them?
   
   Ok.
   
   > 
   > > * Allow constraint NULL just as we honor NOT NULL
   > 
   > Fundamental yacc problem with this as I recall. Gives rise to
   > shift/reduce problems since it is ambiguous with other uses of "NULL" in
   > the same area.
   
   Ok.
   
   > 
   > > * do autocommit so always in a transaction block
   > 
   > This is already the case, right? Every statement has an implicit
   > begin/end around it, unless it is within an explicit begin/end. Or does
   > this mean something else?
   
   Not the same.  Withouth autocommit on, you start in a transaction, and
   have to issue a commit to commit the changes, and you are back in a new
   transaction.  Ingres SQL does this.
   
   > 
   > > * no min/max for oid type
   > 
   > Fixed. New type coersion stuff.
   
   Removed.
   
   > 
   > > * remove un-needed conversion functions
   > 
   > ? An explicit conversion function is always/usually faster than one
   > which requires multiple steps.
   
   Added word 'where appropriate'.  We just have tons of them. Would be
   nice to pair them down a little.
   
   > 
   > > DOCUMENTATION
   > > -------------
   > > * Add keyword list to documentation, already in /tools
   > 
   > Done. In the User's Guide chapter on "Syntax".
   
   Removed.
   
   > 
   > > CHANGES IN THE 6.4.1 RELEASE
   > > ----------------------------
   > > Add pg_dump -N flag to force double quotes around identifiers.  This is
   > >         the default
   > 
   > (Thomas) in case you have room :)
   
   
   Ok.
   
   > 
   > > Fix test for table existance to allow mixed-case and whitespace in
   > >         the table name
   > 
   > Ditto. At least when combined with Billy's fixes to make a complete set.
   
   Ok.  I loose the committers name in the script I wrote, and I am not
   sure who did it.  We also commit other's patches, so even knowing the
   committers name sometimes doesn't help.  I know my fixes, however. :-)
   
   > 
   > > Fix for creating tables with constraints when table name is mixed-case(Billy)
   > > Fixes for mixed-case table names(Billy)
   > 
   > These all sure sound similar...
   
   Removed.
   
   > 
   > > contrib/linux/postgres.init.csh/sh fix
   > 
   > (Thomas)
   
   Added
   
   > 
   > > Change exp() behavior to generate error on underflow
   > 
   > (Tom), right?
   OK.
   
   > 
   > > Timezone fixes(Tom)
   > 
   > ? Not sure we see an improvement yet, if this is the date->datetime
   > conversion problem reported by Oleg.
   
   We'll see.
   
   > 
   > > Use implicit type coersion for matching DEFAULT values
   > 
   > (Thomas) but wasn't this mentioned above somewhere? Maybe not...
   
   Not mentioned.  Updated RELEASE tree and web page with new TODO copy.
   
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   

4. Re: [HACKERS] Upgrades for 6.4.1

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-18T16:07:17Z

   > Bruce Momjian wrote:
   > > >
   > > > > ENHANCEMENTS
   > > > > ------------
   > > > > * Add full ANSI SQL capabilities
   > > > >         * add OUTER joins, left and right (Thomas)
   > > > >         * add INTERSECTS, SUBTRACTS(Stephan)
   > > > >         * add temporary tables
   > > > >         * add sql3 recursive unions
   > > > >         * add the concept of dataspaces
   > > > >         * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
   > > >
   > > > We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are
   > > > brain-damaged though)
   > > 
   > > Removed.
   > 
   > If it's brain-damaged should'nt it be justr Replaced instead of Removed 
   
   We just need to add better precision to the type.
   
   > 
   > > 
   > > >
   > > > >         * add CONSTRAINT
   > > >
   > > > Already here, from Vadim.
   > > Removed.
   > > 
   > 
   > AFAIK, CONSTRAINTS ar currently available only at table create time ?
   > 
   > So once you have (or have.nt) them, you must stay with it ;(
   > 
   > creating/dropping constraints should be made to work in ALTER TABLE as
   > well
   
   Already on list:
   
   	* ALTER TABLE ADD COLUMN does not honor DEFAULT, add CONSTRAINT
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

5. Re: [HACKERS] Upgrades for 6.4.1

   Hannu Krosing <hannu@trust.ee> — 1998-12-18T16:08:33Z

   Bruce Momjian wrote:
   > >
   > > > ENHANCEMENTS
   > > > ------------
   > > > * Add full ANSI SQL capabilities
   > > >         * add OUTER joins, left and right (Thomas)
   > > >         * add INTERSECTS, SUBTRACTS(Stephan)
   > > >         * add temporary tables
   > > >         * add sql3 recursive unions
   > > >         * add the concept of dataspaces
   > > >         * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
   > >
   > > We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are
   > > brain-damaged though)
   > 
   > Removed.
   
   If it's brain-damaged should'nt it be justr Replaced instead of Removed 
   
   > 
   > >
   > > >         * add CONSTRAINT
   > >
   > > Already here, from Vadim.
   > Removed.
   > 
   
   AFAIK, CONSTRAINTS ar currently available only at table create time ?
   
   So once you have (or have.nt) them, you must stay with it ;(
   
   creating/dropping constraints should be made to work in ALTER TABLE as
   well
   
   
   ------------------
   Hannu
   
   

6. Re: [HACKERS] Upgrades for 6.4.1

   Brook Milligan <brook@trillium.nmsu.edu> — 1998-12-18T17:40:28Z

      Would people please review the attached TODO list, and tell me what TODO
      items can be removed, and if the attached 6.4.1 changes are correct.
   
   It looks from your list like a couple of patches I sent in have not
   made it in for one reason or another, though I haven't checked the
   source yet but never saw any acknowledgement.
   
   Here are descriptions:
   
   - the first patch is just to preven listing the perl warning in the
     make output unless it is actually emitted by the make.  this may
     prevent new users from being confused by the warning in their output
     when in fact is is just echoing part of a command not actually run.
   
   - the second patch (to 2 files) just enables building/installing
     pgaccess if TCL and TK are available.  a Makefile is created to do
     this, but you may wish to change the heading information in it since
     I just copied another Makefile to use as a template.
   
   I hope these make it into 6.4.1.
   
   Cheers,
   Brook
   
   ===========================================================================
   $NetBSD$
   
   --- interfaces/Makefile.orig	Tue Oct 27 14:27:36 1998
   +++ interfaces/Makefile	Fri Nov  6 23:12:08 1998
   @@ -48,11 +48,11 @@
    perl5/Makefile: perl5/Makefile.PL
    	cd perl5 && perl Makefile.PL
    
   -install-perl5:
   +install-perl5: perl5/Makefile
    	$(MAKE) -C perl5 clean
    	cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PL
    	$(MAKE) -C perl5 all
   -	if [ -w `sed -n -e 's/^ *SITELIBEXP *= *//p' perl5/Makefile` ]; then \
   +	@if [ -w `sed -n -e 's/^ *SITELIBEXP *= *//p' perl5/Makefile` ]; then \
    		$(MAKE) $(MFLAGS) -C perl5 install; \
    		rm -f perl5/Makefile; \
    	else \
   ===========================================================================
   $NetBSD$
   
   --- bin/Makefile.orig	Sat Jul 25 22:31:08 1998
   +++ bin/Makefile	Mon Nov  9 08:35:00 1998
   @@ -25,6 +25,9 @@
    # TCL/TK programs
    #
    ifeq ($(USE_TCL), true)
   +ifeq ($(USE_TK), true)
   +	DIRS += pgaccess
   +endif
    	DIRS += pgtclsh
    endif
    
   $NetBSD$
   
   --- bin/pgaccess/Makefile.orig	Fri Nov  6 23:43:38 1998
   +++ bin/pgaccess/Makefile	Fri Nov  6 23:46:26 1998
   @@ -0,0 +1,21 @@
   +#-------------------------------------------------------------------------
   +#
   +# Makefile
   +#    Makefile for pgaccess
   +#
   +# Copyright (c) 1994, Regents of the University of California
   +#
   +# IDENTIFICATION
   +#    $Header: /usr/local/cvsroot/pgsql/src/interfaces/libpgtcl/Makefile.in,v 1.33 1998/10/19 00:00:41 tgl Exp $
   +#
   +#-------------------------------------------------------------------------
   +
   +SRCDIR= ../..
   +include $(SRCDIR)/Makefile.global
   +
   +.PHONY: all clean
   +all clean: 
   +
   +.PHONY: install
   +install: pgaccess.tcl
   +	$(INSTALL) $(INSTL_EXE_OPTS) pgaccess.tcl $(BINDIR)/pgaccess
   ===========================================================================
   
   

7. Re: [HACKERS] Upgrades for 6.4.1

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-18T17:55:00Z

   Applied.
   
   Both of them somehow were not applied.  Not sure how I missed them.
   
   Sorry and thanks.
   
   >    Would people please review the attached TODO list, and tell me what TODO
   >    items can be removed, and if the attached 6.4.1 changes are correct.
   > 
   > It looks from your list like a couple of patches I sent in have not
   > made it in for one reason or another, though I haven't checked the
   > source yet but never saw any acknowledgement.
   > 
   > Here are descriptions:
   > 
   > - the first patch is just to preven listing the perl warning in the
   >   make output unless it is actually emitted by the make.  this may
   >   prevent new users from being confused by the warning in their output
   >   when in fact is is just echoing part of a command not actually run.
   > 
   > - the second patch (to 2 files) just enables building/installing
   >   pgaccess if TCL and TK are available.  a Makefile is created to do
   >   this, but you may wish to change the heading information in it since
   >   I just copied another Makefile to use as a template.
   > 
   > I hope these make it into 6.4.1.
   
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

8. Re: [HACKERS] Upgrades for 6.4.1

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-18T17:59:42Z

   Constantin, should you add this Makefile to the pgaccess distribution?
   
   I am not sure.  It is in the PostgreSQL source tree.
   
   > 
   > --- bin/pgaccess/Makefile.orig	Fri Nov  6 23:43:38 1998
   > +++ bin/pgaccess/Makefile	Fri Nov  6 23:46:26 1998
   > @@ -0,0 +1,21 @@
   > +#-------------------------------------------------------------------------
   > +#
   > +# Makefile
   > +#    Makefile for pgaccess
   > +#
   > +# Copyright (c) 1994, Regents of the University of California
   > +#
   > +# IDENTIFICATION
   > +#    $Header: /usr/local/cvsroot/pgsql/src/interfaces/libpgtcl/Makefile.in,v 1.33 1998/10/19 00:00:41 tgl Exp $
   > +#
   > +#-------------------------------------------------------------------------
   > +
   > +SRCDIR= ../..
   > +include $(SRCDIR)/Makefile.global
   > +
   > +.PHONY: all clean
   > +all clean: 
   > +
   > +.PHONY: install
   > +install: pgaccess.tcl
   > +	$(INSTALL) $(INSTL_EXE_OPTS) pgaccess.tcl $(BINDIR)/pgaccess
   > ===========================================================================
   > 
   > 
   
   
   -- 
     Bruce Momjian                        |  http://www.op.net/~candle
     maillist@candle.pha.pa.us            |  (610) 853-3000
     +  If your life is a hard drive,     |  830 Blythe Avenue
     +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
   
   

9. Re: [HACKERS] Upgrades for 6.4.1

   Constantin Teodorescu <teo@flex.ro> — 1998-12-18T18:40:04Z

   Bruce Momjian wrote:
   > 
   > Constantin, should you add this Makefile to the pgaccess distribution?
   > 
   > I am not sure.  It is in the PostgreSQL source tree.
   
   Yes. I will install pgaccess.tcl as executable pgaccess and it seems ok.
   I will add it to my usual tar.gz
   
   -- 
   Constantin Teodorescu
   FLEX Consulting Braila, ROMANIA
   
   

10. Re: [HACKERS] Upgrades for 6.4.1

    Jan Wieck <jwieck@debis.com> — 1998-12-18T18:50:45Z

    > > > >         * add DECIMAL, NUMERIC, DOUBLE PRECISION, BIT, BIT VARYING
    > > >
    > > > We've got DOUBLE PRECISION, DECIMAL, and NUMERIC (the latter two are
    > > > brain-damaged though)
    > >
    > > Removed.
    >
    > If it's brain-damaged should'nt it be justr Replaced instead of Removed
    
        NUMERIC  and  DECIMAL  are identical, but should be different
        from INTEGER (what they are in Postgres for now).
    
        All databases share the definition
    
            NUMERIC [(precision [, scale] )]
    
        And NUMERIC (NUMBER in Oracle :-) is defined  as  a  datatype
        that  uses exact representation of arbitrary precise numbers.
        But everyone has different legal value  ranges  and  defaults
        for  it.   The  ranges  for  the  precision  (number of total
        digits) varies from 38 (Oracle) to over 1000 sometimes.
    
        I'll hack around a little on it to see  what's  possible  for
        us.
    
    
    Jan
    
    --
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #
    
    
    
    

11. Help with Documentation?

    Clark C. Evans <clark.evans@manhattanproject.com> — 1998-12-19T00:41:41Z

    Since I need to learn PosgreSQL, I'd like to help 
    with documentation.  It's the best way to learn... 
    
    To start, can't seem to get the doc/src/sgml 
    to compile.  What version of jade do I need 
    and what version of the DocBook DTD. Is there 
    a link where I can download?
    
    After I am able to re-build the documentation,
    could I get access to the CVS server so I can
    update documentation?
    
    My long term goal is to put documentation
    in the database itself, and to provide tools
    to import/export SGML documents to PostgreSQL
    and to crate a "document server" that
    is accessable from the web.
    
    Best,
    
    Clark
    
    

12. Re: [HACKERS] Upgrades for 6.4.1

    Jan Wieck <jwieck@debis.com> — 1998-12-19T01:01:16Z

    I wrote:
    
    >     NUMERIC  and  DECIMAL  are identical, but should be different
    >     from INTEGER (what they are in Postgres for now).
    >
    >     All databases share the definition
    >
    >         NUMERIC [(precision [, scale] )]
    >
    > [...]
    >
    >     I'll hack around a little on it to see  what's  possible  for
    >     us.
    
        Easy - and the type coersion stuff helps alot!
    
        Up  to  now  (1.5  hours  hacking) I have a NUMERIC type that
        handles  '+'  completely,  including  overflow   checks   and
        rounding.
    
        Subtract  will be trivial, because the core funcitons already
        exist for the add. Multiply and divide will  take  some  time
        and then there are all the comparision operators, an operator
        class   and   all   the   type   conversion   (int<->numeric,
        float<->numeric ...).
    
        Another  tricky  part I expect when telling the parser that a
        literal NUMERIC must not be enclosed into single quotes.
    
        The only ugly thing is, that I needed to  put  the  precision
        AND  the  scale together into atttypmod (I limited both to 99
        for now and put them as prec<<8 |  scale  into).  So  pg_dump
        will need attention later.
    
    
    Jan
    
    --
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #
    
    
    
    

13. Re: [HACKERS] Upgrades for 6.4.1

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-12-19T01:39:10Z

    >     The only ugly thing is, that I needed to  put  the  precision
    >     AND  the  scale together into atttypmod (I limited both to 99
    >     for now and put them as prec<<8 |  scale  into).  So  pg_dump
    >     will need attention later.
    
    Atttypmod was expanded to 32 bits for exactly that use.  I recommend
    16-bits for each option.
    
    -- 
      Bruce Momjian                        |  http://www.op.net/~candle
      maillist@candle.pha.pa.us            |  (610) 853-3000
      +  If your life is a hard drive,     |  830 Blythe Avenue
      +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
    
    

14. Re: [HACKERS] Help with Documentation?

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-12-19T02:52:07Z

    > Since I need to learn PosgreSQL, I'd like to help
    > with documentation.
    
    Great. Welcome.
    
    > To start, can't seem to get the doc/src/sgml
    > to compile.  What version of jade do I need
    > and what version of the DocBook DTD. Is there
    > a link where I can download?
    
    Look in Appendix A of the "integrated" postgres docs (postgres.html). It
    describes two methods of installation; from sources and from RPM (for
    linux). A few days ago we re-discovered how to install and run on
    FreeBSD using available "ports". Linux and FreeBSD are easy; from
    sources is more difficult. A detailed description for FreeBSD is in the
    works, but the info can be posted now I would think if that is your
    platform.
    
    I'm planning on implementing "automatic builds" on the current docs tree
    on postgresql.org so that fresh working docs are available routinely.
    All the pieces are in place now, just need to put the framework in
    place.
    
    As an aside, it is possible to contribute docs without having the
    ability to build the output. For the Postgres project, it doesn't matter
    much, but imho the jade/docbook toolset is so powerful and useful that
    it would be a good opportunity for you to learn a tool for other
    projects too.
    
    > After I am able to re-build the documentation,
    > could I get access to the CVS server so I can
    > update documentation?
    
    At the moment, a relatively limited number of contributors have direct
    *write* access to the CVS server. Typically, one gets cvs access after
    hammering the current committers hard enough with patches that they get
    tired of handling them. Everyone has CVSup and anon-CVS access to read
    the server.
    
    As the de facto current docs coordinator, I'll make sure contributions
    are used, and would welcome any suggestions (especially backed with
    work! :) on document structure and style.
    
    btw, no document contributions or updates have ever been rejected, lost,
    or unused.
    
    > My long term goal is to put documentation
    > in the database itself, and to provide tools
    > to import/export SGML documents to PostgreSQL
    > and to crate a "document server" that
    > is accessable from the web.
    
    Sounds like a neat project.
    
                        - Tom
    
    

15. Re: [HACKERS] Upgrades for 6.4.1

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-12-19T02:58:32Z

    >     Easy - and the type coersion stuff helps alot!
    >     Up  to  now  (1.5  hours  hacking) I have a NUMERIC type that
    >     handles  '+'  completely,  including  overflow   checks   and
    >     rounding.
    
    Neat. I was poking around waiting on a freeware extended-precision
    numerical package, but hadn't found anything with a BSD-style license.
    
    >     Another  tricky  part I expect when telling the parser that a
    >     literal NUMERIC must not be enclosed into single quotes.
    
    This is probably the worst part, since you would hate to take the hit
    representing everything as extended precision even if the actual range
    is int4/float8. Perhaps we can read as those, but if we get a failure
    then escalate to your extended precision type(s). The automatic type
    conversion stuff should convert later if necessary, so it might be
    transparent and relatively fast.
    
    >     The only ugly thing is, that I needed to  put  the  precision
    >     AND  the  scale together into atttypmod (I limited both to 99
    >     for now and put them as prec<<8 |  scale  into).  So  pg_dump
    >     will need attention later.
    
    As Bruce points out, that was anticipated (but I agree it's ugly). Shift
    over 16 bits if you want...
    
    Congrats!
    
                            - Tom
    
    

16. Re: [HACKERS] Upgrades for 6.4.1

    Oleg Bartunov <oleg@sai.msu.su> — 1998-12-19T10:10:11Z

    On Sat, 19 Dec 1998, Thomas G. Lockhart wrote:
    
    > Date: Sat, 19 Dec 1998 02:58:32 +0000
    > From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
    > To: Jan Wieck <jwieck@debis.com>
    > Cc: hannu@trust.ee, maillist@candle.pha.pa.us, hackers@postgreSQL.org
    > Subject: Re: [HACKERS] Upgrades for 6.4.1
    > 
    > >     Easy - and the type coersion stuff helps alot!
    > >     Up  to  now  (1.5  hours  hacking) I have a NUMERIC type that
    > >     handles  '+'  completely,  including  overflow   checks   and
    > >     rounding.
    > 
    > Neat. I was poking around waiting on a freeware extended-precision
    > numerical package, but hadn't found anything with a BSD-style license.
    
    Did you try search SAL ( Sci. Application for Linux) ?
    I just did search for 'precision' and found abot 12 items. Don't know
    about license bit some of them like
    <a href="http://www.hut.fi/~mtommila/apfloat/">apfloat - A C++ High Performance 
    Arbitrary Precision Arithmetic Package</a> are freeware.
    >From web page:
    Apfloat is a high performance arbitrary precision package. That means you can do calculations involving
    millions of digits with it. It uses Number Theoretic Transforms . It's simple to use. It's fast. It's freeware.
    
    
    
    > 
    > >     Another  tricky  part I expect when telling the parser that a
    > >     literal NUMERIC must not be enclosed into single quotes.
    > 
    > This is probably the worst part, since you would hate to take the hit
    > representing everything as extended precision even if the actual range
    > is int4/float8. Perhaps we can read as those, but if we get a failure
    > then escalate to your extended precision type(s). The automatic type
    > conversion stuff should convert later if necessary, so it might be
    > transparent and relatively fast.
    > 
    > >     The only ugly thing is, that I needed to  put  the  precision
    > >     AND  the  scale together into atttypmod (I limited both to 99
    > >     for now and put them as prec<<8 |  scale  into).  So  pg_dump
    > >     will need attention later.
    > 
    > As Bruce points out, that was anticipated (but I agree it's ugly). Shift
    > over 16 bits if you want...
    > 
    > Congrats!
    > 
    >                         - Tom
    > 
    
    _____________________________________________________________
    Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
    Sternberg Astronomical Institute, Moscow University (Russia)
    Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
    phone: +007(095)939-16-83, +007(095)939-23-83
    
    
    

17. Re: [HACKERS] Upgrades for 6.4.1

    Jan Wieck <jwieck@debis.com> — 1998-12-21T13:00:34Z

    >
    > >     The only ugly thing is, that I needed to  put  the  precision
    > >     AND  the  scale together into atttypmod (I limited both to 99
    > >     for now and put them as prec<<8 |  scale  into).  So  pg_dump
    > >     will need attention later.
    >
    > Atttypmod was expanded to 32 bits for exactly that use.  I recommend
    > 16-bits for each option.
    
        I  tried  that  first  and it failed. Now that you said that,
        I've found in nodes/parsenodes.h that  the  typmod  field  of
        TypeName is still int16.
    
        I'll  change  that  to  int32  after  having  checked that it
        doesn't break anything.
    
        I also read the comment from Oleg  about  the  other  numeric
        package  out.   Haven't  taken  a look at it, but I think for
        Postgres I  would  have  to  build  a  complete  new  set  of
        functions from scratch anyway. The reasons for that are:
    
        1.  I want to store the digits of the NUMERIC type as nibbles
            in the tuple to save space (so  it  will  become  a  real
            packed format). My first hack used one byte per digit and
            I think it's wasted space.
    
        2.  I want to use the VARSIZE, one combined int16 holding the
            sign  and  the  number of digits before the decimal point
            and one int16 holding the digits  to  DISPLAY  after  the
            decimal  point  as  metadata describing the precision and
            calc-/display scale.
    
            None of the packages I've seen up to now has  a  separate
            DISPLAY  scale  in  the  number itself. They all use some
            global scale variable.
    
        3.  The   packed   internal   format   will   need   to    be
            unpacked/packed  for speed on complex operations (divide,
            multiply, log etc.). While add  and  subtract  should  be
            possible directly on the packed format.
    
    
    Jan
    
    --
    
    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me.                                  #
    #======================================== jwieck@debis.com (Jan Wieck) #