type casting troubles - Mailing list pgsql-hackers
From | Thomas Lockhart |
---|---|
Subject | type casting troubles |
Date | |
Msg-id | 3BA95092.54F5DB33@fourpalms.org Whole thread Raw |
Responses |
Re: type casting troubles
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
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
pgsql-hackers by date: