Обсуждение: 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
> 
>