Re: [PATCHES] Path to enable a module to change the stack_base_ptr

2005-10-13 Thread Thomas Hallgren

Tom Lane wrote:

Bruce Momjian pgman@candle.pha.pa.us writes:
  

Tom Lane wrote:
  

I'm not really in favor of this ... I think you are trying to make the
backend do something that will never work reliably.



  

Do we want to make this change for 8.1?



I don't want to do it at all.  The justification given is to allow the
backend to support multithreading introduced by an add-on library, which
is a hopeless cause.  Removing static from that variable declaration
is surely a cheap enough change, but what about the next request, and
the one after that?
  
Tom, I don't request that the backend should support multiple threads 
simultaneously. It's one thread at a time. I can't think of a next 
request in this direction. I'm very aware that the backend is 
single-threaded and that you have no intention to change that. Neither do I.


Having the stack_base public is actually useful for another purpose 
also. It can allow you to make assertions that check if an abitrary 
pointer is 'on stack' or not. The MemoryContextContains() could be made 
safer too by just returning false when the given pointer is between the 
stack_base and the current stack_pointer. Perhaps that could be added to 
the patch?


Regards,
Thomas Hallgren



---(end of broadcast)---
TIP 1: 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


[PATCHES] Path to enable a module to change the stack_base_ptr

2005-10-02 Thread Thomas Hallgren
Here is a patch that will enable a module to change the stack_base_ptr 
temporarilly during a call. A background discussion can be found here:


http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg64586.html

Regards,
Thomas Hallgren

Index: src/backend/tcop/postgres.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.463
diff -u -r1.463 postgres.c
--- src/backend/tcop/postgres.c 26 Sep 2005 15:51:12 -  1.463
+++ src/backend/tcop/postgres.c 2 Oct 2005 07:16:14 -
@@ -2285,6 +2285,27 @@
}
 }
 
+/*
+ * set_stack_base_ptr: Assign a new stack base pointer
+ *
+ * Modules that call on the backend code from a thread different then the
+ * main thread can use this function to temporarilly swap the stack base
+ * pointer during the call.
+ *
+ * NOTE! This does in no way mean that the backend code is thread-safe. It
+ * cannot run multiple threads simultaniously. The caller must ensure that
+ * only one thread at a time is calling, that the call is encapsulated in
+ * a PG_TRY/PG_CATCH, and that signal handlers are installed to cater for
+ * signals in other threads then main.
+ */
+char*
+set_stack_base_ptr(char* new_base_ptr)
+{
+   char* old_base_ptr = stack_base_ptr;
+   stack_base_ptr = new_base_ptr;
+   return old_base_ptr;
+}
+
 /* GUC assign hook to update max_stack_depth_bytes from max_stack_depth */
 bool
 assign_max_stack_depth(int newval, bool doit, GucSource source)
Index: src/include/miscadmin.h
===
RCS file: /projects/cvsroot/pgsql/src/include/miscadmin.h,v
retrieving revision 1.179
diff -u -r1.179 miscadmin.h
--- src/include/miscadmin.h 17 Aug 2005 22:14:34 -  1.179
+++ src/include/miscadmin.h 2 Oct 2005 07:16:15 -
@@ -216,6 +216,7 @@
 
 /* in tcop/postgres.c */
 extern void check_stack_depth(void);
+extern char* set_stack_base_ptr(char* new_base_ptr);
 
 
 /*

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [PATCHES] Path to enable a module to change the stack_base_ptr

2005-10-02 Thread Thomas Hallgren

Tom Lane wrote:


Thomas Hallgren [EMAIL PROTECTED] writes:
 

Here is a patch that will enable a module to change the stack_base_ptr 
temporarilly during a call.
   



I'm not really in favor of this ... I think you are trying to make the
backend do something that will never work reliably.

If we were to try to support this, I'd prefer to just make
stack_base_ptr non static, rather than add overhead code.

regards, tom lane
 


Sure, that works for me.

Regards,
Thomas Hallgren



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

  http://www.postgresql.org/docs/faq


Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-05-11 Thread Thomas Hallgren
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
 

This patch will ensure that the hash table iteration performed by 
AtCommit_Portals is restarted when a portal is deleted.
 

 

I have applied the following patch.  I assume it is too risky for
backpatch to 8.0.X.
   

I don't think it's appropriate in HEAD either --- it doesn't solve the
problem, and it is an expensive way of not doing so :-(
 

It certanly solves my problem! And as for expensive? Why would it be? It 
just restarts the iteration everytime something is removed. The only 
thing that could make this patch consume CPU cycles is if there's a vast 
amount of Portals in the iteration that are not candidates for removal. 
I don't see that happen. Do you?

Regards,
Thomas Hallgren

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faq


Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-03-16 Thread Thomas Hallgren
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
 

I'm not sure what you mean. Earlier you rejected my bug-report on the 
iterator because you it was the callers responsability to deal with it 
(hence this patch). Are you now suggesting that we fix that bug instead?
   

Quite honestly, I dunno.  I agree that there's something lacking in this
stack of behaviors, but I don't think any of the solutions suggested so
far actually fix it ...
 

Ok, in that case, please allow this patch to go through. It will not 
cause any harm and until a better solution is architected, it does solve 
my immediate problem.

Regards,
Thomas Hallgren


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


Re: [PATCHES] Patch that deals with that AtCommit_Portals encounters

2005-03-15 Thread Thomas Hallgren
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
 

Thomas Hallgren wrote:
   

This patch will ensure that the hash table iteration performed by 
AtCommit_Portals is restarted when a portal is deleted.
 

 

I'll apply this to HEAD within 24 hours, barring any objections.
   

I don't believe that this actually fixes anything.
In particular, if portal A actually tries to reference portal B during
A's deletion, there is only a 50% chance that this prevents problems.
And since the hash table is traversed in hashcode order, you can't
really imagine that you know which one will be deleted first.
 

Tom,
as I explained to you in an earlier mail exchange, I indeed do cover the 
cases where B would be deleted before A by intercepting a callback in 
the portal. So this patch really solve a problem, at least for me. It it 
would be even better if accompanied by a patch allowing a 
destroy-callback to be (properly) registered with a Portal.

I asked you if that would be something to consider but got no reply. If 
you do think that's a good idea, please approve this patch for now and 
I'll deliver another for the callbacks shortly.

I think a correct fix would involve suppressing that reference in the
first place, rather than making ad-hoc alterations in the traversal
behavior.
 

I'm not sure what you mean. Earlier you rejected my bug-report on the 
iterator because you it was the callers responsability to deal with it 
(hence this patch). Are you now suggesting that we fix that bug instead?

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


[PATCHES] SPI function to investigate query semantics

2004-12-01 Thread Thomas Hallgren
Here's a patch containing the function SPI_iterate_query_roots(...). I'm 
optimistic so it's complete with documentation :-)

I think that this function is needed so that PL/lang authors like 
myself have a way to investigate the semantics of a prepared query. For 
me this is essential since I want to prevent that savepoint related 
statements are executed using normal SQL so that I can enforce the use 
of the methods stipulated by the connection interface.

I forsee that this might be of interest for other PL/lang authors as 
well. With this patch in place, it will be possible to do things like 
this (returning false is rejecting in this case since false terminates 
the iteration):

static bool rejectTransactionCommand(Query* query, void* clientData)
{
   return !(query-commandType == CMD_UTILITY 
   IsA(query-utilityStmt, TransactionStmt));
}
and then use that like:
   result = !SPI_iterate_query_roots(ePlan, rejectTransactionCommand, 
NULL);

The patch has no side effects since it's a pure addon.
Kind regards,
Thomas Hallgren
Index: doc/src/sgml/spi.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/spi.sgml,v
retrieving revision 1.35
diff -u -r1.35 spi.sgml
--- doc/src/sgml/spi.sgml   13 Sep 2004 20:05:25 -  1.35
+++ doc/src/sgml/spi.sgml   1 Dec 2004 19:05:28 -
@@ -1305,6 +1305,82 @@
 
 !-- *** --
 
+refentry id=spi-spi-iterate-query-roots
+ refmeta
+  refentrytitleSPI_iterate_query_roots/refentrytitle
+ /refmeta
+
+ refnamediv
+  refnameSPI_iterate_query_roots/refname
+  refpurposeinvestigate the semantics of a query/refpurpose
+ /refnamediv
+
+ indextermprimarySPI_iterate_query_roots/primary/indexterm
+
+ refsynopsisdiv
+synopsis
+bool SPI_iterate_query_roots(void * parameterplan/parameter, QueryVisitor 
parametercallback/parameter, void * parameterclientData/parameter)
+/synopsis
+ /refsynopsisdiv
+
+ refsect1
+  titleDescription/title
+
+  para
+The functionSPI_iterate_query_roots/function will invoke the
+symbolqueryVisitor/symbol callback once for each top level
+symbolQuery/symbol found in the supplied execution plan.
+The iteration is cancelled when a callback returns symbolfalse/symbol.
+If no callback returns symbolfalse/symbol, or if the plan is
+symbolNULL/symbol, the function returns symboltrue/symbol.
+  /para
+ /refsect1
+
+ refsect1
+  titleArguments/title
+
+  variablelist
+   varlistentry
+termliteralvoid * parameterplan/parameter/literal/term
+listitem
+ para
+  execution plan (returned by functionSPI_prepare/function)
+ /para
+/listitem
+   /varlistentry
+
+   varlistentry
+termliteralQueryVisitor 
parametercallback/parameter/literal/term
+listitem
+ para
+  the callback to invoke for each query found
+ /para
+/listitem
+   /varlistentry
+
+   varlistentry
+termliteralvoid * parameterclientData/parameter/literal/term
+listitem
+ para
+  user defined data that will be passed on to the callback
+ /para
+/listitem
+   /varlistentry
+  /variablelist
+ /refsect1
+
+ refsect1
+  titleReturn Value/title
+  para
+symboltrue/symbol when all callbacks returned symboltrue/symbol or
+symbolfalse/symbol when a callback returned symbolfalse/symbol and
+thus terminated the iteration.
+  /para
+ /refsect1
+/refentry
+
+!-- *** --
+
 refentry id=spi-spi-cursor-find
  refmeta
   refentrytitleSPI_cursor_find/refentrytitle
Index: src/backend/executor/spi.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/executor/spi.c,v
retrieving revision 1.132
diff -u -r1.132 spi.c
--- src/backend/executor/spi.c  16 Nov 2004 18:10:13 -  1.132
+++ src/backend/executor/spi.c  1 Dec 2004 19:05:29 -
@@ -1064,6 +1064,42 @@
return false;
 }
 
+/**
+ * Invokes the queryVisitor callback for each top level Query found in an
+ * execution plan. The iteration is cancelled when a callback returns
+ * false. If no callbacks returns false, or if the plan is NULL, this
+ * function returns true.
+ *
+ * Arguments:
+ * plan  An ExecutionPlan created by SPI_prepare
+ * queryVisitor  The callback function
+ * clientDataUser defined data that will be passed on to the callback
+ * Returns: true if the plan is NULL or if all callback invocation returns true
+ */
+bool
+SPI_iterate_query_roots(void *plan, QueryVisitor queryVisitor, void 
*clientData)
+{
+   _SPI_plan *spiplan = (_SPI_plan *) plan;
+
+   if (spiplan != NULL)
+   {
+   ListCell *query_list_list_item;
+   List *query_list_list = spiplan-qtlist;
+   foreach(query_list_list_item, query_list_list)
+   {
+   List *query_list = lfirst(query_list_list_item);
+   ListCell

Re: [PATCHES] SPI function to investigate query semantics

2004-12-01 Thread Thomas Hallgren
Tom Lane wrote:
We haven't got one that will work from inside arbitrary functions ---
DefineSavepoint and friends don't get it done by themselves, but
expect you to call CommitTransactionCommand/StartTransactionCommand,
and those functions tend to pull the rug out from under the executor.
(I seem to recall trying to do it that way in the first attempt on
plpgsql, and running into all kinds of memory management issues.)
The existing PLs use BeginInternalSubTransaction,
ReleaseCurrentSubTransaction, RollbackAndReleaseCurrentSubTransaction,
but these are subset implementations only suited for
exception-block-structured code.
 

Thanks. I'll check that out and try to figure out how to use it.
What are the future plans? For me it would work really well with 
something like

Savepoint SPI_savepoint(const char* name);
void SPI_releaseSavepoint(Savepoint sp);
void SPI_rollbackSavepoint(Savepoint sp);
The Savepoint structure could then hold information about call level 
etc. needed to ensure proper behaviour when nesting.

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


Re: [PATCHES] SPI function to investigate query semantics

2004-12-01 Thread Thomas Hallgren
Tom Lane wrote:
Looks pretty rejectish to me...
			regards, tom lane
 

Arrghh.
Forget my patch. It's not possible to set savepoints at all using SPI! 
Here I was, thinking that only begin/commit/rollback was rejected (I 
trusted the documentation and did not dive into the code).

A patch is needed for the documentation to clarify this :-)
So what *is* the appropriate way of  starting, releasing, and rolling 
back savepoints then?

Regards,
Thomas Hallgren

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


Re: [PATCHES] SPI function to investigate query semantics

2004-12-01 Thread Thomas Hallgren
Tom Lane wrote:
You do realize that SPI_execute will reject TransactionStmt anyway?
The example is therefore not very compelling ...
 

It won't reject savepoint related statements and that's what the example 
is for.

I want savepoints rejected unless they go through a specific method 
found on my connection object. From current discussions it seems similar 
functionality might be needed for other PL's.

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


Re: [PATCHES] SPI function to investigate query semantics

2004-12-01 Thread Thomas Hallgren
Tom Lane wrote:
Which you will do what with?  I'm not sure I see the point of treating
_SPI_plan as an opaque type while assuming you know what to do with a
Query.
 

What's different in that compared to the methods that use a Snapshot? 
The fact that I provided documentation? If so, ok remove the docs.

Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] SQL:2003 keyword additions

2004-11-24 Thread Thomas Hallgren
Peter Eisentraut wrote:
... Therefore, adding more reserved key 
words than necessary does not achieve anything in terms of SQL 
conformance.

One might argue that it will prevent current PostgreSQL users from 
unintentionally using those keywords and thereby obtain 2 goals:

1. The SQL code will be more portable since other databases may 
recognize the keywords.
2. Migration to a future PostgreSQL version where the relevant commands 
has been implemented will be easier.

Regards,
Thomas Hallgren
---(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


Re: [PATCHES] pgxs patch for win32 (v2)

2004-11-18 Thread Thomas Hallgren
Tom Lane wrote:
Fabien COELHO [EMAIL PROTECTED] writes:
please find attached a very small patch which:
 - install win32 headers on make install
 - install libpostgres.a library under win32 by default (MAKE_DLL=true)
 - fix CPPFLAGS under win32 to look for these added header under PGXS

Applied.
Works like a charm.
Thanks,
Thomas Hallgren
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html


Re: [PATCHES] pgxs under Win32 for PL/Java

2004-11-07 Thread Thomas Hallgren
Fabien COELHO wrote:
I have no mean to test that on a win32 machine. Could you do it?
 

Sure, I'll test it sometime tomorrow or the day after. I'll get back to you.
I'm wondering whether the MAKE_DLL fix should also be done under cygwin.
Any opinion?
 

I can test cygwin too. But just out of curiosity; why would anyone want 
to use cygwin with 8.0?

Regards,
Thomas Hallgren

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


Re: [PATCHES] [HACKERS] CVS should die

2004-11-04 Thread Thomas Hallgren
Tom,
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is.  It's not obvious how
to do better.)
I've been working with a few SCM's and IMHO only one of them really 
handles this really well. That's ClearCase. I'm well aware that 
ClearCase is not an option but I though it could still be interesting to 
know how this can be managed when done right.

In ClearCase everything (both files and directories) are elements. A 
directory is a version of an element and it contains versions of other 
elements. It's not very different from Unix and I-nodes although 
everything is of course versioned.

Subversion claims they handle moves pretty well. When I checked it out, 
it turns out that a move is a copy (versions and all) followed by a 
delete, thus maintaining version history at both locations. I'd 
recommend anyone who think CVS is insufficient due to file moves to 
investigate subversion.

Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [PATCHES] [HACKERS] bug in GUC

2004-06-27 Thread Thomas Hallgren
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
... We don't want to elog(ERROR) partway through that
process.  Especially not in the postmaster, where elog(ERROR) is
tantamount to elog(FATAL).  (But of course the postmaster shouldn't ever
run out of memory anyway...)
It's possible that this should all be rethought, but it would be a much
more wide-ranging change than we've been discussing.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Here's a patch dealing with the unchecked mallocs and strdups in guc.c. 
Rather than mixing in palloc and TopMemoryContext into the code (would 
be rather messy given that most allocs actually falls into the category 
of not always being permitted to do elog(ERROR/FATAL)), I added a couple 
of simple static functions for guc_alloc, guc_realloc, and guc_strdup 
that are used throughout the guc.c file.

Kind regards,
Thomas Hallgren
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.211
diff -u -r1.211 guc.c
--- src/backend/utils/misc/guc.c11 Jun 2004 03:54:54 -  1.211
+++ src/backend/utils/misc/guc.c27 Jun 2004 18:43:18 -
@@ -1786,6 +1786,32 @@
 static void ReportGUCOption(struct config_generic * record);
 static char *_ShowOption(struct config_generic * record);
 
+static void* check_alloc(int elevel, void* data)
+{
+   if(data == NULL)
+   {
+   ereport(elevel,
+   (errcode(ERRCODE_OUT_OF_MEMORY),
+errmsg(out of memory)));
+   }
+   return data;
+}
+
+static void* guc_alloc(int elevel, size_t size)
+{
+   return check_alloc(elevel, malloc(size));
+}
+
+static void* guc_realloc(int elevel, void* old, size_t size)
+{
+   return check_alloc(elevel, realloc(old, size));
+}
+
+static char* guc_strdup(int elevel, const char* src)
+{
+   return (char*)check_alloc(elevel, strdup(src));
+}
+
 struct config_generic** get_guc_variables()
 {
return guc_variables;
@@ -1842,11 +1868,7 @@
size_vars = num_vars + num_vars / 4;
 
guc_vars = (struct config_generic **)
-   malloc(size_vars * sizeof(struct config_generic *));
-   if (!guc_vars)
-   ereport(FATAL,
-   (errcode(ERRCODE_OUT_OF_MEMORY),
-errmsg(out of memory)));
+   guc_alloc(FATAL, size_vars * sizeof(struct config_generic *));
 
num_vars = 0;
 
@@ -1905,35 +1927,41 @@
  * Add a new GUC variable to the list of known variables. The
  * list is expanded if needed.
  */
-static void
-add_guc_variable(struct config_generic *var)
+static bool
+add_guc_variable(int elevel, struct config_generic *var)
 {
if(num_guc_variables + 1 = size_guc_variables)
{
/* Increase the vector with 20%
 */
-   int size_vars = size_guc_variables + size_guc_variables / 4;
+   int size_vars = size_guc_variables + size_guc_variables / 5;
struct config_generic** guc_vars;
 
if(size_vars == 0)
+   {
size_vars = 100;
-
-   guc_vars = (struct config_generic**)
-   malloc(size_vars * sizeof(struct 
config_generic*));
-
-   if (guc_variables != NULL)
+   guc_vars = (struct config_generic**)
+   guc_alloc(elevel, size_vars * sizeof(struct 
config_generic*));
+   }
+   else
{
-   memcpy(guc_vars, guc_variables,
-   num_guc_variables * sizeof(struct 
config_generic*));
-   free(guc_variables);
+   guc_vars = (struct config_generic**)
+   guc_realloc(elevel, guc_variables, size_vars * 
sizeof(struct config_generic*));
}
 
-   guc_variables = guc_vars;
+   if(guc_vars == NULL)
+   /*
+* Out of memory
+*/
+   return false;
+
size_guc_variables = size_vars;
+   guc_variables = guc_vars;
}
guc_variables[num_guc_variables++] = var;
qsort((void*) guc_variables, num_guc_variables,
sizeof(struct config_generic*), guc_var_compare);
+   return true;
 }
 
 /*
@@ -1941,15 +1969,22 @@
  * to a valid custom variable class at this point.
  */
 static struct config_string*
-add_placeholder_variable(const char *name)
+add_placeholder_variable(int elevel, const char *name)
 {
size_t sz = sizeof(struct config_string) + sizeof(char

Re: [PATCHES] [HACKERS] dynamic_library_path on Win32

2004-06-07 Thread Thomas Hallgren
Attached is a patch that takes care of the PATHSEP issue. I made a more
extensive change then what was suggested. I found the file path.c that
contained a lot of Unix/Windows agnostic functions so I added a function
there instead and removed the PATHSEP declaration in exec.c altogether. All
to keep things from scattering all over the code.

I also took the liberty of changing the name of the functions
first_path_sep and last_path_sep. Where I come from (and I'm apparently
not alone given the former macro name PATHSEP), they should be called
first_dir_sep and last_dir_sep. The new function I introduced, that
actually finds path separators, is now the first_path_sep. The patch
contains changes on all affected places of course.

I also changed the documentation on dynamic_library_path to reflect the
chagnes.

Kind regards,

Thomas Hallgren


Bruce Momjian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]

 I can do it but will be a few days until I get to it.

 --
-

 Tom Lane wrote:
  Andrew Dunstan [EMAIL PROTECTED] writes:
   You've found a bug. Clearly we need to adjust the parsing of
   dynamic_library_path and probably preload_libraries for Win32.
 
  Yup.  Using PATHSEP sounded reasonable to me.  Any volunteer to fix
  this?  (Don't forget to patch the docs for these variables, too.)
 
  regards, tom lane
 
  ---(end of broadcast)---
  TIP 4: Don't 'kill -9' the postmaster
 

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

Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.265
diff -u -r1.265 runtime.sgml
--- doc/src/sgml/runtime.sgml   26 May 2004 18:51:43 -  1.265
+++ doc/src/sgml/runtime.sgml   7 Jun 2004 21:48:09 -
@@ -2617,8 +2617,9 @@
/para
 
para
-The value for varnamedynamic_library_path/varname has to be a 
colon-separated
-list of absolute directory names. If a directory name starts
+The value for varnamedynamic_library_path/varname has to be a
+list of absolute directory names separated by colon or, in windows
+environments with semi-colon. If a directory name starts
 with the special value literal$libdir/literal, the
 compiled-in productnamePostgreSQL/productname package
 library directory is substituted. This where the modules
@@ -2628,6 +2629,10 @@
 example:
 programlisting
 dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
+/programlisting
+or, in a windows environment:
+programlisting
+dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
 /programlisting
/para
 
Index: src/backend/commands/dbcommands.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/dbcommands.c,v
retrieving revision 1.134
diff -u -r1.134 dbcommands.c
--- src/backend/commands/dbcommands.c   26 May 2004 13:56:45 -  1.134
+++ src/backend/commands/dbcommands.c   7 Jun 2004 21:48:09 -
@@ -941,7 +941,7 @@
if (dbpath == NULL || dbpath[0] == '\0')
return NULL;
 
-   if (first_path_separator(dbpath))
+   if (first_dir_separator(dbpath))
{
if (!is_absolute_path(dbpath))
ereport(ERROR,
Index: src/backend/utils/fmgr/dfmgr.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/fmgr/dfmgr.c,v
retrieving revision 1.73
diff -u -r1.73 dfmgr.c
--- src/backend/utils/fmgr/dfmgr.c  26 May 2004 18:35:39 -  1.73
+++ src/backend/utils/fmgr/dfmgr.c  7 Jun 2004 21:48:10 -
@@ -288,7 +288,7 @@
 
AssertArg(name);
 
-   have_slash = (first_path_separator(name) != NULL);
+   have_slash = (first_dir_separator(name) != NULL);
 
if (!have_slash)
{
@@ -343,7 +343,7 @@
if (name[0] != '$')
return pstrdup(name);
 
-   if ((sep_ptr = first_path_separator(name)) == NULL)
+   if ((sep_ptr = first_dir_separator(name)) == NULL)
sep_ptr = name + strlen(name);

if (strlen($libdir) != sep_ptr - name ||
@@ -374,7 +374,7 @@
size_t  baselen;
 
AssertArg(basename != NULL);
-   AssertArg(first_path_separator(basename) == NULL);
+   AssertArg(first_dir_separator(basename

[PATCHES] Link errors on win32

2004-05-28 Thread Thomas Hallgren
After patching postmaster.c (see previous post) I'm unable to link on win32
(mingw). I get the following errors:

gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declaratio
ns -L../../src/port   -o postgres.exe -Wl,--base-file,postgres.base
postgres.exp access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o
parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o
libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o
postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o
tcop/SUBSYS.o utils/SUBSYS.o
../../src/timezone/SUBSYS.o -lz -lreadline -lwsock32 -lm  -lpgport -lws2_32
executor/SUBSYS.o(.text+0x10417):nodeSeqscan.c: undefined reference to `nth'
executor/SUBSYS.o(.text+0x134a6):nodeSubqueryscan.c: undefined reference to
`nth'
port/SUBSYS.o(.text+0x3be):pg_sema.c: undefined reference to `pqkill'
storage/SUBSYS.o(.text+0x4363):fd.c: undefined reference to
`is_absolute_path'
storage/SUBSYS.o(.text+0x7fc5):pmsignal.c: undefined reference to `pqkill'
storage/SUBSYS.o(.text+0xd129):proc.c: undefined reference to `pqkill'
utils/SUBSYS.o(.text+0x24f58):not_in.c: undefined reference to `llast'
utils/SUBSYS.o(.text+0x24f70):not_in.c: undefined reference to `ltruncate'
utils/SUBSYS.o(.text+0x6c2cc):fmgr.c: undefined reference to `nth'
make[2]: *** [postgres] Error 1
make[2]: Leaving directory `/ws/pgsql/src/backend'

Regards,

Thomas Hallgren



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Link errors on win32

2004-05-28 Thread Thomas Hallgren
Magnus Hagander [EMAIL PROTECTED] writes:
 This looks like it's missing stuff from Bruces move from
 backend/port/win32 to port/kill.c of the kill signal. Are you sure you
 pulled a new version of the port directory as well? And did you do a
 make clean?

I did a make clean. But it encountered an error and terminated prematurely
and I missed it...

make[2]: Entering directory `/ws/pgsql/contrib/earthdistance'
make[2]: *** No rule to make target `clean'.  Stop.
make[2]: Leaving directory `/ws/pgsql/contrib/earthdistance'
make[1]: *** [clean] Error 2
make[1]: Leaving directory `/ws/pgsql/contrib'
make: *** [clean] Error 2

Anyway, I removed everything and downloaded a new fresh version, reapplied
my patch for postmaster.c, and recompiled. Everything links ok now.

Thanks,

Thomas Hallgren



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

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


Re: [PATCHES] Link errors on win32

2004-05-28 Thread Thomas Hallgren
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
 

I did a make clean. But it encountered an error and terminated prematurely
and I missed it...
   

 

make[2]: Entering directory `/ws/pgsql/contrib/earthdistance'
make[2]: *** No rule to make target `clean'.  Stop.
make[2]: Leaving directory `/ws/pgsql/contrib/earthdistance'
make[1]: *** [clean] Error 2
make[1]: Leaving directory `/ws/pgsql/contrib'
make: *** [clean] Error 2
   

You must have a broken version of make.  There certainly is a 'clean'
rule in that subdirectory, and it works for everyone else.
			regards, tom lane
 

Ah yes. Actually, this is the error I got once I manually created the 
earthdistance directory in order for the clean to proceed. The first 
time it failed, it was missing altogether.

- thomas

---(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] Link errors on win32

2004-05-28 Thread Thomas Hallgren
Bruce Momjian wrote:
Thomas Hallgren wrote:
 

Magnus Hagander [EMAIL PROTECTED] writes:
   

This looks like it's missing stuff from Bruces move from
backend/port/win32 to port/kill.c of the kill signal. Are you sure you
pulled a new version of the port directory as well? And did you do a
make clean?
 

I did a make clean. But it encountered an error and terminated prematurely
and I missed it...
make[2]: Entering directory `/ws/pgsql/contrib/earthdistance'
make[2]: *** No rule to make target `clean'.  Stop.
make[2]: Leaving directory `/ws/pgsql/contrib/earthdistance'
make[1]: *** [clean] Error 2
make[1]: Leaving directory `/ws/pgsql/contrib'
make: *** [clean] Error 2
Anyway, I removed everything and downloaded a new fresh version, reapplied
my patch for postmaster.c, and recompiled. Everything links ok now.
   

I did a gmake clean and gmake distclean from the top of CVS and it
worked fine for me.
 

I've encountered this before. You have to do a make that fails first, 
then a make clean. On occation, the latter will fail. I'm not shure 
exactly when or why this happens. My theory is that the make clean 
assumes that some directories have been created when in fact they have 
not since the original make failed prematurely.

- thomas

---(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] Configuration parameters for plugin modules

2004-05-19 Thread Thomas Hallgren
Same patch as before but I added a small change to the gram.y enabling 
SET command to use qualified names.

- thomas
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.263
diff -u -r1.263 runtime.sgml
--- doc/src/sgml/runtime.sgml   29 Apr 2004 04:37:09 -  1.263
+++ doc/src/sgml/runtime.sgml   19 May 2004 21:01:40 -
@@ -2924,6 +2924,60 @@
 /variablelist
/sect2
 
+   sect2 id=runtime-config-custom
+titleCustomized Options/title
+
+para
+ The following was designed to allow options not normally known to
+ productnamePostgreSQL/productname to be declared in the posgresql.conf
+ file and/or manipulated using the commandSET/command in a controlled
+ manner so that add-on modules to the postgres proper (such as lanugage
+ mappings for triggers and functions) can be configured in a unified way.
+/para
+
+variablelist
+
+ varlistentry id=guc-custom_variable_classes 
xreflabel=custom_variable_classes
+  termvarnamecustom_variable_classes/varname (typestring/type)/term
+  indextermprimarycustom_variable_classes//
+  listitem
+   para
+This variable specifies one or several classes to be used for custom
+variables. A custom variable is a variable not normally known to
+the productnamePostgreSQL/productname proper but used by some add
+on module.
+   /para
+
+   para
+Aribtrary variables can be defined for each class specified here. Those
+variables will be treated as placeholders and have no meaning until the
+module that defines them is loaded. When a module for a specific class is
+loaded, it will add the proper variable definitions for the class
+associated with it, convert any placeholder values according to those
+definitions, and issue warnings for any placeholders that then remains.
+   /para
+   
+   para
+Here is an example what custom variables might look like:
+
+programlisting
+custom_variable_class = 'plr,pljava'
+plr.foo = '/usr/lib/R'
+pljava.baz = 1
+plruby.var = true== this one would generate an error
+/programlisting
+   /para
+
+   para
+This option can only be set at server start or in the
+filenamepostgresql.conf/filename configuration file.
+   /para
+
+  /listitem
+ /varlistentry
+/variablelist
+   /sect2
+
sect2 id=runtime-config-developer
 titleDeveloper Options/title
 
Index: src/backend/parser/gram.y
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.454
diff -u -r2.454 gram.y
--- src/backend/parser/gram.y   10 May 2004 22:44:45 -  2.454
+++ src/backend/parser/gram.y   19 May 2004 21:01:43 -
@@ -309,7 +309,7 @@
 %type strSconst comment_text
 %type strUserId opt_boolean ColId_or_Sconst
 %type list   var_list var_list_or_default
-%type strColId ColLabel type_name param_name
+%type strColId ColLabel var_name type_name param_name
 %type node   var_value zone_value
 
 %type keyword unreserved_keyword func_name_keyword
@@ -857,14 +857,14 @@
}
;
 
-set_rest:  ColId TO var_list_or_default
+set_rest:  var_name TO var_list_or_default
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-name = $1;
n-args = $3;
$$ = n;
}
-   | ColId '=' var_list_or_default
+   | var_name '=' var_list_or_default
{
VariableSetStmt *n = makeNode(VariableSetStmt);
n-name = $1;
@@ -914,6 +914,19 @@
n-name = session_authorization;
n-args = NIL;
$$ = n;
+   }
+   ;
+
+var_name:
+   ColId  
 { $$ = $1; }
+   | var_name '.' ColId
+   {
+   int qLen = strlen($1);
+   char* qualName = palloc(qLen + strlen($3) + 2);
+   strcpy(qualName, $1);
+   qualName[qLen] = '.';
+   strcpy(qualName + qLen + 1, $3);
+   $$ = qualName;
}
;
 
Index: 

[PATCHES] Configuration parameters for plugin modules

2004-05-09 Thread Thomas Hallgren
Posted this patch 2 weeks ago. Since then new changes has been made to 
guc.c making it hard to apply. Here's a new fresh version intended for 
current cvs head.

In short:
The patch adresses the TODO list item Allow external interfaces to 
extend the GUC variable set.

Plugin modules like the pllang modules needs a way to declare 
configuration parameters. The postmaster has no knowledge of such 
modules when it reads the postgresql.conf file. Rather than allowing 
totally unknown configuration parameters, the concept of a variable 
class is introduced. Variables that belongs to a declared classes will 
create a placeholder value of string type and will not generate an 
error. When a module is loaded, it will declare variables for such a 
class and make those variables consume any placeholders that has been 
defined. Finally, the module will generate warnings for unrecognized 
placeholders defined for its class.

More detail:
The design is outlined after the suggestions made by Tom Lane and Joe 
Conway in this thread:

http://archives.postgresql.org/pgsql-hackers/2004-02/msg00229.php

A new string variable 'custom_variable_classes' is introduced. This 
variable is a comma separated string of identifiers. Each identifier 
denots a 'class' that will allow its members to be added without error. 
This variable must be defined in postmaster.conf.

The lexer (guc_file.l) is changed so that it can accept a qualified name 
in the form ID.ID as the name of a variable. I also changed so that 
the 'custom_variable_classes', if found, is added first of all variables 
in order to remove the order of declaration issue.

The guc_variables table is made more dynamic. It is originally created 
with 20% slack and can grow dynamically. A capacity is introduced to 
avoid resizing every time a new variable is added. guc_variables and
num_guc_variables becomes static (hidden).

The GucInfoMain now uses the new function get_guc_variables() and 
GetNumConfigOptions  instead or using the guc_variables directly.

The find_option() function, when passed a missing name, will check if 
the name is qualified. If the name is qualified and if the qualifier 
denotes a class included in the 'custom_variable_classes', a placeholder 
variable will be created. Such a placeholder will not participate in a 
list operation but will otherwise function as a normal string variable.

DefinetypeGucVariable() functions will be added, one for each variable 
type. They are inteded to be used by add-on modules like the pllang 
mappings. Example:

extern void DefineCustomBoolVariable(
const char* name,
const char* short_desc,
const char* long_desc,
bool* valueAddr,
GucContext context,
GucBoolAssignHook assign_hook,
GucShowHook show_hook);
(I created typedefs for the assign-hook and show-hook functions). A call 
to these functions will define a new GUC-variable. If a placeholder 
exists it will be replaced but it's value will be used in place of the 
default value. The valueAddr is assumed ot point at a default value when 
the define function is called. The only constraint that is imposed on a 
Custom variable is that its name is qualified.

Finally, a function:

void EmittWarningsOnPlacholders(const char* className)

was added. This function should be called when a module has completed 
its variable definitions. At that time, no placeholders should remain 
for the class that the module uses. If they do, elog(INFO, ...) messages 
will be issued to inform the user that unrecognized variables are present.

Kind regards,

Thomas Hallgren
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.263
diff -u -r1.263 runtime.sgml
--- doc/src/sgml/runtime.sgml   29 Apr 2004 04:37:09 -  1.263
+++ doc/src/sgml/runtime.sgml   9 May 2004 20:37:42 -
@@ -2924,6 +2924,60 @@
 /variablelist
/sect2
 
+   sect2 id=runtime-config-custom
+titleCustomized Options/title
+
+para
+ The following was designed to allow options not normally known to
+ productnamePostgreSQL/productname to be declared in the posgresql.conf
+ file and/or manipulated using the commandSET/command in a controlled
+ manner so that add-on modules to the postgres proper (such as lanugage
+ mappings for triggers and functions) can be configured in a unified way.
+/para
+
+variablelist
+
+ varlistentry id=guc-custom_variable_classes 
xreflabel=custom_variable_classes
+  termvarnamecustom_variable_classes/varname (typestring/type)/term
+  indextermprimarycustom_variable_classes//
+  listitem
+   para
+This variable specifies one or several classes to be used for custom
+variables. A custom variable is a variable not normally known to
+the productnamePostgreSQL/productname proper but used by some add
+on module

[PATCHES] Patch for Makefile.shlib

2004-05-07 Thread Thomas Hallgren
Here's a patch that will allow external modules like pllang to set
additional flags for the dlltool and dllwrap commands. More info here:

http://archives.postgresql.org/pgsql-hackers/2004-05/msg00350.php

regards,

Thomas Hallgren
-- 
A ship in harbor is safe, but that is not what ships are built for.
- John A. Shedd Index: src/Makefile.shlib
===
RCS file: /projects/cvsroot/pgsql-server/src/Makefile.shlib,v
retrieving revision 1.74
diff -u -r1.74 Makefile.shlib
--- src/Makefile.shlib  1 Dec 2003 22:23:06 -   1.74
+++ src/Makefile.shlib  7 May 2004 14:17:56 -
@@ -26,6 +26,12 @@
 #   additional stuff to put in its link command
 # (If you want a patchlevel, include it in SO_MINOR_VERSION, e.g., 6.2.)
 #
+# Optional flags when building DLL's (only applicable to win32 and cygwin
+# platforms).
+# DLLTOOL_DEFFLAGS  Additional flags when creating the dll .def file
+# DLLTOOL_LIBFLAGS  Additional flags when creating the libmodule.a file
+# DLLWRAP_FLAGS Additional flags to dllwrap
+#
 # The module Makefile must also include
 # $(top_builddir)/src/Makefile.global before including this file.
 # (Makefile.global sets PORTNAME and other needed symbols.)
@@ -284,9 +290,9 @@
 
 # win32 case
 $(shlib) lib$(NAME).a: $(OBJS)
-   $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS)
-   $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) 
$(SHLIB_LINK)
-   $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a
+   $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS)
+   $(DLLWRAP) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def 
$(OBJS) $(SHLIB_LINK)
+   $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def 
--output-lib lib$(NAME).a
 
 endif # PORTNAME == win32
 
@@ -294,9 +300,9 @@
 
 # Cygwin case
 $(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT)
-   $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS)
-   $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) $(DLLINIT) 
$(SHLIB_LINK)
-   $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a
+   $(DLLTOOL) --export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS)
+   $(DLLWRAP) -o $(shlib) --dllname $(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def 
$(OBJS) $(DLLINIT) $(SHLIB_LINK)
+   $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(NAME).def 
--output-lib lib$(NAME).a
 
 $(DLLINIT): $(DLLINIT:%.o=%.c)
$(MAKE) -C $(@D) $(@F)


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


Re: [PATCHES] Run-as-admin warning for win32

2004-05-04 Thread Thomas Hallgren
 2. Are you sure Powerusers is such a good idea? It's the default for
 all non-admin users. When Postgres becomes a service, it's going to be
 relatively easy to configure it to run as a low-priv user. Until then,
 however, isn't it too difficult for admins to set up the system for it
 to run as a different user?

Found this document on the net. It gives you a good overview of what
different levels of users can and cannot do. I think the heading What can a
power user do that a user can't contains a couple of very good reasons to
prevent that PostgreSQL runs with Powerusers rights.

http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1da8cbc0/_Toc42414596

Exerpt:

Unfortunately, these permissions are also the same permissions that allow
power users to:
  · Introduce Trojan horses that, if executed by administrators or
other users, can compromise system and data security
  · Make system-wide operating system and application changes
that affect other users of the system

Kind regards,

Thomas Hallgren



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

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


Re: [PATCHES] Run-as-admin warning for win32

2004-05-04 Thread Thomas Hallgren
Sorry. That link was internal to the document. This one should work.

http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1da8cbc0/SecDefs2003.doc

Regards,

Thomas Hallgren

Shachar Shemesh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 Thomas Hallgren wrote:


http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1d
a8cbc0/_Toc42414596
 
 
 Link does not work.

 Exerpt:
 
 Unfortunately, these permissions are also the same permissions that allow
 power users to:
   ? Introduce Trojan horses that, if executed by administrators or
 other users, can compromise system and data security
   ? Make system-wide operating system and application changes
 that affect other users of the system
 
 Kind regards,
 
 Thomas Hallgren
 
 
 rant
 That pathetic thing called Windows security is getting to me. It is
 close to impossible to create a user, and once created, this user will
 not be capable of actually doing anything.

 Very flexible, very granular permissions system result in making it
 impossible for someone, us in this case, to find out whether we are
 over-priveleged.

 Well meaning, but horrible system, with even more horrible results.
 /rant

 Shachar

 -- 
 Shachar Shemesh
 Lingnu Open Source Consulting
 http://www.lingnu.com/


 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster




---(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] Some new SPI functions

2004-02-15 Thread Thomas Hallgren
 Who did you think would do it?

 regards, tom lane

you :-)

Seriously, I didn't give it much though. This is undoubtedly the best way
although some projects handle it differently. A  tech-writer perhaps, with
better writing skills then programmers in general. But people like that are
probabaly not too common in the open source field. If you don't do like
JBoss and charge for the docs (I'm *not* in favor of that).

Anyway, here's the patch again. This time with documentation.

Index: doc/src/sgml/spi.sgml
===
retrieving revision 1.30
diff -u -r1.30 spi.sgml
--- doc/src/sgml/spi.sgml 1 Dec 2003 22:07:57 - 1.30
+++ doc/src/sgml/spi.sgml 15 Feb 2004 13:47:13 -
@@ -573,6 +573,190 @@

 !-- *** --

+refentry id=spi-spi-getargcount
+ refmeta
+  refentrytitleSPI_getargcount/refentrytitle
+ /refmeta
+
+ refnamediv
+  refnameSPI_getargcount/refname
+  refpurposereturns the number of arguments needed when executing a plan
+  prepared by functionSPI_prepare/function/refpurpose
+ /refnamediv
+
+ indextermprimarySPI_getargcount/primary/indexterm
+
+ refsynopsisdiv
+synopsis
+int SPI_getargcount(void * parameterplan/parameter)
+/synopsis
+ /refsynopsisdiv
+
+ refsect1
+  titleDescription/title
+
+  para
+   functionSPI_getargcount/function returns the number of arguments
needed
+   when executing a plan prepared by functionSPI_prepare/function.
+  /para
+ /refsect1
+
+ refsect1
+  titleArguments/title
+
+  variablelist
+   varlistentry
+termliteralvoid * parameterplan/parameter/literal/term
+listitem
+ para
+  execution plan (returned by functionSPI_prepare/function)
+ /para
+/listitem
+   /varlistentry
+  /variablelist
+ /refsect1
+
+ refsect1
+  titleReturn Value/title
+  para
+The expected argument count for the parameterplan/parameter or
+symbolSPI_ERROR_ARGUMENT/symbol if the parameterplan
+/parameter is symbolNULL/symbol
+  /para
+ /refsect1
+/refentry
+
+!-- *** --
+
+refentry id=spi-spi-getargtypeid
+ refmeta
+  refentrytitleSPI_getargtypeid/refentrytitle
+ /refmeta
+
+ refnamediv
+  refnameSPI_getargtypeid/refname
+  refpurposereturns the expected typeid for the specified argument when
+  executing a plan prepared by
functionSPI_prepare/function/refpurpose
+ /refnamediv
+
+ indextermprimarySPI_getargtypeid/primary/indexterm
+
+ refsynopsisdiv
+synopsis
+Oid SPI_getargtypeid(void * parameterplan/parameter, int
parameterargIndex/parameter)
+/synopsis
+ /refsynopsisdiv
+
+ refsect1
+  titleDescription/title
+
+  para
+   functionSPI_getargtypeid/function returns the Oid representing the
type
+   id for argument at parameterargIndex/parameter in a plan prepared by
+   functionSPI_prepare/function. First argument is at index zero.
+  /para
+ /refsect1
+
+ refsect1
+  titleArguments/title
+
+  variablelist
+   varlistentry
+termliteralvoid * parameterplan/parameter/literal/term
+listitem
+ para
+  execution plan (returned by functionSPI_prepare/function)
+ /para
+/listitem
+   /varlistentry
+
+   varlistentry
+termliteralint parameterargIndex/parameter/literal/term
+listitem
+ para
+  zero based index of the argument
+ /para
+/listitem
+   /varlistentry
+  /variablelist
+ /refsect1
+
+ refsect1
+  titleReturn Value/title
+  para
+The type id of the argument at the given index or symbol
+SPI_ERROR_ARGUMENT/symbol if the parameterplan/parameter is
+symbolNULL/symbol or parameterargIndex/parameter is less than 0
or
+not less than the number of arguments declared for the parameterplan
+/parameter
+  /para
+ /refsect1
+/refentry
+
+!-- *** --
+
+refentry id=spi-spi-is_cursor_plan
+ refmeta
+  refentrytitleSPI_is_cursor_plan/refentrytitle
+ /refmeta
+
+ refnamediv
+  refnameSPI_is_cursor_plan/refname
+  refpurposereturns symboltrue/symbol if a plan
+  prepared by functionSPI_prepare/function can be passed
+  as an argument to functionSPI_cursor_open/function/refpurpose
+ /refnamediv
+
+ indextermprimarySPI_is_cursor_plan/primary/indexterm
+
+ refsynopsisdiv
+synopsis
+bool SPI_is_cursor_plan(void * parameterplan/parameter)
+/synopsis
+ /refsynopsisdiv
+
+ refsect1
+  titleDescription/title
+
+  para
+   functionSPI_is_cursor_plan/function returns symboltrue/symbol
+   if a plan prepared by functionSPI_prepare/function can be passed
+   as an argument to functionSPI_cursor_open/function and symbol
+   false/symbol if that is not the case. The criteria is that the
+   parameterplan/parameter represents one single command and that this
+   command is a commandSELECT/command without an
commandINTO/command
+   clause.
+  /para
+ /refsect1
+
+ refsect1
+  titleArguments/title
+
+  variablelist
+   varlistentry
+termliteralvoid * parameterplan/parameter/literal/term
+listitem
+ para
+  execution plan (returned 

Re: [PATCHES] Some new SPI functions

2004-02-14 Thread Thomas Hallgren
Sure, I'll provide some docs. Just wasn't aware that patchers did that.

- thomas

- Original Message - 
From: Bruce Momjian [EMAIL PROTECTED]
To: Thomas Hallgren [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, February 13, 2004 06:12
Subject: Re: [PATCHES] Some new SPI functions



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