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