Re: [PATCHES] Path to enable a module to change the stack_base_ptr
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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