From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Outdated example in documentation |
Date: | 2003-02-24 20:42:49 |
Message-ID: | 5378.1046119369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Related observations: The premise of the example is that the operator ^
> only exists for double precision arguments.
Which is what makes it difficult to think of a future-proof example :-(
> ^ is implemented using SQL
> function dpow, which is implemented using C function dpow. There's also a
> documented SQL function pow, which is implemented using C function dpow.
> Wouldn't it be enough to have the documented SQL function pow and the
> operator on top of that?
There's quite a bit of redundancy of this sort in pg_proc. You will
find however that getting rid of it is easier said than done. (Hint:
type regproc doesn't know about overloading, therefore references from
initdb-time entries in pg_operator to pg_proc had better refer to
uniquely named functions.) Short of massive redesign of the initdb
process, the extra entries aren't going away. Even if we wanted to
do the work, there's the certainty that some user applications are
referring to those functions by name.
> There's also a documented SQL function pow for "numeric", but no operator
> for it. Should that be added?
Sure, but you'll find it has to go through numeric_power ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-24 21:23:44 | Re: Possibly inconsistent type casting logic |
Previous Message | Darko Prenosil | 2003-02-24 19:53:05 | I cant find it or I'm just lazy ? |