From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | "'pgsql-interfaces(at)postgresql(dot)org'" <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | Re: ODBC: Declare/Fetch & SELECT INTO |
Date: | 2000-08-31 21:47:07 |
Message-ID: | 11286.967758427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Dave Page <dpage(at)vale-housing(dot)co(dot)uk> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2000-08-31 22:07:28 | ODBC: Declare/Fetch & SELECT INTO |
Previous Message | Joel Burton | 2000-08-31 18:35:51 | Re: convert from access |