Обсуждение: type casting troubles
I have split the timestamp data type into two types to better match SQL9x specs. I've implemented them as "timestamp" and "timestamptz" (the latter corresponding to the implementation in recent releases), and have implemented conversion routines between the two types. However, I expect to be able to cast one to the other, but am crashing the server deep down in the executor when phrasing a query using the CAST() syntax, whereas an explicit call to the conversion routine seems to work fine. I thought that I understood the mechanisms for this casting (I'd done the original implementation, after all ;) but the code has evolved since then, presumably for the better. Any hints on what could be happening? - Thomas thomas=# select timestamp without time zone 'now',timestamptz(timestamp without time zone 'now'); ------------------------+---------------------------2001-09-19 19:05:07.81 | 2001-09-19 19:05:07.81-07 (1 row) thomas=# select cast(timestamp without time zone 'now' as timestamptz); server closed the connection unexpectedly backend> select cast(timestamp without time zone 'now' as timestamptz); Program received signal SIGSEGV, Segmentation fault. 0x401286f6 in strncpy () from /lib/libc.so.6 (gdb) where #0 0x401286f6 in strncpy () from /lib/libc.so.6 #1 0x819fc77 in namestrcpy (name=0x82d6340, str=0x1f8 <Address 0x1f8 out of bounds>) at name.c:175 #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, attributeName=0x1f8 <Address 0x1f8 out of bounds>,oidtypeid=1184, typmod=-1, attdim=0, attisset=0 '\000') at tupdesc.c:365 #3 0x810d309 in ExecTypeFromTL (targetList=0x82d60a8) at execTuples.c:594 #4 0x810d63d in ExecAssignResultTypeFromTL (node=0x82d60c4, commonstate=0x82d628c) at execUtils.c:288 #5 0x8115072 in ExecInitResult (node=0x82d60c4, estate=0x82d616c, parent=0x0) at nodeResult.c:227 #6 0x8109334 in ExecInitNode (node=0x82d60c4, estate=0x82d616c, parent=0x0) at execProcnode.c:140 #7 0x8107570 in InitPlan (operation=CMD_SELECT, parseTree=0x82d23cc, plan=0x82d60c4, estate=0x82d616c) at execMain.c:628 #8 0x8106c5e in ExecutorStart (queryDesc=0x82d6150, estate=0x82d616c) at execMain.c:135 #9 0x817e719 in ProcessQuery (parsetree=0x82d23cc, plan=0x82d60c4, dest=Debug) at pquery.c:257 #10 0x817cbf2 in pg_exec_query_string ( query_string=0x82d2008 "select cast(timestamp without time zone 'now' as timestamptz);\n", dest=Debug, parse_context=0x82a5e94) at postgres.c:812 #11 0x817e0c1 in PostgresMain (argc=2, argv=0xbffff6f4, real_argc=2, real_argv=0xbffff6f4, username=0x828f6d8 "thomas") at postgres.c:1963 #12 0x81236e5 in main (argc=2, argv=0xbffff6f4) at main.c:203 #13 0x400e9cbe in __libc_start_main () from /lib/libc.so.6
Thomas Lockhart <lockhart@fourpalms.org> writes: > #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, > attributeName=0x1f8 <Address 0x1f8 out of bounds>, oidtypeid=1184, > typmod=-1, attdim=0, > attisset=0 '\000') at tupdesc.c:365 This appears to indicate that you have a Resdom node with an invalid resname field. Seems like that wouldn't be a datatype-specific issue at all. Have you changed the handling of cast() nodes? regards, tom lane
> > #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, > > attributeName=0x1f8 <Address 0x1f8 out of bounds>, oidtypeid=1184, > > typmod=-1, attdim=0, > > attisset=0 '\000') at tupdesc.c:365 > This appears to indicate that you have a Resdom node with an invalid > resname field. Seems like that wouldn't be a datatype-specific issue > at all. Have you changed the handling of cast() nodes? Nothing changed afaik, though I *have* accumulated a few changes over the last couple of months which I have not committed back to cvs. I'll look at it, but can't think of why I'd be messing with TypeCast nodes at all. I'd have expected that all of the nodes would have references to timestamp and timestamptz by the time I'm that far into the executor, and they seem to be data types in good standing for other purposes at least. - Thomas
> Nope, these variants all work for me. But I know where the problem is > now: you have a broken version of FigureColname() in parse_target.c. > Somebody submitted a bogus patch last week; I've fixed it in current > CVS, but evidently your sources are from last week. Sure. cvsup needed to be upgraded on hub.org (and I wasn't certain it would work anyway given the recent changes), so I stopped updating my tree while I was in the middle of the big push to get the date/time stuff written. Darn. - Thomas
OK, I see a patch from 2001-09-10 for parse_target.c which is a smoking gun. The patch tries to force a column name for the TypeCast node, and doesn't check to see if one was actually specified :( So that probably explains why, on my system, select cast(int4 '1' as float8); fails, while select cast(int4 '1' as float8) as "foobar"; succeeds. Ouch. I've wasted a bunch of time on this. - Thomas
When will CVSup be upgraded? I continue to see that you have the time bug. I just ran cvsup and got: Parsing supfile "cvsup_config" Connecting to postgresql.org Connected to postgresql.org Server software version: REL_16_1 Server postgresql.org has the S1G bug See http://www.polstra.com/projects/freeware/CVSup/s1g/ for details Please notify the maintainer of postgresql.org Refusing update from server with S1G bug Regards, .. Otto Otto Hirr OLAB Inc 503.617.6595 otto.hirr@olabinc.com > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of > Thomas Lockhart > Sent: Thursday, September 20, 2001 7:57 AM > To: Tom Lane > Cc: Hackers List > Subject: Re: type casting troubles > > > > Nope, these variants all work for me. But I know where the > problem is > > now: you have a broken version of FigureColname() in parse_target.c. > > Somebody submitted a bogus patch last week; I've fixed it in current > > CVS, but evidently your sources are from last week. > > Sure. cvsup needed to be upgraded on hub.org (and I wasn't certain it > would work anyway given the recent changes), so I stopped updating my > tree while I was in the middle of the big push to get the date/time > stuff written. > > Darn. > > - Thomas > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > >