Thread: Re: [PATCHES] ':' and ';' operators
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
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
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) #
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
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, Pennsylvania19026
>
> 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,
Pennsylvania19026