Re: [HACKERS] Lost a function overloading capability?

Tom wrote:
>
> I was updating some utilities in config/ the other day and noticed that
> we have apparently lost a capability for function overloading on
> built-in functions:
>
>   CREATE FUNCTION abstime_datetime(int4)
>   RETURNS datetime AS '-' LANGUAGE 'internal';
>
> used to allow me to overload the built-in function abstime_datetime() to
> convert Unix system times stored as integers into a datetime type. I can
> still define it, but it never gets a good input value. For example,
> after defining this function I should be able to say:
>
>   SELECT abstime_datetime(0);
>   abstime_datetime
>   ----------------------------
>   Tue Apr 23 13:51:12 1974 GMT
>   (1 row)
>
> should give me 'Thu Jan 01 00:00:00 1970 GMT' instead. Input values
> which should be passed by reference are also affected.

    With  the  Feb/13  cvs  sources  this  still  worked (haven't
    checked newer one). It returns "epoch" (that is Jan 01  ...).

>
> Does this ring a bell with anyone? Could something have changed with the
> inclusion of the PL interface (just speculating here)? It would be nice
> to get this capability back, and if not then to remove my contrib code
> which no longer works :(

    I  don't  think  the PL interface can cause things like this.
    But I wonder how this could happen at all. The recently fixed
    bug  in  CREATE FUNCTION (proretset true due to TypeName node
    from parser) isn't a candidate  for  that  -  it  would  have
    returned NO data at all.

>
>                                                           - Tom
>
> Another possibility is that I am not remembering the right way to do
> this, _and_ didn't remember correctly _and_ didn't test anything back
> when I make the unixdate.sql contrib file. I don't _think_ I would have
> missed all of these steps, but...
>
>
>


A little confused, Jan


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #