Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id E508B475D93 for ; Mon, 14 Oct 2002 13:29:02 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 59BD7475D12 for ; Mon, 14 Oct 2002 13:29:02 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9EHSwhR017248; Mon, 14 Oct 2002 13:28:58 -0400 (EDT) To: "Nigel J. Andrews" Cc: Constantin Teodorescu , PostgreSQL Interfaces Subject: Re: GD global data array capabilities in pltcl In-reply-to: References: Comments: In-reply-to "Nigel J. Andrews" message dated "Mon, 14 Oct 2002 17:20:40 +0100" Date: Mon, 14 Oct 2002 13:28:57 -0400 Message-ID: <17247.1034616537@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/41 X-Sequence-Number: 3203 "Nigel J. Andrews" writes: > so I would say it's not accessable from other functions within the same > backend. I doubt very much that this data is database wide I can only see it > being backend specific. It's definitely backend-local. I imagine you could access another procedure's GD if you could determine its name (it's built from the pg_proc OID, I think). However, if you want to share global data across pltcl functions in the same backend session, you shouldn't bother with GD at all: just create named global Tcl variables. All pltcl functions in a backend run in the same interpreter, so they can trivially access global variables. regards, tom lane