> > > > 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.
> finfo->fn_nargs = procedureStruct->pronargs;
> in the INTERNALlanguageId arm of the switch in fmgr.c (line
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??
In response to
pgsql-hackers by date
|Next:||From: Thomas G. Lockhart||Date: 1998-03-04 13:57:51|
|Subject: Re: [HACKERS] version control backups?|
|Previous:||From: Thomas G. Lockhart||Date: 1998-03-04 13:31:26|
|Subject: Re: Glibc2 (was Re: [HACKERS] PostgreSQL - the Linux of Databases...)|