On Wed, 24 Nov 1999, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.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@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 25 Nov 1999 14:08:41 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [PATCHES] ':' and ';' operators 
Peter Eisentraut <e99re41@DoCS.UU.SE> 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.

It's always been true (or at least been true for a long time) that ';'
used as an operator has to appear inside parens, like "SELECT (;2)",
to keep psql from thinking that it's a statement terminator.  Can't you
maintain that behavior?

':' is a little trickier --- if you want to use it to reference
psql-provided variables, then there's probably no way you can support it
as an SQL operator too.  Of course ecpg must have the same problem.

> 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 think most of the confusion in this area comes from the fact that
while operators have always (?) been overloadable across types, up till
6.5 built-in functions had to have the same names in SQL as in the C
code, and therefore the function names for different data types had to
be different.  The only way to overload a function name was to make an
ugly (and slow) SQL function wrapper.  So there was a strong notational
advantage to using operator rather than function syntax for anything
that was useful for more than one datatype.  That problem's gone now.

I'm not in favor of removing the operators, except maybe for ';' and ':',
but I agree it'd be a fine idea to provide standardized function names
across all the numeric data types, and to make sure that the operators
that are there work on NUMERIC too.

> I don't have the SQL standards around here, but they should be the
> reference,

SQL doesn't address math functions at all, AFAICS.  Given that lack,
the names used in C's <math.h> look OK to me, with the exception that
I'd rather see abs() than fabs().

			regards, tom lane

Thu, 25 Nov 1999 10:47:20 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: [PATCHES] ':' and ';' operators 
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@debis.com (Jan Wieck) #



Thu, 25 Nov 1999 17:02:57 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] Re: [PATCHES] ':' and ';' operators
Tom Lane wrote:

>
> > I don't have the SQL standards around here, but they should be the
> > reference,
>
> SQL doesn't address math functions at all, AFAICS.  Given that lack,
> the names used in C's <math.h> look OK to me, with the exception that
> I'd rather see abs() than fabs().
>
>                         regards, tom lane

For what its worth (I'll probably get brow-beaten for even mentioning this :-) ),
the ODBC 2.0 specification allows clients to test ODBC data sources to determine
if the data source has implemented the following:

ABS(numeric),
ACOS(float),
ASIN(float),
ATAN(float),
ATAN2(float1, float2),
CEILING(numeric),
COS(float),
COT(float),
EXP(float),
FLOOR(numeric),
LOG(float),
MOD(integer1, integer2),
SIGN(numeric),
SIN(float),
SQRT(float),
TAN(float),
PI(),
RAND([integer]),
DEGREES(numeric),
LOG10(float),
POWER(numeric, integer),
RADIANS(numeric),
ROUND(numeric, integer),
TRUNCATE(numeric, integer)

Anways, thats the list for ODBC 2.0 -- I'm not sure what ODBC 3.0 has....

Mike






Thu, 25 Nov 1999 12:12:44 -0500
mascarm@mascari.com
Re: [HACKERS] Re: [PATCHES] ':' and ';' operators

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

Fri, 17 Dec 1999 21:42:24 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
initdb messed up
> 
> 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@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

Fri, 17 Dec 1999 21:56:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] initdb messed up