type casting troubles

Started by Thomas Lockhartover 24 years ago6 messages
#1Thomas Lockhart
lockhart@fourpalms.org

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Lockhart (#1)
Re: type casting troubles

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

#3Thomas Lockhart
lockhart@fourpalms.org
In reply to: Thomas Lockhart (#1)
Re: type casting troubles

#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

#4Thomas Lockhart
lockhart@fourpalms.org
In reply to: Thomas Lockhart (#1)
Re: type casting troubles

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

#5Thomas Lockhart
lockhart@fourpalms.org
In reply to: Thomas Lockhart (#1)
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

#6Otto Hirr
otto.hirr@olabinc.com
In reply to: Thomas Lockhart (#5)
Re: type casting troubles

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

Show quoted text

-----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