dblink bug fix - please apply prior to wrapping up beta tarball

Your patch has been added to the PostgreSQL unapplied patches list at:

http://207.106.42.251/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Joe Conway wrote:

This fixes dblink for breakage related to the last minute
CreateTemplateTupleDesc changes (elimination of WITHOUTOID in favor of
true/false).

Please apply.

Thanks,

Joe

Index: contrib/dblink/dblink.c
===================================================================
RCS file: /opt/src/cvs/pgsql-server/contrib/dblink/dblink.c,v
retrieving revision 1.10
diff -c -r1.10 dblink.c
*** contrib/dblink/dblink.c	2 Sep 2002 06:13:31 -0000	1.10
--- contrib/dblink/dblink.c	3 Sep 2002 03:05:12 -0000
***************
*** 463,469 ****
is_sql_cmd = true;

/* need a tuple descriptor representing one TEXT column */
! tupdesc = CreateTemplateTupleDesc(1, WITHOUTOID);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "status",
TEXTOID, -1, 0, false);

--- 463,469 ----
is_sql_cmd = true;

/* need a tuple descriptor representing one TEXT column */
! tupdesc = CreateTemplateTupleDesc(1, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "status",
TEXTOID, -1, 0, false);

***************
*** 628,634 ****
if (PQresultStatus(res) == PGRES_COMMAND_OK)
{
/* need a tuple descriptor representing one TEXT column */
! tupdesc = CreateTemplateTupleDesc(1, WITHOUTOID);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "status",
TEXTOID, -1, 0, false);

--- 628,634 ----
if (PQresultStatus(res) == PGRES_COMMAND_OK)
{
/* need a tuple descriptor representing one TEXT column */
! 			tupdesc = CreateTemplateTupleDesc(1, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "status",
TEXTOID, -1, 0, false);

***************
*** 883,889 ****
elog(ERROR, "dblink_get_pkey: relation does not exist");

/* need a tuple descriptor representing one INT and one TEXT column */
! 		tupdesc = CreateTemplateTupleDesc(2, WITHOUTOID);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "position",
INT4OID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "colname",
--- 883,889 ----
elog(ERROR, "dblink_get_pkey: relation does not exist");

/* need a tuple descriptor representing one INT and one TEXT column */
! tupdesc = CreateTemplateTupleDesc(2, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 1, "position",
INT4OID, -1, 0, false);
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "colname",
***************
*** 1936,1942 ****
if (natts < 1)
elog(ERROR, "cannot create a description for empty results");

! desc = CreateTemplateTupleDesc(natts, WITHOUTOID);

attnum = 0;

--- 1936,1942 ----
if (natts < 1)
elog(ERROR, "cannot create a description for empty results");

! desc = CreateTemplateTupleDesc(natts, false);

attnum = 0;

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joe Conway <mail@joeconway.com> writes:

This fixes dblink for breakage related to the last minute
CreateTemplateTupleDesc changes (elimination of WITHOUTOID in favor of
true/false).

Applied. Sorry about that, but I knew you were working on dblink and
thought it best not to joggle your elbow. Is contrib/tablefunc okay?

regards, tom lane

Tom Lane wrote:

Applied. Sorry about that, but I knew you were working on dblink and
thought it best not to joggle your elbow. Is contrib/tablefunc okay?

No sweat! Yesterday was a bit of a whirlwind around cvs. I tested
contrib/tablefunc also and it seems OK.

BTW, that connectby function gave me the impression that it may actually
be simpler for the function writer to build and return their own
tuplestore. A lot of complexity is removed by not having to deal with
multiple calls.

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:

BTW, that connectby function gave me the impression that it may actually
be simpler for the function writer to build and return their own
tuplestore. A lot of complexity is removed by not having to deal with
multiple calls.

For sure. The only saving grace of the multiple-calls thing is that it
allows you to cope with indefinitely large result sets ... and we're
blowing that advantage by stuffing the result into a tuplestore back
at nodeFunctionscan.c, anyway. I still want to revisit that set of
issues someday soon (not for 7.3 of course).

regards, tom lane