Thread
-
Lost a function overloading capability in v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-03T13:54:34Z
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 -
Re: [HACKERS] Lost a function overloading capability in v6.3
Michael Meskes <meskes@topsystem.de> — 1998-03-03T14:03:17Z
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
-
Re: [HACKERS] Lost a function overloading capability in v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-03T14:33:47Z
> 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 -
Re: [HACKERS] Lost a function overloading capability in v6.3
Michael Meskes <meskes@topsystem.de> — 1998-03-03T14:46:24Z
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
-
Re: [HACKERS] Lost a function overloading capability in v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-03T15:19:10Z
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 -
Re: [HACKERS] Lost a function overloading capability in v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-03T16:12:01Z
> 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 -
Re: [HACKERS] Lost a function overloading capability in v6.3
Jan Wieck <jwieck@debis.com> — 1998-03-04T10:45:05Z
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) # -
Re: [HACKERS] Lost a function overloading capability in v6.3
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-04T13:53:13Z
> > > > 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 -
Re: [HACKERS] Lost a function overloading capability in v6.3
Jan Wieck <jwieck@debis.com> — 1998-03-04T15:10:19Z
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) #