From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Jan Wieck <jwieck(at)debis(dot)com> |
Cc: | meskes(at)topsystem(dot)de, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Lost a function overloading capability in v6.3 |
Date: | 1998-03-04 13:53:13 |
Message-ID: | 34FD5CC9.67EE88EB@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1998-03-04 13:57:51 | Re: [HACKERS] version control backups? |
Previous Message | Thomas G. Lockhart | 1998-03-04 13:31:26 | Re: Glibc2 (was Re: [HACKERS] PostgreSQL - the Linux of Databases...) |