Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Lost a function overloading capability in v6.3

From: jwieck(at)debis(dot)com (Jan Wieck)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: jwieck(at)debis(dot)com, 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 15:10:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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).



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

In response to

pgsql-hackers by date

Next:From: Jan WieckDate: 1998-03-04 15:43:03
Subject: Speedups
Previous:From: Thomas A. SzybistDate: 1998-03-04 14:57:57
Subject: Re: Glibc2 (was Re: [HACKERS] PostgreSQL - the Linux of Databases...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group