Re: [PATCHES] Calling a java program thru a trigger or a function in postgresql

2004-02-12 Thread Thomas Hallgren
I think your question is a bit off-topic on this mailinglist. You should
probably post it to pgsql-general.

Anyway, perhaps you'd be interested in looking at
http://gborg.postgresql.org/project/pljava.

Regards,

Thomas Hallgren

- Original Message - 
From: venky [EMAIL PROTECTED]
Newsgroups: comp.databases.postgresql.patches
Sent: Tuesday, January 20, 2004 14:44
Subject: Calling a java program thru a trigger or a function in postgresql


 Here's a high-level overview of what I want to do:

 1.  A record in a postgresql database is changed.
 2.  If the change causes the data record to meet certain conditions based
on
 Boolean logic, a database trigger will invoke a Java UDF.
 3.  This Java UDF uses the JavaMail API to send an e-mail to a specified
 recipient.

 The javamailing program is written separately and is running fine.

 Can any one give me the following details :

 1.  Where to place the java or class file for access.
 2.  plz give me the exact create function statements.
 3.  plz give me the exact create trigger statments.

  O R
 Plz give me the code to satisfy my requirement.

 Thanks in advance for ur help

 venky


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


[PATCHES] Some new SPI functions

2004-02-12 Thread Thomas Hallgren
I need three new functions in the Server Programming Interface (SPI) when
mapping an ExecutionPlan to a Java prepared statement (Pl/Java project).


The execute method of the prepared statement needs to know if the result is
a ResultSet (SPI_cursor_open) or just a number indicated how many rows that
where affected (SPI_execp). Currently there's no way I can tell by just
looking at the plan unless I violate the data hiding and use spi_priv.h. I
really don't want to do that. Hence the need for SPI_is_cursor_plan

I send an array of java objects for the arguments. The
SPI_cursor_open/SPI_execp of course expects the arguments to be Datum's and
the mapper must convert java objects. The mapping code is based on Oid's so
I need a way to extract the number of expected arguments and the typeid of
each arguments.

I find it likely that other pllang implementations where similar support
is planned might find these functions useful.


Thomas Hallgren

Index: src/backend/executor/spi.c
===
retrieving revision 1.109
diff -u -r1.109 spi.c
--- src/backend/executor/spi.c 2 Dec 2003 19:26:47 - 1.109
+++ src/backend/executor/spi.c 12 Feb 2004 11:13:11 -
@@ -918,6 +918,65 @@
  PortalDrop(portal, false);
 }

+/*
+ * Returns the Oid representing the type id for argument at argIndex. First
+ * parameter is at index zero.
+ */
+Oid
+SPI_getargtypeid(void *plan, int argIndex)
+{
+ if (plan == NULL || argIndex  0 || argIndex = ((_SPI_plan*)plan)-nargs)
+ {
+  SPI_result = SPI_ERROR_ARGUMENT;
+  return InvalidOid;
+ }
+ return ((_SPI_plan *) plan)-argtypes[argIndex];
+}
+
+/*
+ * Returns the number of arguments for the prepared plan.
+ */
+int
+SPI_getargcount(void *plan)
+{
+ if (plan == NULL)
+ {
+  SPI_result = SPI_ERROR_ARGUMENT;
+  return -1;
+ }
+ return ((_SPI_plan *) plan)-nargs;
+}
+
+/*
+ * Returns true if the plan contains exactly one command
+ * and that command originates from normal SELECT (i.e.
+ * *not* a SELECT ... INTO). In essence, the result indicates
+ * if the command can be used with SPI_cursor_open
+ *
+ * Parameters
+ *plan A plan previously prepared using SPI_prepare
+ */
+bool
+SPI_is_cursor_plan(void *plan)
+{
+ List *qtlist;
+ _SPI_plan *spiplan = (_SPI_plan *) plan;
+ if (spiplan == NULL)
+ {
+  SPI_result = SPI_ERROR_ARGUMENT;
+  return false;
+ }
+
+ qtlist = spiplan-qtlist;
+ if(length(spiplan-ptlist) == 1  length(qtlist) == 1)
+ {
+  Query *queryTree = (Query *) lfirst((List *) lfirst(qtlist));
+  if(queryTree-commandType == CMD_SELECT  queryTree-into == NULL)
+   return true;
+ }
+ return false;
+}
+
 /* === private functions === */

 /*
Index: src/include/executor/spi.h
===
retrieving revision 1.41
diff -u -r1.41 spi.h
--- src/include/executor/spi.h 2 Dec 2003 19:26:47 - 1.41
+++ src/include/executor/spi.h 12 Feb 2004 11:13:21 -
@@ -90,6 +90,10 @@
 extern void *SPI_saveplan(void *plan);
 extern int SPI_freeplan(void *plan);

+extern Oid SPI_getargtypeid(void *plan, int argIndex);
+extern int SPI_getargcount(void *plan);
+extern bool SPI_is_cursor_plan(void *plan);
+
 extern HeapTuple SPI_copytuple(HeapTuple tuple);
 extern TupleDesc SPI_copytupledesc(TupleDesc tupdesc);
 extern TupleTableSlot *SPI_copytupleintoslot(HeapTuple tuple,



---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Some new SPI functions

2004-02-12 Thread Tom Lane
Thomas Hallgren [EMAIL PROTECTED] writes:
 I need three new functions in the Server Programming Interface (SPI) when
 mapping an ExecutionPlan to a Java prepared statement (Pl/Java project).

These functions look reasonable, but where is the documentation patch?

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] support for printing/exporting xml

2004-02-12 Thread Bruce Momjian

I assume the group agreed that adding XML to libpq was the way to handle
XML, with a hook in psql to call it.

I also see this copyright on one of the files:

+ * Hash Table Data Type
+ * Copyright (C) 1997 Kaz Kylheku [EMAIL PROTECTED]
+ *
+ * Free Software License:
+ *
+ * All rights are reserved by the author, with the following exceptions:
+ * Permission is granted to freely reproduce and distribute this software,
+ * possibly in exchange for a fee, provided that this copyright notice appears
+ * intact. Permission is also granted to adapt this software to produce
+ * derivative works, as long as the modified versions carry this copyright
+ * notice and additional notices stating that the work has been modified.
+ * This source code may be translated into executable form and incorporated
+ * into proprietary software; there is no requirement for such software to
+ * contain a copyright notice related to this source.
+ *

I assume this copyright is compatible with our BSD copyright.

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

http://momjian.postgresql.org/cgi-bin/pgpatches

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

---


Brian Moore wrote:
 hello,
 
 please find attached my support for printing/exporting
 xml from postgresql. psql has been modified to take
 an additional command line argument (-M) to print xml
 and the file fe-printxml.c has been added. additionally,
 i have added an extra function to libpq, PGresult_as_xml
 
 thanks,
 
 b
 
 __
 Do you Yahoo!?
 Yahoo! SiteBuilder - Free web site building tool. Try it!
 http://webhosting.yahoo.com/ps/sb/

Content-Description: postgresql-7.4.1.add_xml_export_support.patch

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
http://archives.postgresql.org

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

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] Some new SPI functions

2004-02-12 Thread Bruce Momjian
Tom Lane wrote:
 Thomas Hallgren [EMAIL PROTECTED] writes:
  I need three new functions in the Server Programming Interface (SPI) when
  mapping an ExecutionPlan to a Java prepared statement (Pl/Java project).
 
 These functions look reasonable, but where is the documentation patch?

I assume it will come when the final patch is submitted.

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

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] support for printing/exporting xml

2004-02-12 Thread Bruce Momjian
Peter Eisentraut wrote:
 Bruce Momjian wrote:
  Peter Eisentraut wrote:
   Bruce Momjian wrote:
I assume the group agreed that adding XML to libpq was the way to
handle XML, with a hook in psql to call it.
  
   I'm not sure about that, but we certainly disagree with this kind
   of nonstandard XML when there is a perfectly good standard out
   there.
 
  OK, can you elaborate?  What is the non-standard part?  His choice of
  tags?
 
 Yes.  The SQL/XML standard has been discussed several times on this 
 list.  Additionally, it has been mentioned that an implementation in 
 libpq is too specific for some.  Some people want streaming interfaces, 
 some want it in the backend, etc.  I think there are going to be many 
 implementations of the XML theme, so I think it's premature to adopt 
 one of them into libpq.

OK, what do you suggest the poster does now?  Use SQL/XML?  Move it into
the backend?

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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [PATCHES] support for printing/exporting xml

2004-02-12 Thread Bruce Momjian

Patch removed.  Requires more discussion.

---

Brian Moore wrote:
 hello,
 
 please find attached my support for printing/exporting
 xml from postgresql. psql has been modified to take
 an additional command line argument (-M) to print xml
 and the file fe-printxml.c has been added. additionally,
 i have added an extra function to libpq, PGresult_as_xml
 
 thanks,
 
 b
 
 __
 Do you Yahoo!?
 Yahoo! SiteBuilder - Free web site building tool. Try it!
 http://webhosting.yahoo.com/ps/sb/

Content-Description: postgresql-7.4.1.add_xml_export_support.patch

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?
 
http://archives.postgresql.org

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

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


[PATCHES] win32 patch: Signal delivery when blocking on semaphore

2004-02-12 Thread Magnus Hagander
This patch makes the block on semaphore interruptible by signals on
win32. Without this, you can't kill a backend when it's waiting on a
lock.

//Magnus


win32_semint.patch
Description: win32_semint.patch

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] support for printing/exporting xml

2004-02-12 Thread Peter Eisentraut
Bruce Momjian wrote:
 Peter Eisentraut wrote:
  Bruce Momjian wrote:
   I assume the group agreed that adding XML to libpq was the way to
   handle XML, with a hook in psql to call it.
 
  I'm not sure about that, but we certainly disagree with this kind
  of nonstandard XML when there is a perfectly good standard out
  there.

 OK, can you elaborate?  What is the non-standard part?  His choice of
 tags?

Yes.  The SQL/XML standard has been discussed several times on this 
list.  Additionally, it has been mentioned that an implementation in 
libpq is too specific for some.  Some people want streaming interfaces, 
some want it in the backend, etc.  I think there are going to be many 
implementations of the XML theme, so I think it's premature to adopt 
one of them into libpq.



---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] temp patch for win32 readdir issue

2004-02-12 Thread Bruce Momjian

Removed.  Adding new version.

---

Magnus Hagander wrote:
 Ok, so I know this is pretty ugly. But there is a bug in mingw (current
 release - it's fixed in the snapshot version) with regards to readdir()
 (see previous mails on win32-hackers). Basically, it doesn't set errno
 correctly.
 
 This patch will catch this error with regards to the readdir(), wrap a
 change in #ifdef WIN32, and emit a warning at compile time. This is a
 temporary measure until mingw releases a version that has this fixed.
 
 Applying this will make it easier on those who want to compile
 postgresql on win32, since it removes a manual step. Which is why I'm
 giving it a shot posting it here even though it's ugly.
 
 //Magnus

Content-Description: win32_readdir.patch

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings

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

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] temp patch for win32 readdir issue

2004-02-12 Thread Bruce Momjian

We will document this on the win32 TODO list and remove this patch once
MinGW is fixed.

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

http://momjian.postgresql.org/cgi-bin/pgpatches

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

---


Magnus Hagander wrote:
 Ok, so I know this is pretty ugly. But there is a bug in mingw (current
 release - it's fixed in the snapshot version) with regards to readdir()
 (see previous mails on win32-hackers). Basically, it doesn't set errno
 correctly.
 
 This patch will catch this error with regards to the readdir(), wrap a
 change in #ifdef WIN32, and emit a warning at compile time. This is a
 temporary measure until mingw releases a version that has this fixed.
 
 Applying this will make it easier on those who want to compile
 postgresql on win32, since it removes a manual step. Which is why I'm
 giving it a shot posting it here even though it's ugly.
 
 //Magnus

Content-Description: win32_readdir.patch

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings

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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] win32 setitimer implementation

2004-02-12 Thread Magnus Hagander
Hello!

Here is a patch that implements setitimer() on win32. With this patch
applied, deadlock detection and statement_timeout now works.

The file timer.c goes into src/backend/port/win32/.

The patch also removes two lines of printf debugging accidentally left
in pqsignal.h, in the console control handler.


//Magnus
 win32_setitimer.patch  timer.c 


win32_setitimer.patch
Description: win32_setitimer.patch


timer.c
Description: timer.c

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Patch for psql startup clarity

2004-02-12 Thread Bruce Momjian
Peter Eisentraut wrote:
 David Fetter wrote:
\? for help with psql commands
 
  If you wanted to pick one of the two patches, which one would it be?
  If not, what should the patch look like?
 
 There seems to be a consensus on the form left standing above.  That 
 seems OK to me.

Attached patch applied.  Thanks.

---

Welcome to psql 7.5devel, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
   \h for help with SQL commands
   \? for help with psql commands
   \g or terminate with semicolon to execute query
   \q to quit

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: doc/TODO
===
RCS file: /cvsroot/pgsql-server/doc/TODO,v
retrieving revision 1.1211
diff -c -c -r1.1211 TODO
*** doc/TODO12 Feb 2004 18:11:16 -  1.1211
--- doc/TODO12 Feb 2004 19:57:01 -
***
*** 1,6 
  TODO list for PostgreSQL
  
! Last updated: Thu Feb 12 13:11:14 EST 2004
  
  Current maintainer:   Bruce Momjian ([EMAIL PROTECTED])
  
--- 1,6 
  TODO list for PostgreSQL
  
! Last updated: Thu Feb 12 13:14:40 EST 2004
  
  Current maintainer:   Bruce Momjian ([EMAIL PROTECTED])
  
Index: doc/src/sgml/start.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/start.sgml,v
retrieving revision 1.34
diff -c -c -r1.34 start.sgml
*** doc/src/sgml/start.sgml 12 Feb 2004 16:38:04 -  1.34
--- doc/src/sgml/start.sgml 12 Feb 2004 19:57:01 -
***
*** 321,327 
   
  Type:  \copyright for distribution terms
 \h for help with SQL commands
!\? for help on internal slash commands
 \g or terminate with semicolon to execute query
 \q to quit
   
--- 321,327 
   
  Type:  \copyright for distribution terms
 \h for help with SQL commands
!\? for help with psql commands
 \g or terminate with semicolon to execute query
 \q to quit
   
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.104
diff -c -c -r1.104 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml  20 Jan 2004 23:48:56 -  1.104
--- doc/src/sgml/ref/psql-ref.sgml  12 Feb 2004 19:57:05 -
***
*** 524,530 
  
  Type:  \copyright for distribution terms
 \h for help with SQL commands
!\? for help on internal slash commands
 \g or terminate with semicolon to execute query
 \q to quit
  
--- 524,530 
  
  Type:  \copyright for distribution terms
 \h for help with SQL commands
!\? for help with psql commands
 \g or terminate with semicolon to execute query
 \q to quit
  
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.83
diff -c -c -r1.83 startup.c
*** src/bin/psql/startup.c  25 Jan 2004 03:07:22 -  1.83
--- src/bin/psql/startup.c  12 Feb 2004 19:57:08 -
***
*** 267,274 
printf(gettext(Welcome to %s %s, the PostgreSQL interactive 
terminal.\n\n
   Type:  \\copyright for 
distribution terms\n
  \\h for help with SQL 
commands\n
! \\? for help on internal slash 
commands\n
!\\g or terminate with semicolon to execute query\n
  \\q to quit\n\n),
   pset.progname, PG_VERSION);
  #ifdef USE_SSL
--- 267,274 
printf(gettext(Welcome to %s %s, the PostgreSQL interactive 
terminal.\n\n
   Type:  \\copyright for 
distribution terms\n
  \\h for help with SQL 
commands\n
! \\? for help with psql 
commands\n
! \\g or terminate with 
semicolon to execute query\n
  \\q to quit\n\n),
   pset.progname, PG_VERSION);
  #ifdef USE_SSL

---(end of broadcast)---
TIP 7: don't forget to increase your free space 

Re: [PATCHES] ANALYZE patch for review

2004-02-12 Thread Bruce Momjian

Applied by Tom.  Thanks.

---

Mark Cave-Ayland wrote:
 Hi Tom,
 
  -Original Message-
  From: Tom Lane [mailto:[EMAIL PROTECTED] 
  Sent: 02 February 2004 16:54
  To: Mark Cave-Ayland
  Cc: [EMAIL PROTECTED]
  Subject: Re: [PATCHES] ANALYZE patch for review 
  
  
  Mark Cave-Ayland [EMAIL PROTECTED] writes:
   So I'd like to propose a slightly different solution. I think that
   examine_attribute() should return a pointer to a custom structure 
   containing any information that needs to be passed to the datatype 
   specific routine (not the entire VacAttrStats structure), 
  or NULL if 
   the column should not be analyzed.
  
  Just a void* you mean?  Sure, we could do that, although it 
  might result in some duplicated effort.  Another possibility 
  is that analyze.c goes ahead and creates a VacAttrStats 
  struct (including a void* extension pointer that it 
  initializes to NULL) and then passes the struct to 
  examine_attribute, which returns a bool and optionally 
  modifies fields in the VacAttrStats struct --- in particular 
  the requested-row-count and extension pointer.  If false is 
  returned then analyze.c just throws away the VacAttrStats 
  struct instead of including it in its to-do list.
 
 Yup indeed. Please find enclosed the latest version of the analyze patch
 taking into account all the things we have discussed in the thread. It
 feels a lot cleaner than the other - the advantage of having
 analyze_rel() create the VacAttrStats structure is that you can put some
 vaguely sensible defaults in the user-defined function so it shouldn't
 bomb too badly if someone gets it wrong, plus the attribute and type
 information can be fed in automagically.
 
 This rewrite has the benefit that it gets rid of the duplication of
 routines having to get their own copies of the attribute and type rows
 based on attnum, and also the (void *) pointer gives a clear abstraction
 of the data required for the pg_statistic table entry and those that are
 used by the current default routine. I also altered the
 examine_attribute() to allow the user-defined function to check
 attstattarget for the column manually (in case they want to do something
 special with minus or zero values), and also as discussed the internal
 stats routine is called directly without requiring an entry in the
 catalog.
 
   If you suppose that the major field is the upper bits of
   the statistics ID value, then this is just a slightly 
   different way of thinking about the range-based allocation 
   method I suggested before.
  
   I was thinking perhaps in terms of an extra staowner int2 field in 
   pg_statistic where the IDs are allocated by the PGDG.
  
  I do not really want to add a field to pg_statistic.  That 
  complicates matters more than we have a justification to do.  
  Nor do we have any reason at this point to think that we need 
  a 2^32 namespace for statistics kinds.  (If 2^16 ever starts 
  to look cramped, we can just widen the fields to int4 without 
  introducing any backwards compatibility issues --- existing 
  code assignments will remain valid.  But I find it hard to 
  foresee that happening.)
 
 OK, I've left this as it is at the moment.
 
 
 Cheers,
 
 Mark.
 
 ---
 
 Mark Cave-Ayland
 Webbased Ltd.
 Tamar Science Park
 Derriford
 Plymouth
 PL6 8BX
 England
 
 Tel: +44 (0)1752 764445
 Fax: +44 (0)1752 764446
 
 
 This email and any attachments are confidential to the intended
 recipient and may also be privileged. If you are not the intended
 recipient please delete it from your system and notify the sender. You
 should not copy it or use it for any purpose nor disclose or distribute
 its contents to any other person.

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

 
 ---(end of broadcast)---
 TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

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

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Some new SPI functions

2004-02-12 Thread Bruce Momjian

Thomas, if this is ready for application, would you make some SGML
changes to match, or give me text to add for them.  Thanks.

---

Thomas Hallgren wrote:
 I need three new functions in the Server Programming Interface (SPI) when
 mapping an ExecutionPlan to a Java prepared statement (Pl/Java project).
 
 
 The execute method of the prepared statement needs to know if the result is
 a ResultSet (SPI_cursor_open) or just a number indicated how many rows that
 where affected (SPI_execp). Currently there's no way I can tell by just
 looking at the plan unless I violate the data hiding and use spi_priv.h. I
 really don't want to do that. Hence the need for SPI_is_cursor_plan
 
 I send an array of java objects for the arguments. The
 SPI_cursor_open/SPI_execp of course expects the arguments to be Datum's and
 the mapper must convert java objects. The mapping code is based on Oid's so
 I need a way to extract the number of expected arguments and the typeid of
 each arguments.
 
 I find it likely that other pllang implementations where similar support
 is planned might find these functions useful.
 
 
 Thomas Hallgren
 
 Index: src/backend/executor/spi.c
 ===
 retrieving revision 1.109
 diff -u -r1.109 spi.c
 --- src/backend/executor/spi.c 2 Dec 2003 19:26:47 - 1.109
 +++ src/backend/executor/spi.c 12 Feb 2004 11:13:11 -
 @@ -918,6 +918,65 @@
   PortalDrop(portal, false);
  }
 
 +/*
 + * Returns the Oid representing the type id for argument at argIndex. First
 + * parameter is at index zero.
 + */
 +Oid
 +SPI_getargtypeid(void *plan, int argIndex)
 +{
 + if (plan == NULL || argIndex  0 || argIndex = ((_SPI_plan*)plan)-nargs)
 + {
 +  SPI_result = SPI_ERROR_ARGUMENT;
 +  return InvalidOid;
 + }
 + return ((_SPI_plan *) plan)-argtypes[argIndex];
 +}
 +
 +/*
 + * Returns the number of arguments for the prepared plan.
 + */
 +int
 +SPI_getargcount(void *plan)
 +{
 + if (plan == NULL)
 + {
 +  SPI_result = SPI_ERROR_ARGUMENT;
 +  return -1;
 + }
 + return ((_SPI_plan *) plan)-nargs;
 +}
 +
 +/*
 + * Returns true if the plan contains exactly one command
 + * and that command originates from normal SELECT (i.e.
 + * *not* a SELECT ... INTO). In essence, the result indicates
 + * if the command can be used with SPI_cursor_open
 + *
 + * Parameters
 + *plan A plan previously prepared using SPI_prepare
 + */
 +bool
 +SPI_is_cursor_plan(void *plan)
 +{
 + List *qtlist;
 + _SPI_plan *spiplan = (_SPI_plan *) plan;
 + if (spiplan == NULL)
 + {
 +  SPI_result = SPI_ERROR_ARGUMENT;
 +  return false;
 + }
 +
 + qtlist = spiplan-qtlist;
 + if(length(spiplan-ptlist) == 1  length(qtlist) == 1)
 + {
 +  Query *queryTree = (Query *) lfirst((List *) lfirst(qtlist));
 +  if(queryTree-commandType == CMD_SELECT  queryTree-into == NULL)
 +   return true;
 + }
 + return false;
 +}
 +
  /* === private functions === */
 
  /*
 Index: src/include/executor/spi.h
 ===
 retrieving revision 1.41
 diff -u -r1.41 spi.h
 --- src/include/executor/spi.h 2 Dec 2003 19:26:47 - 1.41
 +++ src/include/executor/spi.h 12 Feb 2004 11:13:21 -
 @@ -90,6 +90,10 @@
  extern void *SPI_saveplan(void *plan);
  extern int SPI_freeplan(void *plan);
 
 +extern Oid SPI_getargtypeid(void *plan, int argIndex);
 +extern int SPI_getargcount(void *plan);
 +extern bool SPI_is_cursor_plan(void *plan);
 +
  extern HeapTuple SPI_copytuple(HeapTuple tuple);
  extern TupleDesc SPI_copytupledesc(TupleDesc tupdesc);
  extern TupleTableSlot *SPI_copytupleintoslot(HeapTuple tuple,
 
 
 
 ---(end of broadcast)---
 TIP 8: explain analyze is your friend
 

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

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] psql documentation one liner

2004-02-12 Thread Bruce Momjian
Peter Eisentraut wrote:
 Gavin Sherry wrote:
  This just clears up one aspect of variable handling in psql.
  [ variable names are case-sensitive ]
 
 I honestly wonder why this is suddenly of so much interest.  I hope no 
 one is going to question the fact that the command names are 
 case-sensitive.  Do we need a note abou that, too?

Patch applied.  I just added a sentence, rather than an new paragraph. 
I think the confusion is because SQL variable names aren't case
senstitive, so it is a little confusing.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.105
diff -c -c -r1.105 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml  12 Feb 2004 19:58:16 -  1.105
--- doc/src/sgml/ref/psql-ref.sgml  13 Feb 2004 05:08:46 -
***
*** 1613,1618 
--- 1613,1619 
underscores. See the section xref
linkend=APP-PSQL-variables
endterm=APP-PSQL-variables-title below for details.
+   Variable names are case-sensitive.
/para
  
para

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] temp patch for win32 readdir issue

2004-02-12 Thread Neil Conway
Bruce Momjian [EMAIL PROTECTED] writes:
 We will document this on the win32 TODO list and remove this patch once
 MinGW is fixed.

IIRC, Tom and I both suggested that there is no need to clutter the
source tree with a temporary workaround for a platform that hasn't
even seen a stable release yet. Or did I miss something...?

-Neil


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings