Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.8.8) with ESMTP id KAA08201; Mon, 5 Oct 1998 10:12:47 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA22736; Mon, 5 Oct 1998 10:11:51 -0400 (EDT) To: "Thomas G. Lockhart" cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: [HACKERS] TCL_ARRAYS code in libpgtcl is pretty seriously broken In-reply-to: Your message of Mon, 05 Oct 1998 00:57:02 +0000 <3618195E.6FE14EF6@alumni.caltech.edu> Date: Mon, 05 Oct 1998 10:11:51 -0400 Message-ID: <22734.907596711@sss.pgh.pa.us> From: Tom Lane "Thomas G. Lockhart" writes: > This isn't a definitive answer and there may be another way to discover > array-ness but it's where I would look. Not sure if you'd be happy > having to do a select on pg_type for every query unless you're doing it > already... I think that won't fly for performance reasons. I know I wouldn't want my Tcl applications paying an additional frontend-to-backend round trip for every SELECT result... I was actually a tad surprised to realize that the column-type info sent by the backend couldn't answer such a basic question as "is this an array?". Something to fix if we ever rev the FE/BE protocol again. Don't think I'd propose a protocol rev just for this, though. In the meantime, I'm inclined to take the fallback approach I suggested yesterday: provide the array-to-list reformatting function as a separate Tcl statement that the application programmer can decide to invoke. The app writer is likely to know perfectly well where he needs that feature anyway. regards, tom lane