Обсуждение: Outdated example in documentation

User's Guide section 7.2, example 7-1, claims that

SELECT 2 ^ 3 AS "Exp";

will be equivalent, after type resolution, to

SELECT CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";

(which is true) or

SELECT 2.0 ^ 3.0 AS "Exp";

which is not true, since 2.0 and 3.0 are nowadays of type numeric.  Rather
than deleting the third branch of this claim (which would also imply
deleting the subsequent Note), does anyone want to think of a new example?

Related observations:  The premise of the example is that the operator ^
only exists for double precision arguments.  ^ 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 also a documented SQL function pow for "numeric", but no operator
for it.  Should that be added?

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.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