Re: Outdated example in documentation

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

In response to

Browse pgsql-hackers by date

  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 ?