Lost a function overloading capability in v6.3
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
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
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
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
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
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
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) #
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
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) #