Re: [BUGS] BUG #2129: dblink problem

From: Joe Conway <mail(at)joeconway(dot)com>
To: Akio Iwaasa <iwaasa(at)mxs(dot)nes(dot)nec(dot)co(dot)jp>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [BUGS] BUG #2129: dblink problem
Date: 2006-01-03 02:34:23
Message-ID: 43B9E2AF.7040003@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-patches

Akio Iwaasa wrote:
> The following bug has been logged online:
>
> Bug reference: 2129
> Logged by: Akio Iwaasa

>
> "postgres" process terminated with "signal 11"
> because of my wrong SQL statement using "dblink".
>
> --- SQL statement(Select statement a function) ---
> select into RET *
> from dblink(''select C1,C2,C3 from TABLE01 where ... '') <<<<< 3 column
> as LINK_TABLE01(LC1 varchar(5),LC2 varchar(5),
> LC3 varchar(5),LC4 varchar(5)) ; <<<<< 4 column

The attached patch (against cvs HEAD) fixes the reported issue.

However, there is a remaining oddity with dblink_fetch(). Basically,
each time dblink_fetch() is called, the named cursor is advanced, even
though an error is thrown before returning any rows. Is there a simple
way to get the number of columns in the result, without actually
advancing the cursor?

If no one thinks the above is a problem, I'll commit the attached
against HEAD and stable branches back to 7.3.

Joe

Attachment Content-Type Size
current.diff text/x-patch 2.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Joe Conway 2006-01-03 05:09:29 Re: [BUGS] BUG #2129: dblink problem
Previous Message Bernhard Rosenkraenzer 2006-01-02 19:29:44 BUG #2138: Feature request: handle foreign key constraints on arrays

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-01-03 02:47:57 ShmemIndexLock rewrite
Previous Message Marko Kreen 2006-01-02 22:55:36 pgcrypto: bug in gen_salt (md5/xdes)