I had developed a "cheat" to help people convert Unix system time stored
as an integer into a true date/time type. I noticed that it did not work
prior to the v6.3 release, but have now gone back to v6.2.1 and
confirmed that it works there. Can someone test this on their
installation and confirm that it is a problem for all v6.3 (since
someone reported that it worked for them earlier, but I'm not sure how
that could be):

  CREATE FUNCTION abstime_datetime(int4)
  RETURNS datetime
  AS '-' LANGUAGE 'internal';

For v6.2.1, here is the result:

postgres=> select abstime_datetime(0);
abstime_datetime
----------------
epoch
(1 row)
postgres=> select abstime_datetime(900000000);
abstime_datetime
----------------------------
Thu Jul 09 16:00:00 1998 GMT
(1 row)

When I run this same thing on v6.3, I get a date sometime in 1974 which
I think might actually be derived from a pointer interpreted as an
integer :(

postgres=> select abstime_datetime(0);
abstime_datetime
----------------------------
Wed Apr 24 18:51:28 1974 GMT
(1 row)
postgres=> select abstime_datetime(900000000);
abstime_datetime
----------------------------
Wed Apr 24 18:37:12 1974 GMT
(1 row)

Any ideas where to look? It would be a shame to lose this capability.
Although the example is perhaps not too respectable, it illustrates a
useful feature...

                                                                       -
Tom


Tue, 03 Mar 1998 13:54:34 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Lost a function overloading capability in v6.3
Thomas G. Lockhart writes:
>   CREATE FUNCTION abstime_datetime(int4)
>   RETURNS datetime
>   AS '-' LANGUAGE 'internal';

Did that. Could anyone please tell me how to drop this function?

> When I run this same thing on v6.3, I get a date sometime in 1974 which
> I think might actually be derived from a pointer interpreted as an
> integer :(
> 
> postgres=> select abstime_datetime(0);
> abstime_datetime
> ----------------------------
> Wed Apr 24 18:51:28 1974 GMT
> (1 row)
> postgres=> select abstime_datetime(900000000);
> abstime_datetime
> ----------------------------
> Wed Apr 24 18:37:12 1974 GMT
> (1 row)

mm=> select abstime_datetime(0);
abstime_datetime
----------------
epoch           
(1 row)

mm=> select abstime_datetime(900000000);
abstime_datetime
----------------
epoch           
(1 row)

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Tue, 3 Mar 1998 15:03:17 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: [HACKERS] Lost a function overloading capability in v6.3
> Thomas G. Lockhart writes:
> >   CREATE FUNCTION abstime_datetime(int4)
> >   RETURNS datetime
> >   AS '-' LANGUAGE 'internal';
>
> Did that. Could anyone please tell me how to drop this function?

destroydbcreatedb

Oops. Sorry about that. The good news is that the function isn't damaging to
your system :-/

> > When I run this same thing on v6.3, I get a date sometime in 1974 which
> > I think might actually be derived from a pointer interpreted as an
> > integer :(
> >
> > postgres=> select abstime_datetime(0);
> > abstime_datetime
> > ----------------------------
> > Wed Apr 24 18:51:28 1974 GMT
> > (1 row)
> > postgres=> select abstime_datetime(900000000);
> > abstime_datetime
> > ----------------------------
> > Wed Apr 24 18:37:12 1974 GMT
> > (1 row)
>
> mm=> select abstime_datetime(0);
> abstime_datetime
> ----------------
> epoch
> (1 row)
>
> mm=> select abstime_datetime(900000000);
> abstime_datetime
> ----------------
> epoch
> (1 row)

OK, so that is on a v6.3 system Michael? Then does anyone have an idea why
my system is showing a problem? Can someone running on Linux (RH4.2, 2.0.30
kernel) try this out?? _Everything_ in the regression tests is OK...

                                            - Tom


Tue, 03 Mar 1998 14:33:47 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Lost a function overloading capability in v6.3
Thomas G. Lockhart writes:
> destroydbcreatedb
> 
> Oops. Sorry about that. The good news is that the function isn't damaging to
> your system :-/

No problem. It's my test DB anyway.
 
> > mm=> select abstime_datetime(900000000);
> > abstime_datetime
> > ----------------
> > epoch
> > (1 row)

Is this answer correct?

> OK, so that is on a v6.3 system Michael? Then does anyone have an idea why

This was on v6.3. cvsup'ed this morning. 

> my system is showing a problem? Can someone running on Linux (RH4.2, 2.0.30
> kernel) try this out?? _Everything_ in the regression tests is OK...

I do run Linux, what else? :-)

My system is Debian 2.0, 2.0.33 kernel, glibc-2.0.7.

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

Tue, 3 Mar 1998 15:46:24 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: [HACKERS] Lost a function overloading capability in v6.3
Michael Meskes wrote:

> Thomas G. Lockhart writes:
> > destroydbcreatedb
> >
> > Oops. Sorry about that. The good news is that the function isn't damaging to
> > your system :-/
>
> No problem. It's my test DB anyway.
>
> > > mm=> select abstime_datetime(900000000);
> > > abstime_datetime
> > > ----------------
> > > epoch
> > > (1 row)
>
> Is this answer correct?

Oh! I only noticed the first one, which was the right answer. You are getting
zero into the function in both cases, where for my machine I'm getting garbage
which might be uninitialized stuff or a pointer.

Neither are correct.

Can someone speculate where this might be happening? I don't even know where to
start looking :(

                                                 - Tom


Tue, 03 Mar 1998 15:19:10 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Lost a function overloading capability in v6.3
> Oh! I only noticed the first one, which was the right answer. You are getting
> zero into the function in both cases, where for my machine I'm getting garbage
> which might be uninitialized stuff or a pointer.
>
> Neither are correct.
>
> Can someone speculate where this might be happening? I don't even know where to
> start looking :(

More information: my snapshots through 980112 work correctly, so the breakage
happened after that.

                                              - Tom


Tue, 03 Mar 1998 16:12:01 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Lost a function overloading capability in v6.3

Tom wrote:

> > > When I run this same thing on v6.3, I get a date sometime in 1974 which
> > > I think might actually be derived from a pointer interpreted as an
> > > integer :(
> > >
> > > postgres=> select abstime_datetime(0);
> > > abstime_datetime
> > > ----------------------------
> > > Wed Apr 24 18:51:28 1974 GMT
> > > (1 row)
> > > postgres=> select abstime_datetime(900000000);
> > > abstime_datetime
> > > ----------------------------
> > > Wed Apr 24 18:37:12 1974 GMT
> > > (1 row)
> >
> > mm=> select abstime_datetime(0);
> > abstime_datetime
> > ----------------
> > epoch
> > (1 row)
> >
> > mm=> select abstime_datetime(900000000);
> > abstime_datetime
> > ----------------
> > epoch
> > (1 row)
>
> OK, so that is on a v6.3 system Michael? Then does anyone have an idea why
> my system is showing a problem? Can someone running on Linux (RH4.2, 2.0.30
> kernel) try this out?? _Everything_ in the regression tests is OK...

    The  bug  is  that  when  the  language  is  internal but the
    function isn't in the builtin table, fmgr_info() (in  fmgr.c)
    doesn't  set  fn_nargs.  So fmgr_c() calls abstime_datetime()
    without arguments.

    Add

    finfo->fn_nargs = procedureStruct->pronargs;

    in the INTERNALlanguageId arm of the switch in  fmgr.c  (line
    198).


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) #



Wed, 4 Mar 1998 11:45:05 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Lost a function overloading capability in v6.3
> > > > When I run this same thing on v6.3, I get a date sometime in 1974 which
> > > > I think might actually be derived from a pointer interpreted as an
> > > > integer :(
>
>     The  bug  is  that  when  the  language  is  internal but the
>     function isn't in the builtin table, fmgr_info() (in  fmgr.c)
>     doesn't  set  fn_nargs.  So fmgr_c() calls abstime_datetime()
>     without arguments.
>
>     Add
>
>     finfo->fn_nargs = procedureStruct->pronargs;
>
>     in the INTERNALlanguageId arm of the switch in  fmgr.c  (line
>     198).

THANKS JAN! I was just getting started doing a binary search of the source trees
trying to find when the problem was introduced. This saved me a _lot_ of time...

I just tried it and it works! I added the line just below the elog(ERROR) check
in that same block of code.

Now, should this be done conditionally or is it OK to set this all the time? I
looked back at the v6.2.1 code and this field was not explicitly set in this
area, so has the behavior of something else changed? What would you suggest??

                                             - Tom


Wed, 04 Mar 1998 13:53:13 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Lost a function overloading capability in v6.3

Tom wrote:
>
> > > > > When I run this same thing on v6.3, I get a date sometime in 1974 which
> > > > > I think might actually be derived from a pointer interpreted as an
> > > > > integer :(
> >
> >     The  bug  is  that  when  the  language  is  internal but the
> >     function isn't in the builtin table, fmgr_info() (in  fmgr.c)
> >     doesn't  set  fn_nargs.  So fmgr_c() calls abstime_datetime()
> >     without arguments.
> >
> >     Add
> >
> >     finfo->fn_nargs = procedureStruct->pronargs;
> >
> >     in the INTERNALlanguageId arm of the switch in  fmgr.c  (line
> >     198).
>
> THANKS JAN! I was just getting started doing a binary search of the source trees
> trying to find when the problem was introduced. This saved me a _lot_ of time...
>
> I just tried it and it works! I added the line just below the elog(ERROR) check
> in that same block of code.
>
> Now, should this be done conditionally or is it OK to set this all the time? I
> looked back at the v6.2.1 code and this field was not explicitly set in this
> area, so has the behavior of something else changed? What would you suggest??

    I  think  it's  O.K.  to set it all the time. As far as I can
    see, the declarations for  the  builtin  functions  have  the
    correct  nargs  settings (varcharin 3 args). And this is what
    they have in the pg_proc's  pronargs  attribute.  Adding  the
    above  line only touches overloading builtin functions. Since
    the call of such an overload goes through fmgr_c(),  it  MUST
    be done (fmgr_c must know how many arguments to pass).


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) #



Wed, 4 Mar 1998 16:10:19 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Lost a function overloading capability in v6.3