Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.10.1/8.10.1) with ESMTP id e7VLlBC36310 for ; Thu, 31 Aug 2000 17:47:11 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id RAA11289; Thu, 31 Aug 2000 17:47:08 -0400 (EDT) To: Dave Page cc: "'pgsql-interfaces@postgresql.org'" Subject: Re: ODBC: Declare/Fetch & SELECT INTO In-reply-to: <8568FC767B4AD311AC33006097BCD3D6091945@woody.vale-housing.co.uk> References: <8568FC767B4AD311AC33006097BCD3D6091945@woody.vale-housing.co.uk> Comments: In-reply-to Dave Page message dated "Thu, 31 Aug 2000 22:07:28 -0000" Date: Thu, 31 Aug 2000 17:47:07 -0400 Message-ID: <11286.967758427@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200008/196 Dave Page writes: > The following is from the commlog - the table is not created, and no error > is raised: > conn=52758652, query='declare SQL_CUR0325413C cursor for SELECT * INTO > pgadmin_desc FROM pg_description WHERE objoid > 18655' Hmm. I'd say that that should raise an error, since you are giving the backend conflicting instructions about where to deliver the selected tuples (through the cursor, or into a new table). I think right now the code simply ignores the INTO clause when the context is a cursor declaration, but giving an error if both are specified seems more appropriate. However, that might not help you very much :-(. I take it you are just issuing a SELECT INTO command yourself, and ODBC is tacking on the DECLARE CURSOR part? Seems ODBC needs to know not to do that for a SELECT INTO. regards, tom lane