Re: [PATCHES] temp patch for win32 readdir issue
Bruce Momjian <[EMAIL PROTECTED]> writes: > We will document this on the win32 TODO list and remove this patch once > MinGW is fixed. IIRC, Tom and I both suggested that there is no need to clutter the source tree with a temporary workaround for a platform that hasn't even seen a stable release yet. Or did I miss something...? -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] psql documentation one liner
Peter Eisentraut wrote: > Gavin Sherry wrote: > > This just clears up one aspect of variable handling in psql. > > [ "variable names are case-sensitive" ] > > I honestly wonder why this is suddenly of so much interest. I hope no > one is going to question the fact that the command names are > case-sensitive. Do we need a note abou that, too? Patch applied. I just added a sentence, rather than an new paragraph. I think the confusion is because SQL variable names aren't case senstitive, so it is a little confusing. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.105 diff -c -c -r1.105 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 12 Feb 2004 19:58:16 - 1.105 --- doc/src/sgml/ref/psql-ref.sgml 13 Feb 2004 05:08:46 - *** *** 1613,1618 --- 1613,1619 underscores. See the section below for details. + Variable names are case-sensitive. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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 pl 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] ANALYZE patch for review
Applied by Tom. Thanks. --- Mark Cave-Ayland wrote: > Hi Tom, > > > -Original Message- > > From: Tom Lane [mailto:[EMAIL PROTECTED] > > Sent: 02 February 2004 16:54 > > To: Mark Cave-Ayland > > Cc: [EMAIL PROTECTED] > > Subject: Re: [PATCHES] ANALYZE patch for review > > > > > > "Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > > > So I'd like to propose a slightly different solution. I think that > > > examine_attribute() should return a pointer to a custom structure > > > containing any information that needs to be passed to the datatype > > > specific routine (not the entire VacAttrStats structure), > > or NULL if > > > the column should not be analyzed. > > > > Just a void* you mean? Sure, we could do that, although it > > might result in some duplicated effort. Another possibility > > is that analyze.c goes ahead and creates a VacAttrStats > > struct (including a void* extension pointer that it > > initializes to NULL) and then passes the struct to > > examine_attribute, which returns a bool and optionally > > modifies fields in the VacAttrStats struct --- in particular > > the requested-row-count and extension pointer. If false is > > returned then analyze.c just throws away the VacAttrStats > > struct instead of including it in its to-do list. > > Yup indeed. Please find enclosed the latest version of the analyze patch > taking into account all the things we have discussed in the thread. It > feels a lot cleaner than the other - the advantage of having > analyze_rel() create the VacAttrStats structure is that you can put some > vaguely sensible defaults in the user-defined function so it shouldn't > bomb too badly if someone gets it wrong, plus the attribute and type > information can be fed in automagically. > > This rewrite has the benefit that it gets rid of the duplication of > routines having to get their own copies of the attribute and type rows > based on attnum, and also the (void *) pointer gives a clear abstraction > of the data required for the pg_statistic table entry and those that are > used by the current default routine. I also altered the > examine_attribute() to allow the user-defined function to check > attstattarget for the column manually (in case they want to do something > special with minus or zero values), and also as discussed the internal > stats routine is called directly without requiring an entry in the > catalog. > > > >> If you suppose that the "major" field is the upper bits of > > >> the statistics ID value, then this is just a slightly > > >> different way of thinking about the range-based allocation > > >> method I suggested before. > > > > > I was thinking perhaps in terms of an extra staowner int2 field in > > > pg_statistic where the IDs are allocated by the PGDG. > > > > I do not really want to add a field to pg_statistic. That > > complicates matters more than we have a justification to do. > > Nor do we have any reason at this point to think that we need > > a 2^32 namespace for statistics kinds. (If 2^16 ever starts > > to look cramped, we can just widen the fields to int4 without > > introducing any backwards compatibility issues --- existing > > code assignments will remain valid. But I find it hard to > > foresee that happening.) > > OK, I've left this as it is at the moment. > > > Cheers, > > Mark. > > --- > > Mark Cave-Ayland > Webbased Ltd. > Tamar Science Park > Derriford > Plymouth > PL6 8BX > England > > Tel: +44 (0)1752 764445 > Fax: +44 (0)1752 764446 > > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. You > should not copy it or use it for any purpose nor disclose or distribute > its contents to any other person. [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Vacuum Delay feature
Jan Wieck wrote: > Bruce Momjian wrote: > > > Jan Wieck wrote: > >> Attached is a corrected version that solves the query cancel problem by > >> not napping any more and going full speed as soon as any signal is > >> pending. If nobody objects, I'm going to commit this tomorrow. > > > > Jan, three questions. First, is this useful now that we have the new > > cache replacement code, second, do we need this many parameters (can't > > any of them be autotuned), and third, what about documentation? > > > > You mean if stopping to nap is useful when a signal is pending or if > napping during vacuum itself is useful at all? > > I am willing to make it all self tuning and automagic. Just tell me how. I was hoping you would have some ideas. :-) I guess my question is that now that we have the new cache replacement policy, is the vacuum delay worth while. I looked at http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem useful. > Documentation is missing so far. Will work on that. Cool. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ANALYZE patch for review
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > Yup indeed. Please find enclosed the latest version of the analyze patch > taking into account all the things we have discussed in the thread. I've reviewed and applied this with some small changes. You did a good job --- the only things you missed AFAICS were pg_dump support and documentation. I changed the API slightly for the typanalyze function and the compute_stats subroutine. I don't think it's necessary or appropriate to pass in the Relation pointer to typanalyze; that simplifies its signature to a single INTERNAL parameter. (If we did want to pass the Relation, I'd be inclined to make it a field in VacAttrStats.) Also I tweaked compute_stats so that the attribute number of the column is passed explicitly. I foresee needing this for functional-index stats gathering --- it's likely that the accumulated sample rows will be built on the fly and will have a tupdesc that includes both the main table rows and the functional index columns. So compute_stats shouldn't assume that the nominal column number is the right thing to use to extract the column it wants. > I also altered the examine_attribute() to allow the user-defined > function to check attstattarget for the column manually (in case they > want to do something special with minus or zero values), As I've committed it, the convention that zero means "no stats" is enforced by examine_attribute(), but the typanalyze function is responsible for deciding what a negative value means. Seem reasonable? Also, I put the following documentation about "kind" values into pg_statistic.h. /* * The present allocation of "kind" codes is: * *1-99:reserved for assignment by the core PostgreSQL project * (values in this range will be documented in this file) *100-199: reserved for assignment by the PostGIS project * (values to be documented in PostGIS documentation) *200-:reserved for future public assignments * * For private use you may choose a "kind" code at random in the range * 1-3. However, for code that is to be widely disseminated it is * better to obtain a publicly defined "kind" code by request from the * PostgreSQL Global Development Group. */ regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Patch for psql startup clarity
Peter Eisentraut wrote:
> David Fetter wrote:
> > > > \? for help with psql commands
>
> > If you wanted to pick one of the two patches, which one would it be?
> > If not, what should the patch look like?
>
> There seems to be a consensus on the form left standing above. That
> seems OK to me.
Attached patch applied. Thanks.
---
Welcome to psql 7.5devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/TODO
===
RCS file: /cvsroot/pgsql-server/doc/TODO,v
retrieving revision 1.1211
diff -c -c -r1.1211 TODO
*** doc/TODO12 Feb 2004 18:11:16 - 1.1211
--- doc/TODO12 Feb 2004 19:57:01 -
***
*** 1,6
TODO list for PostgreSQL
! Last updated: Thu Feb 12 13:11:14 EST 2004
Current maintainer: Bruce Momjian ([EMAIL PROTECTED])
--- 1,6
TODO list for PostgreSQL
! Last updated: Thu Feb 12 13:14:40 EST 2004
Current maintainer: Bruce Momjian ([EMAIL PROTECTED])
Index: doc/src/sgml/start.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/start.sgml,v
retrieving revision 1.34
diff -c -c -r1.34 start.sgml
*** doc/src/sgml/start.sgml 12 Feb 2004 16:38:04 - 1.34
--- doc/src/sgml/start.sgml 12 Feb 2004 19:57:01 -
***
*** 321,327
Type: \copyright for distribution terms
\h for help with SQL commands
!\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
--- 321,327
Type: \copyright for distribution terms
\h for help with SQL commands
!\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.104
diff -c -c -r1.104 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 20 Jan 2004 23:48:56 - 1.104
--- doc/src/sgml/ref/psql-ref.sgml 12 Feb 2004 19:57:05 -
***
*** 524,530
Type: \copyright for distribution terms
\h for help with SQL commands
!\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
--- 524,530
Type: \copyright for distribution terms
\h for help with SQL commands
!\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.83
diff -c -c -r1.83 startup.c
*** src/bin/psql/startup.c 25 Jan 2004 03:07:22 - 1.83
--- src/bin/psql/startup.c 12 Feb 2004 19:57:08 -
***
*** 267,274
printf(gettext("Welcome to %s %s, the PostgreSQL interactive
terminal.\n\n"
"Type: \\copyright for
distribution terms\n"
" \\h for help with SQL
commands\n"
! " \\? for help on internal slash
commands\n"
! " \\g or terminate with semicolon to execute query\n"
" \\q to quit\n\n"),
pset.progname, PG_VERSION);
#ifdef USE_SSL
--- 267,274
printf(gettext("Welcome to %s %s, the PostgreSQL interactive
terminal.\n\n"
"Type: \\copyright for
distribution terms\n"
" \\h for help with SQL
commands\n"
! " \\? for help with psql
commands\n"
! " \\g or terminate with
semicolon to execute query\n"
" \\q to quit\n\n"),
pset.progname, PG_VERSION);
#ifdef USE_SSL
---(end of broadcast)---
TIP 7: don't
[PATCHES] win32 setitimer implementation
Hello! Here is a patch that implements setitimer() on win32. With this patch applied, deadlock detection and statement_timeout now works. The file timer.c goes into src/backend/port/win32/. The patch also removes two lines of "printf debugging" accidentally left in pqsignal.h, in the console control handler. //Magnus <> <> win32_setitimer.patch Description: win32_setitimer.patch timer.c Description: timer.c ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] temp patch for win32 readdir issue
We will document this on the win32 TODO list and remove this patch once MinGW is fixed. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Magnus Hagander wrote: > Ok, so I know this is pretty ugly. But there is a bug in mingw (current > release - it's fixed in the snapshot version) with regards to readdir() > (see previous mails on win32-hackers). Basically, it doesn't set errno > correctly. > > This patch will catch this error with regards to the readdir(), wrap a > change in #ifdef WIN32, and emit a warning at compile time. This is a > temporary measure until mingw releases a version that has this fixed. > > Applying this will make it easier on those who want to compile > postgresql on win32, since it removes a manual step. Which is why I'm > giving it a shot posting it here even though it's ugly. > > //Magnus Content-Description: win32_readdir.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] temp patch for win32 readdir issue
Removed. Adding new version. --- Magnus Hagander wrote: > Ok, so I know this is pretty ugly. But there is a bug in mingw (current > release - it's fixed in the snapshot version) with regards to readdir() > (see previous mails on win32-hackers). Basically, it doesn't set errno > correctly. > > This patch will catch this error with regards to the readdir(), wrap a > change in #ifdef WIN32, and emit a warning at compile time. This is a > temporary measure until mingw releases a version that has this fixed. > > Applying this will make it easier on those who want to compile > postgresql on win32, since it removes a manual step. Which is why I'm > giving it a shot posting it here even though it's ugly. > > //Magnus Content-Description: win32_readdir.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Vacuum Delay feature
Jan Wieck wrote: > Attached is a corrected version that solves the query cancel problem by > not napping any more and going full speed as soon as any signal is > pending. If nobody objects, I'm going to commit this tomorrow. Jan, three questions. First, is this useful now that we have the new cache replacement code, second, do we need this many parameters (can't any of them be autotuned), and third, what about documentation? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] support for printing/exporting xml
Bruce Momjian wrote: > I assume the group agreed that adding XML to libpq was the way to > handle XML, with a hook in psql to call it. I'm not sure about that, but we certainly disagree with this kind of nonstandard XML when there is a perfectly good standard out there. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] support for printing/exporting xml
Peter Eisentraut wrote: > Bruce Momjian wrote: > > I assume the group agreed that adding XML to libpq was the way to > > handle XML, with a hook in psql to call it. > > I'm not sure about that, but we certainly disagree with this kind of > nonstandard XML when there is a perfectly good standard out there. OK, can you elaborate? What is the non-standard part? His choice of tags? -- 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 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] support for printing/exporting xml
Bruce Momjian <[EMAIL PROTECTED]> writes: > I assume the group agreed that adding XML to libpq was the way to handle > XML, with a hook in psql to call it. My recollection was that we had not agreed we liked this patch? regards, tom lane ---(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] support for printing/exporting xml
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > > > I assume the group agreed that adding XML to libpq was the way to > > > handle XML, with a hook in psql to call it. > > > > I'm not sure about that, but we certainly disagree with this kind > > of nonstandard XML when there is a perfectly good standard out > > there. > > OK, can you elaborate? What is the non-standard part? His choice of > tags? Yes. The SQL/XML standard has been discussed several times on this list. Additionally, it has been mentioned that an implementation in libpq is too specific for some. Some people want streaming interfaces, some want it in the backend, etc. I think there are going to be many implementations of the XML theme, so I think it's premature to adopt one of them into libpq. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] win32 patch: Signal delivery when blocking on semaphore
This patch makes the "block on semaphore" interruptible by signals on win32. Without this, you can't kill a backend when it's waiting on a lock. //Magnus win32_semint.patch Description: win32_semint.patch ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] support for printing/exporting xml
Patch removed. Requires more discussion. --- Brian Moore wrote: > hello, > > please find attached my support for printing/exporting > xml from postgresql. psql has been modified to take > an additional command line argument (-M) to print xml > and the file fe-printxml.c has been added. additionally, > i have added an extra function to libpq, PGresult_as_xml > > thanks, > > b > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ Content-Description: postgresql-7.4.1.add_xml_export_support.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] support for printing/exporting xml
Peter Eisentraut wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Bruce Momjian wrote: > > > > I assume the group agreed that adding XML to libpq was the way to > > > > handle XML, with a hook in psql to call it. > > > > > > I'm not sure about that, but we certainly disagree with this kind > > > of nonstandard XML when there is a perfectly good standard out > > > there. > > > > OK, can you elaborate? What is the non-standard part? His choice of > > tags? > > Yes. The SQL/XML standard has been discussed several times on this > list. Additionally, it has been mentioned that an implementation in > libpq is too specific for some. Some people want streaming interfaces, > some want it in the backend, etc. I think there are going to be many > implementations of the XML theme, so I think it's premature to adopt > one of them into libpq. OK, what do you suggest the poster does now? Use SQL/XML? Move it into the backend? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Some new SPI functions
Tom Lane wrote: > "Thomas Hallgren" <[EMAIL PROTECTED]> writes: > > I need three new functions in the Server Programming Interface (SPI) when > > mapping an ExecutionPlan to a Java prepared statement (Pl/Java project). > > These functions look reasonable, but where is the documentation patch? I assume it will come when the final patch is submitted. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] support for printing/exporting xml
I assume the group agreed that adding XML to libpq was the way to handle XML, with a hook in psql to call it. I also see this copyright on one of the files: + * Hash Table Data Type + * Copyright (C) 1997 Kaz Kylheku <[EMAIL PROTECTED]> + * + * Free Software License: + * + * All rights are reserved by the author, with the following exceptions: + * Permission is granted to freely reproduce and distribute this software, + * possibly in exchange for a fee, provided that this copyright notice appears + * intact. Permission is also granted to adapt this software to produce + * derivative works, as long as the modified versions carry this copyright + * notice and additional notices stating that the work has been modified. + * This source code may be translated into executable form and incorporated + * into proprietary software; there is no requirement for such software to + * contain a copyright notice related to this source. + * I assume this copyright is compatible with our BSD copyright. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Brian Moore wrote: > hello, > > please find attached my support for printing/exporting > xml from postgresql. psql has been modified to take > an additional command line argument (-M) to print xml > and the file fe-printxml.c has been added. additionally, > i have added an extra function to libpq, PGresult_as_xml > > thanks, > > b > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ Content-Description: postgresql-7.4.1.add_xml_export_support.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Some new SPI functions
"Thomas Hallgren" <[EMAIL PROTECTED]> writes: > I need three new functions in the Server Programming Interface (SPI) when > mapping an ExecutionPlan to a Java prepared statement (Pl/Java project). These functions look reasonable, but where is the documentation patch? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[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 pl implementations where similar support
is planned might find these functions useful.
Thomas Hallgren
Index: src/backend/executor/spi.c
===
retrieving revision 1.109
diff -u -r1.109 spi.c
--- src/backend/executor/spi.c 2 Dec 2003 19:26:47 - 1.109
+++ src/backend/executor/spi.c 12 Feb 2004 11:13:11 -
@@ -918,6 +918,65 @@
PortalDrop(portal, false);
}
+/*
+ * Returns the Oid representing the type id for argument at argIndex. First
+ * parameter is at index zero.
+ */
+Oid
+SPI_getargtypeid(void *plan, int argIndex)
+{
+ if (plan == NULL || argIndex < 0 || argIndex >= ((_SPI_plan*)plan)->nargs)
+ {
+ SPI_result = SPI_ERROR_ARGUMENT;
+ return InvalidOid;
+ }
+ return ((_SPI_plan *) plan)->argtypes[argIndex];
+}
+
+/*
+ * Returns the number of arguments for the prepared plan.
+ */
+int
+SPI_getargcount(void *plan)
+{
+ if (plan == NULL)
+ {
+ SPI_result = SPI_ERROR_ARGUMENT;
+ return -1;
+ }
+ return ((_SPI_plan *) plan)->nargs;
+}
+
+/*
+ * Returns true if the plan contains exactly one command
+ * and that command originates from normal SELECT (i.e.
+ * *not* a SELECT ... INTO). In essence, the result indicates
+ * if the command can be used with SPI_cursor_open
+ *
+ * Parameters
+ *plan A plan previously prepared using SPI_prepare
+ */
+bool
+SPI_is_cursor_plan(void *plan)
+{
+ List *qtlist;
+ _SPI_plan *spiplan = (_SPI_plan *) plan;
+ if (spiplan == NULL)
+ {
+ SPI_result = SPI_ERROR_ARGUMENT;
+ return false;
+ }
+
+ qtlist = spiplan->qtlist;
+ if(length(spiplan->ptlist) == 1 && length(qtlist) == 1)
+ {
+ Query *queryTree = (Query *) lfirst((List *) lfirst(qtlist));
+ if(queryTree->commandType == CMD_SELECT && queryTree->into == NULL)
+ return true;
+ }
+ return false;
+}
+
/* === private functions === */
/*
Index: src/include/executor/spi.h
===
retrieving revision 1.41
diff -u -r1.41 spi.h
--- src/include/executor/spi.h 2 Dec 2003 19:26:47 - 1.41
+++ src/include/executor/spi.h 12 Feb 2004 11:13:21 -
@@ -90,6 +90,10 @@
extern void *SPI_saveplan(void *plan);
extern int SPI_freeplan(void *plan);
+extern Oid SPI_getargtypeid(void *plan, int argIndex);
+extern int SPI_getargcount(void *plan);
+extern bool SPI_is_cursor_plan(void *plan);
+
extern HeapTuple SPI_copytuple(HeapTuple tuple);
extern TupleDesc SPI_copytupledesc(TupleDesc tupdesc);
extern TupleTableSlot *SPI_copytupleintoslot(HeapTuple tuple,
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] 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
