initdb messed up

On Wed, 24 Nov 1999, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > This patch removes the ';' (logarithm) and ':' (exponentiation) operators,
> > as was generally agreed upon.
>
> This is a tad premature IMHO. In the first place, we haven't got the
> replacement functions --- at least not with user-friendly names.
> In the second place, I think we oughta deprecate these things for a
> release or two before we actually remove 'em.

Deprecation is not going to work in this case because those two operators
interfere with their blessed SQL meaning. And now is the time to remove
them. The reason I wanted them removed now is that it is a pain to account
for them, or even disambiguate them, in psql. I guess for now I will no
longer bother with them.

At the risk of taking on more work and/or provoking a holy war, I think
the mathematical operators and function names need some cleaning up in
general. From the previous conversation on this topic I gathered that a
lot of these things are from PostQUEL times. Also, there is some confusion
between float and numeric operators and functions and sometimes they only
work on one, etc.

I don't have the SQL standards around here, but they should be the
reference, so if someone could fill me in. Barring anything that's in
there, I think that there should be a standard set of functions, such as
this:
exp()
log()
pow()
sin(), cos(), ...
abs()
sgn()
factorial()
sqrt()
surd()
floor()
ceil()
trunc()
round()
as well as anything else that's easily thrown in because it's already in
math.h.

All of these functions should be overloaded for float4, float8, and
numeric, as well as int* where appropriate. Some might argue that things
such as sin() or exp() do not make sense for numeric and you should cast
it to float. I'm not sure myself.

Operators should only be assigned if they are in the standard and/or they
make sense to a math person. To me (being a math person), this would
particularly disqualify these operators:
!! -- factorial left operator
% -- truncation left operator (as opposed to % modulo)
: -- exponentiation
; -- logarithm
@ -- absolute value

(Tom speculated that someone might have had some fun writing the parser
and hence threw in these things.)

Rationale:
* Compatibility: break it now or be stuck with it forever
* If anyone actually used the above operators in those meanings, I will
personally congratulate them.
* Someone will have to do it eventually.

This is not something I could do tomorrow anyway, so we can have an
extended discussion. I'm looking forward to it ...

> BTW: a patch that removes user-visible features and breaks regress
> tests is incomplete without doc and test updates...

When will I ever learn ...
Sorry.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut wrote:

> All of these functions should be overloaded for float4, float8, and
> numeric, as well as int* where appropriate. Some might argue that things
> such as sin() or exp() do not make sense for numeric and you should cast
> it to float. I'm not sure myself.

They make sense for numeric, because you can get the sine of
a value with hundreds of SIGNIFICANT digits. Would be damned
slow, but if needed...

NUMERIC has a higher precision than float8. The problem
arising at this point is to ensure that an expression with
mixed attribute types (numeric, floatN and/or integer) must
allways cast anything to numeric if at least one of the
arguments is.

The trigonometric functions are missing for numeric up to
now, but there are Taylor and McLaurin definitions available.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

We have some major initdb breakage from recent initdb patches. I am
going to try and clean it up as best I can, but we will need Peter
involved in fixing this in a portable way.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

>
> We have some major initdb breakage from recent initdb patches. I am
> going to try and clean it up as best I can, but we will need Peter
> involved in fixing this in a portable way.

With my cleanups, I now get. At least it runs now:

---------------------------------------------------------------------------

This database system will be initialized with username "postgres".
This user will own all the data files and must also own the server process.

trap: Illegal number: SIGINT
Creating database system directory /u/pg/data
Creating database system directory /u/pg/data/base
Creating database XLOG directory /u/pg/data/pg_xlog
Creating template database in /u/pg/data/base/template1
ERROR: pg_atoi: error in "f": can't parse "f"
ERROR: pg_atoi: error in "f": can't parse "f"
Creating global relations in /u/pg/data/base
ERROR: pg_atoi: error in "t": can't parse "t"
ERROR: pg_atoi: error in "t": can't parse "t"
Adding template1 database to pg_database
TRAP: Failed Assertion("!(reldesc):", File: "bootstrap.c", Line: 464)

!(reldesc) (0) [No such file or directory]
Abort trap

initdb failed.
Removing /u/pg/data.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026