Upgrades for 6.4.1

* 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

* 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

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

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

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
===========================================================================

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

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

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

* 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) #

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

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) #

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

Bruce Momjian wrote:

--ELM913959223-29577-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.

Hi Bruce,

Did my patches to psql to correct handle mixed case table names make it into 6.4.1. I can re-send the patches if needed.

--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |

Bruce Momjian wrote:

--ELM913959223-29577-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.

Hi Bruce,

Did my patches to psql to correct handle mixed case table names make it into 6.4.1. I can re-send the patches if needed.

Yes, I believe I applied those patches. The list of changes includes
several mixed-case fixes.

-- 
  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

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

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

Is this running anywhere?

Clark

Just installed the cgi for it at http://www.postgresql.org/cgi/cvsweb ...
I leave it to our esteemed webmaster to make it look good :)

On Sat, 19 Dec 1998, Clark Evans wrote:

Is this running anywhere?

Clark

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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/&quot;&gt;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