Re: [PATCHES] [PATCH] Add support for GnuTLS
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I think we are ready to move forward with this. Please supply an updated patch ready for application. Thanks. I'm still not very happy with the size/invasiveness of that patch. Nor am I. FWIW, Red Hat's legal department thinks that the FSF has overreached in claiming that the GPL is incompatible with OpenSSL's license. Which is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which there are quite a few ... OK. Let's shelve the idea. I will add a TODO item. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [PATCH] Add support for GnuTLS
On Mon, May 29, 2006 at 11:21:16PM -0400, Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I think we are ready to move forward with this. Please supply an updated patch ready for application. Thanks. I'm still not very happy with the size/invasiveness of that patch. I think the size is unavoidable due to the amount of code being copied between files. As an example I've created a version of the patch which contains the minimal number of changes required for GnuTLS support. That weighs in at 48KB. It does it by putting everything required into one file and using #ifdefs to determine which code to compile. Note: it's just an example, I wouldn't suggest adding it. For starters, the #ifdef forest is a text-book example of how not to do things. However, any increase in modularisation is going to increase the size of the patch due to the moving around of code. If you have any suggestions about the trade-off between modularity and patch size, I'd like to hear them. At the end of the day, what really needs to happen is that a position needs to be taken: 1. No, never support anything other than OpenSSL 2. Yes, support GnuTLS but not in this form 3. Yes, accept patch as is (with updates for CVS drift) Once a decision has been made, whatever it is, we can move forward. The other features of the original patch can be added later if needed. FWIW, Red Hat's legal department thinks that the FSF has overreached in claiming that the GPL is incompatible with OpenSSL's license. Which is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which there are quite a few ... It is absolutly true that being a limited liability company and having money to pay lawyers helps with legal questions. Have a ncie day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [PATCHES] [PATCH] Add support for GnuTLS
Forgot the patch... On Tue, May 30, 2006 at 01:01:38PM +0200, Martijn van Oosterhout wrote: snip -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. Index: configure Index: configure.in === RCS file: /projects/cvsroot/pgsql/configure.in,v retrieving revision 1.464 diff -c -r1.464 configure.in *** configure.in29 Apr 2006 20:47:29 - 1.464 --- configure.in30 May 2006 10:51:30 - *** *** 489,498 # AC_MSG_CHECKING([whether to build with OpenSSL support]) PGAC_ARG_BOOL(with, openssl, no, [ --with-openssl build with OpenSSL support], ! [AC_DEFINE([USE_SSL], 1, [Define to build with (Open)SSL support. (--with-openssl)])]) AC_MSG_RESULT([$with_openssl]) AC_SUBST(with_openssl) # # Prefer libedit --- 489,515 # AC_MSG_CHECKING([whether to build with OpenSSL support]) PGAC_ARG_BOOL(with, openssl, no, [ --with-openssl build with OpenSSL support], ! [AC_DEFINE([USE_SSL_OPENSSL], 1, [Define to build with (Open)SSL support. (--with-openssl)])]) AC_MSG_RESULT([$with_openssl]) AC_SUBST(with_openssl) + # + # GnuTLS + # + AC_MSG_CHECKING([whether to build with GnuTLS support]) + PGAC_ARG_BOOL(with, gnutls, no, [ --with-gnutls build with GnuTLS support], + [AC_DEFINE([USE_SSL_GNUTLS], 1, [Define to build with GnuTLS (SSL) support. (--with-gnutls)])]) + AC_MSG_RESULT([$with_gnutls]) + AC_SUBST(with_gnutls) + + if test $with_openssl = yes -o $with_gnutls = yes ; then + AC_DEFINE([USE_SSL], 1, [Define to build with SSL support (select either OpenSSL or GnuTLS)]) + fi + + if test $with_openssl = yes -a $with_gnutls = yes ; then + AC_MSG_ERROR([ + *** Cannot select both OpenSSL and GnuTLS.]) + fi # # Prefer libedit *** *** 692,697 --- 709,720 fi fi + if test $with_gnutls = yes ; then + AC_CHECK_LIB(gnutls, gnutls_init, [], [AC_MSG_ERROR([library 'gnutls' is required for GnuTLS])]) + # Technically we only need this with --enable-thread-safety + AC_CHECK_LIB(gcrypt, gcry_control, [], [AC_MSG_ERROR([library 'gcrypt' is required for GnuTLS])]) + fi + if test $with_pam = yes ; then AC_CHECK_LIB(pam,pam_start, [], [AC_MSG_ERROR([library 'pam' is required for PAM])]) fi *** *** 774,779 --- 797,807 AC_CHECK_HEADER(openssl/err.h, [], [AC_MSG_ERROR([header file openssl/err.h is required for OpenSSL])]) fi + if test $with_gnutls = yes ; then + AC_CHECK_HEADER(gnutls/gnutls.h, [], [AC_MSG_ERROR([header file gnutls/gnutls.h is required for GnuTLS])]) + AC_CHECK_HEADER(gcrypt.h,[], [AC_MSG_ERROR([header file gcrypt.h is required for GnuTLS])]) + fi + if test $with_pam = yes ; then AC_CHECK_HEADERS(security/pam_appl.h, [], [AC_CHECK_HEADERS(pam/pam_appl.h, [], Index: src/backend/libpq/be-secure.c === RCS file: /projects/cvsroot/pgsql/src/backend/libpq/be-secure.c,v retrieving revision 1.70 diff -c -r1.70 be-secure.c *** src/backend/libpq/be-secure.c 12 May 2006 22:44:36 - 1.70 --- src/backend/libpq/be-secure.c 30 May 2006 10:51:32 - *** *** 89,99 #include arpa/inet.h #endif ! #ifdef USE_SSL #include openssl/ssl.h #include openssl/dh.h #endif #include libpq/libpq.h #include miscadmin.h #include tcop/tcopprot.h --- 89,108 #include arpa/inet.h #endif ! #ifdef USE_SSL_OPENSSL #include openssl/ssl.h #include openssl/dh.h #endif + #ifdef USE_SSL_GNUTLS + #include gnutls/gnutls.h + #include gnutls/x509.h + + /* If thread safety ever becomes an issue for the backend, we will need to + * include this. See the frontend code in libpq. */ + /* #include gcrypt.h */ + #endif + #include libpq/libpq.h #include miscadmin.h #include tcop/tcopprot.h *** *** 106,132 #define SERVER_CERT_FILE server.crt #define SERVER_PRIVATE_KEY_FILE server.key - static DH *load_dh_file(int keylength); - static DH *load_dh_buffer(const char *, size_t); - static DH *tmp_dh_cb(SSL *s, int is_export, int keylength); - static intverify_cb(int, X509_STORE_CTX *); - static void info_cb(const SSL *ssl, int type, int args); static void initialize_SSL(void); static void destroy_SSL(void); static intopen_server_SSL(Port *); static void close_SSL(Port *); - static const char *SSLerrmessage(void); - #endif - - #ifdef USE_SSL /* *How much data can be sent across a secure connection *(total in both directions) before we require renegotiation. */ #define RENEGOTIATION_LIMIT (512 * 1024 * 1024) static SSL_CTX *SSL_context = NULL; #endif /*
Re: [PATCHES] plpgsql documentation
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, http://www.postgresql.org/developer/testing. --- Chris Browne wrote: An article at WebProNews quoted from the PG docs as to the merits of stored procedures. I have added a bit more material on their merits, as well as making a few changes to improve the introductions to PL/Perl and PL/Tcl. Index: plperl.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v retrieving revision 2.52 diff -c -u -r2.52 plperl.sgml --- plperl.sgml 10 Mar 2006 19:10:48 - 2.52 +++ plperl.sgml 25 May 2006 22:38:45 - @@ -17,6 +17,12 @@ ulink url=http://www.perl.com;Perl programming language/ulink. /para + para The usual advantage to using PL/Perl is that this allows use, + within stored functions, of the manyfold quotestring +munging/quote operators and functions available for Perl. Parsing + complex strings may be be easier using Perl than it is with the + string functions and control structures provided in PL/pgsql./para + para To install PL/Perl in a particular database, use literalcreatelang plperl replaceabledbname//literal. Index: plpgsql.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.88 diff -c -u -r1.88 plpgsql.sgml --- plpgsql.sgml 10 Mar 2006 19:10:48 - 1.88 +++ plpgsql.sgml 25 May 2006 22:38:46 - @@ -155,21 +155,36 @@ para That means that your client application must send each query to - the database server, wait for it to be processed, receive the - results, do some computation, then send other queries to the - server. All this incurs interprocess communication and may also - incur network overhead if your client is on a different machine - than the database server. + the database server, wait for it to be processed, receive and + process the results, do some computation, then send further + queries to the server. All this incurs interprocess + communication and will also incur network overhead if your client + is on a different machine than the database server. /para para - With applicationPL/pgSQL/application you can group a block of computation and a - series of queries emphasisinside/emphasis the - database server, thus having the power of a procedural - language and the ease of use of SQL, but saving lots of - time because you don't have the whole client/server - communication overhead. This can make for a - considerable performance increase. + With applicationPL/pgSQL/application you can group a block of + computation and a series of queries emphasisinside/emphasis + the database server, thus having the power of a procedural + language and the ease of use of SQL, but with considerable + savings because you don't have the whole client/server + communication overhead. +/para +itemizedlist + + listitempara Elimination of additional round trips between + client and server /para/listitem + + listitempara Intermediate results that the client does not + need do not need to be marshalled or transferred between server + and client /para/listitem + + listitempara There is no need for additional rounds of query + parsing /para/listitem + +/itemizedlist +para This can allow for a considerable performance increase as +compared to an application that does not use stored functions. /para para Index: pltcl.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v retrieving revision 2.39 diff -c -u -r2.39 pltcl.sgml --- pltcl.sgml10 Mar 2006 19:10:48 - 2.39 +++ pltcl.sgml25 May 2006 22:38:46 - @@ -25,22 +25,27 @@ titleOverview/title para -PL/Tcl offers most of the capabilities a function -writer has in the C language, except for some restrictions. +PL/Tcl offers most of the capabilities a function writer has in +the C language, with a few restrictions, and with the addition of +the powerful string processing libraries that are available for +Tcl. /para para -The good restriction is that everything is executed in a safe -Tcl interpreter. In addition to the limited command set of safe Tcl, only -a few commands are available to access the database via SPI and to raise -messages via functionelog()/. There is no way to access internals of the -database server or to gain OS-level access under the permissions of the -
Re: [PATCHES] small doc patch for regexp_replace
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, http://www.postgresql.org/developer/testing. --- Joachim Wieland wrote: Is there any reason, why regexp_replace is not included in the tables of the string functions? http://developer.postgresql.org/docs/postgres/functions-string.html The appended patch adds regexp_replace() and links to the pattern matching section for substring / regexp_replace. I noticed that in the table the declaration of the arguments is inconsistent, for example: lower(string) ascii(text) length(string text) also in the sgml, there is sometimes text and sometimes typetext/type. I'd fix that if someone told me what the preferred (if any) form is... Joachim [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Patch applied. Thanks. --- [EMAIL PROTECTED] wrote: Bruce Momjian schrieb: This patch cannot be applied. 'active_simple_exprs' is referenced but not defined. I think the new variable name is 'simple_eval_estate', which used to be a structure member of 'active_simple_exprs'. Would you please update it against current CVS and resubmit? Thanks. Attached please find the patch against head of today, 2034 UTC Someone had removed active_simple_exprs. Actually I didn't use it but simply had to clean it up before calling freeplan. I removed the appropriate lines of code. Please let me know if anything appears to be wrong with this patch. Regards Titus *** ./doc/src/sgml/plpgsql.sgml.orig Fri Mar 10 20:10:48 2006 --- ./doc/src/sgml/plpgsql.sgml Mon May 8 23:40:12 2006 *** *** 865,870 --- 865,919 /para para + To obtain the values of the fields the record is made up of, + the record variable can be qualified with the column or field + name. This can be done either by literally using the column name + or the column name for indexing the record can be taken out of a scalar + variable. The syntax for this notation is Record_variable.(IndexVariable). + To get information about the column field names of the record, + a special expression exists that returns all column names as an array: + RecordVariable.(*) . + Thus, the RECORD can be viewed + as an associative array that allows for introspection of it's contents. + This feature is especially useful for writing generic triggers that + operate on records with unknown structure. + Here is an example procedure that shows column names and values + of the predefined record NEW in a trigger procedure: + programlisting + + CREATE OR REPLACE FUNCTION show_associative_records() RETURNS TRIGGER AS $$ + DECLARE + colname TEXT; + colcontent TEXT; + colnamesTEXT[]; + colnINT4; + coliINT4; + BEGIN + -- obtain an array with all field names of the record + colnames := NEW.(*); + RAISE NOTICE 'All column names of test record: %', colnames; + -- show field names and contents of record + coli := 1; + coln := array_upper(colnames,1); + RAISE NOTICE 'Number of columns in NEW: %', coln; + FOR coli IN 1 .. coln LOOP + colname := colnames[coli]; + colcontent := NEW.(colname); + RAISE NOTICE 'column % of NEW: %', quote_ident(colname), quote_literal(colcontent); + END LOOP; + -- Do it with a fixed field name: + -- will have to know the column name + RAISE NOTICE 'column someint of NEW: %', quote_literal(NEW.someint); + RETURN NULL; + END; + $$ LANGUAGE plpgsql; + --CREATE TABLE test_records (someint INT8, somestring TEXT); + --CREATE TRIGGER tr_test_record BEFORE INSERT ON test_records FOR EACH ROW EXECUTE PROCEDURE show_associative_records(); + + /programlisting +/para + +para Note that literalRECORD/ is not a true data type, only a placeholder. One should also realize that when a applicationPL/pgSQL/application function is declared to return type typerecord/, this is not quite the *** ./src/pl/plpgsql/src/pl_comp.c.orig Tue Mar 14 23:48:23 2006 --- ./src/pl/plpgsql/src/pl_comp.cMon May 8 22:49:50 2006 *** *** 870,876 new = palloc(sizeof(PLpgSQL_recfield)); new-dtype = PLPGSQL_DTYPE_RECFIELD; ! new-fieldname = pstrdup(cp[1]); new-recparentno = ns-itemno; plpgsql_adddatum((PLpgSQL_datum *) new); --- 870,877 new = palloc(sizeof(PLpgSQL_recfield)); new-dtype = PLPGSQL_DTYPE_RECFIELD; ! new-fieldindex.fieldname = pstrdup(cp[1]); ! new-fieldindex_flag = RECFIELD_USE_FIELDNAME; new-recparentno = ns-itemno; plpgsql_adddatum((PLpgSQL_datum *) new); *** *** 976,982 new = palloc(sizeof(PLpgSQL_recfield)); new-dtype = PLPGSQL_DTYPE_RECFIELD; ! new-fieldname = pstrdup(cp[2]); new-recparentno = ns-itemno; plpgsql_adddatum((PLpgSQL_datum *) new); --- 977,984 new = palloc(sizeof(PLpgSQL_recfield));
Re: [PATCHES] [pgadmin-hackers] Adminpack contrib module
Patch applied. Thanks. --- Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrus Sent: 08 May 2006 18:16 To: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] Adminpack contrib module There were no objections, so attached is an updated version of the adminpack, with non-version specific naming for addition to the source tree. The entire directory in the archive should be added to /contrib, and an appropriate entry added to contrib/Makefile. adminpack.sql.in file contains comment /* generic file access functions (genfile.c) */ However, there is no genfile.c file in this package. Well spotted - update attached. Thanks, Dave. Content-Description: adminpack.tar.gz [ Attachment, skipping... ] ---(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 -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] fori stmt with by keyword was:(Re: [HACKERS] for statement,
I went to test this patch and got the attached regression failures.
Please repair and resubmit. Thanks.
---
Jaime Casanova wrote:
On 4/30/06, Jaime Casanova [EMAIL PROTECTED] wrote:
On 4/29/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
there is a chance to add a STEP clause to the FOR statement in plpgsql?
This is not free: it'd require making STEP a reserved word (at least
within plpgsql) which is contrary to spec. I think you need to make
a pretty good case why the value of the feature outweighs breaking
applications that have perfectly-legally used step as an identifier.
This isn't available in PL/SQL, is it? That doesn't mean we shouldn't do
it, of course, but it might lessen any perceived imperative.
Maybe using BY instad of STEP as the keyword would make it easier, since
its occurrence in SQL makes it less likely to be used as a variable.
cheers
andrew
Hi,
i make a little patch using BY instead of STEP per Tom's complaint and
Andrew's suggestion.
the patch is ready, at least it seems to me... also i have added some
lines to the docs...
let me know what your decision is about this...
--
regards,
Jaime Casanova
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning.
Richard Cook
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
*** ./expected/plpgsql.out Tue May 30 07:58:19 2006
--- ./results/plpgsql.out Tue May 30 08:13:52 2006
***
*** 1466,1474
--- 1466,1482
-- ethernet interface into the wall and patch it to the hub.
--
insert into Hub values ('base.hub1', 'Patchfield PF0_1 hub', 16);
+ ERROR: syntax error at or near ¤
+ LINE 1: ¤JäH¯#¤F
+ ^
+ QUERY: ¤JäH¯#¤F
+ CONTEXT: PL/pgSQL function tg_hub_adjustslots line 9 at for with integer
loopvar
+ PL/pgSQL function tg_hub_a line 6 at assignment
insert into System values ('orion', 'PC');
insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b');
update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2';
+ ERROR: HS.base.hub1.1 does not exist
+ CONTEXT: PL/pgSQL function tg_slotlink_a line 16 at assignment
--
-- Now we take a look at the patchfield
--
***
*** 1482,1488
PF0_1 | PS.base.a5 | WS.001.3a in room 001 - -
| -
PF0_1 | PS.base.a6 | WS.001.3b in room 001 - -
| -
PF0_1 | PS.base.b1 | WS.002.1a in room 002 - Phone PH.hc002
(Hicom standard) | PS.base.ta5 - Phone line -103
! PF0_1 | PS.base.b2 | WS.002.1b in room 002 - orion IF eth0 (PC)
| Patchfield PF0_1 hub slot 1
PF0_1 | PS.base.b3 | WS.002.2a in room 002 - Phone PH.hc003
(Hicom standard) | PS.base.tb2 - Phone line -106
PF0_1 | PS.base.b4 | WS.002.2b in room 002 - -
| -
PF0_1 | PS.base.b5 | WS.002.3a in room 002 - -
| -
--- 1490,1496
PF0_1 | PS.base.a5 | WS.001.3a in room 001 - -
| -
PF0_1 | PS.base.a6 | WS.001.3b in room 001 - -
| -
PF0_1 | PS.base.b1 | WS.002.1a in room 002 - Phone PH.hc002
(Hicom standard) | PS.base.ta5 - Phone line -103
! PF0_1 | PS.base.b2 | WS.002.1b in room 002 - orion IF eth0 (PC)
| -
PF0_1 | PS.base.b3 | WS.002.2a in room 002 - Phone PH.hc003
(Hicom standard) | PS.base.tb2 - Phone line -106
PF0_1 | PS.base.b4 | WS.002.2b in room 002 - -
| -
PF0_1 | PS.base.b5 | WS.002.3a in room 002 - -
| -
***
*** 1530,1540
ERROR: illegal slotlink beginning with XX
CONTEXT: PL/pgSQL function tg_slotlink_a line 16 at assignment
insert into HSlot values ('HS', 'base.hub1', 1, '');
! ERROR: duplicate key violates unique constraint hslot_name
insert into HSlot values ('HS', 'base.hub1', 20, '');
ERROR: no manual manipulation of HSlot
delete from HSlot;
- ERROR: no manual manipulation of HSlot
insert into IFace values ('IF', 'notthere', 'eth0', '');
ERROR: system notthere does not exist
insert into IFace values ('IF', 'orion', 'ethernet_interface_name_too_long',
'');
--- 1538,1547
ERROR: illegal slotlink beginning with XX
CONTEXT: PL/pgSQL function tg_slotlink_a line 16 at assignment
insert into HSlot
Re: [PATCHES] The problem of an inline definition by construction in
Patch applied to CVS HEAD and 8.1.X. Thanks. Borland CC also needed this change, so I modified your patch appropriately. --- Hiroshi Saito wrote: Dear Bruce san. I neglected sufficient test before a release.:-( Problem appears by construction in win32 of 8.1.4. nmake -f win32.mak .\Release\\ /FD /c /D HAVE_VSNPRINTF /D HAVE_STRDUP pqexpbuffer.c pqexpbuffer.c cl.exe /nologo /W3 /GX /O2 /MD /I ..\..\include /I. /D FRONTEND /D N DEBUG /D WIN32 /D _WINDOWS /Fp.\Release\libpq.pch /YX /Fo.\Release\\ /Fd .\Release\\ /FD /c /D HAVE_VSNPRINTF /D HAVE_STRDUP pqsignal.c pqsignal.c cl.exe @C:\DOCUME~1\saito\LOCALS~1\Temp\nmi02992. wchar.c ..\..\backend\utils\mb\wchar.c(100) : error C2054: 'inline' ..\..\backend\utils\mb\wchar.c(101) : error C2085: 'pg_euc_mblen' (snip) It is not mingw. Regards, Hiroshi Saito [ Attachment, skipping... ] ---(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 -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
Re: [PATCHES] Add namespace dependency for conversions
Patch applied. Thanks. --- Bernd Helmle wrote: Currently we don't record any dependencies between namespaces and conversions. This looks inconsistent to me, since we have dependencies on all other objects that live within namespaces. Please find attached a small patch that fixes this issue. -- Thanks Bernd [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] trivial fix in fd.c
Patch applied. Thanks. --- Qingqing Zhou wrote: Fix a format warning in fd.c when FDDEBUG is on. By the way (to save a thread): What's the rationale of designing resowner APIs like this: ResourceOwnerEnlargeABC(); ResourceOwnerRememberABC(); Is that because sometimes we don't allow any elog in ResourceOwnerRememberABC()? Regards, Qingqing Index: fd.c === RCS file: /projects/cvsroot/pgsql/src/backend/storage/file/fd.c,v retrieving revision 1.127 diff -c -r1.127 fd.c *** fd.c5 Mar 2006 15:58:37 - 1.127 --- fd.c22 May 2006 08:00:42 - *** *** 649,655 Index i; Filefile; ! DO_DB(elog(LOG, AllocateVfd. Size %d, SizeVfdCache)); Assert(SizeVfdCache 0); /* InitFileAccess not called? */ --- 649,655 Index i; Filefile; ! DO_DB(elog(LOG, AllocateVfd. Size %lu, SizeVfdCache)); Assert(SizeVfdCache 0); /* InitFileAccess not called? */ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] archiver.pid
Patch applied to CVS HEAD and 8.1.X. Thanks. --- Simon Riggs wrote: On Mon, 2006-05-22 at 17:29 +0100, Simon Riggs wrote: Lock file to prevent starting with multiple archivers present. Possibly some debate over exact behaviour, but publish early... Original patch withdrawn. New patch included. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. I wish to object to this patch; it's poorly designed, poorly coded, and badly documented. The philosophy seems to be I want this feature and I don't care what I have to do to the semantics and performance of plpgsql to get it. In particular I don't like the bits that go /* Do not allow typeids to become narrowed by InvalidOids causing specialized typeids from the tuple restricting the destination */ The incoherence of the comment is a good guide to how poorly thought out the code is. These bits are positioned so that they change the language semantics even when not using a dynamic field reference; what's more, they don't make any sense when you *are* using a dynamic field reference, because you need to keep the actual field type not try (probably vainly) to cast it to whatever the previous field's type was. I also dislike the loop added to exec_eval_cleanup(), which will impose a significant performance penalty on every single expression evaluation done by any plpgsql function, whether it's ever heard of dynamic field references or not. I doubt it's even necessary; I think the author doesn't understand plpgsql's memory allocation strategy very well. Lastly, and this is maybe a judgement call, I find the changes to PLpgSQL_recfield fairly ugly. It'd be better to make a separate datum type PLpgSQL_dynamic_recfield or some such. This needs to be bounced back for rework. It looks like a first draft that should have been rewritten once the author had learned enough to make it sort-of-work. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
OK, patch reverted, and attached. Would the author please revise? Thanks. It seems like a cool feature. --- Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. I wish to object to this patch; it's poorly designed, poorly coded, and badly documented. The philosophy seems to be I want this feature and I don't care what I have to do to the semantics and performance of plpgsql to get it. In particular I don't like the bits that go /* Do not allow typeids to become narrowed by InvalidOids causing specialized typeids from the tuple restricting the destination */ The incoherence of the comment is a good guide to how poorly thought out the code is. These bits are positioned so that they change the language semantics even when not using a dynamic field reference; what's more, they don't make any sense when you *are* using a dynamic field reference, because you need to keep the actual field type not try (probably vainly) to cast it to whatever the previous field's type was. I also dislike the loop added to exec_eval_cleanup(), which will impose a significant performance penalty on every single expression evaluation done by any plpgsql function, whether it's ever heard of dynamic field references or not. I doubt it's even necessary; I think the author doesn't understand plpgsql's memory allocation strategy very well. Lastly, and this is maybe a judgement call, I find the changes to PLpgSQL_recfield fairly ugly. It'd be better to make a separate datum type PLpgSQL_dynamic_recfield or some such. This needs to be bounced back for rework. It looks like a first draft that should have been rewritten once the author had learned enough to make it sort-of-work. regards, tom lane -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + *** ./doc/src/sgml/plpgsql.sgml.origFri Mar 10 20:10:48 2006 --- ./doc/src/sgml/plpgsql.sgml Mon May 8 23:40:12 2006 *** *** 865,870 --- 865,919 /para para + To obtain the values of the fields the record is made up of, + the record variable can be qualified with the column or field + name. This can be done either by literally using the column name + or the column name for indexing the record can be taken out of a scalar + variable. The syntax for this notation is Record_variable.(IndexVariable). + To get information about the column field names of the record, + a special expression exists that returns all column names as an array: + RecordVariable.(*) . + Thus, the RECORD can be viewed + as an associative array that allows for introspection of it's contents. + This feature is especially useful for writing generic triggers that + operate on records with unknown structure. + Here is an example procedure that shows column names and values + of the predefined record NEW in a trigger procedure: + programlisting + + CREATE OR REPLACE FUNCTION show_associative_records() RETURNS TRIGGER AS $$ + DECLARE + colname TEXT; + colcontent TEXT; + colnamesTEXT[]; + colnINT4; + coliINT4; + BEGIN + -- obtain an array with all field names of the record + colnames := NEW.(*); + RAISE NOTICE 'All column names of test record: %', colnames; + -- show field names and contents of record + coli := 1; + coln := array_upper(colnames,1); + RAISE NOTICE 'Number of columns in NEW: %', coln; + FOR coli IN 1 .. coln LOOP + colname := colnames[coli]; + colcontent := NEW.(colname); + RAISE NOTICE 'column % of NEW: %', quote_ident(colname), quote_literal(colcontent); + END LOOP; + -- Do it with a fixed field name: + -- will have to know the column name + RAISE NOTICE 'column someint of NEW: %', quote_literal(NEW.someint); + RETURN NULL; + END; + $$ LANGUAGE plpgsql; + --CREATE TABLE test_records (someint INT8, somestring TEXT); + --CREATE TRIGGER tr_test_record BEFORE INSERT ON test_records FOR EACH ROW EXECUTE PROCEDURE show_associative_records(); + + /programlisting +/para + +para Note that literalRECORD/ is not a true data type, only a placeholder. One should also realize that when a applicationPL/pgSQL/application function is declared to return type typerecord/, this is not quite the *** ./src/pl/plpgsql/src/pl_comp.c.orig Tue Mar 14 23:48:23 2006 --- ./src/pl/plpgsql/src/pl_comp.c Mon May 8 22:49:50 2006 *** *** 870,876
Re: [PATCHES] [PATCH] Warning about configure args (weaker version)
Patch applied. Thanks. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. Here's a weaker version of the previous patch. Rather than aborting, it simply prints a warning about any unrecognised options, just before the end: checking thread safety of required library functions... yes *** Option ignored: --enable-depends configure: creating ./config.status ...etc... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [PATCH] Improve EXPLAIN ANALYZE overhead by sampling
Patch applied. Thanks. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. This was a suggestion made back in March that would dramatically reduce the overhead of EXPLAIN ANALYZE on queries that loop continuously over the same nodes. http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.php What it does behave normally for the first 50 tuples of any node, but after that it starts sampling at ever increasing intervals, the intervals controlled by an exponential function. So for a node iterating over 1 million tuples it takes around 15,000 samples. The result is that EXPLAIN ANALYZE has a much reduced effect on the total execution time. Without EXPLAIN ANALYZE: postgres=# select count(*) from generate_series(1,100); count - 100 (1 row) Time: 2303.599 ms EXPLAIN ANALYZE without patch: postgres=# explain analyze select count(*) from generate_series(1,100); QUERY PLAN Aggregate (cost=15.00..15.01 rows=1 width=0) (actual time=8022.070..8022.073 rows=1 loops=1) - Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=0) (actual time=1381.762..4873.369 rows=100 loops=1) Total runtime: 8042.472 ms (3 rows) Time: 8043.401 ms EXPLAIN ANALYZE with patch: postgres=# explain analyze select count(*) from generate_series(1,100); QUERY PLAN Aggregate (cost=15.00..15.01 rows=1 width=0) (actual time=2469.491..2469.494 rows=1 loops=1) - Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=0) (actual time=1405.002..2187.417 rows=100 loops=1) Total runtime: 2496.529 ms (3 rows) Time: 2497.488 ms As you can see, the overhead goes from 5.7 seconds to 0.2 seconds. Obviously this is an extreme case, but it will probably help in a lot of other cases people have been complaining about. - To get this close it needs to get an estimate of the sampling overhead. It does this by a little calibration loop that is run once per backend. If you don't do this, you end up assuming all tuples take the same time as tuples with the overhead, resulting in nodes apparently taking longer than their parent nodes. Incidently, I measured the overhead to be about 3.6us per tuple per node on my (admittedly slightly old) machine. Note that the resulting times still include the overhead actually incurred, I didn't filter it out. I want the times to remain reflecting reality as closely as possible. - I also removed InstrStopNodeMulti and made InstrStopNode take a tuple count parameter instead. This is much clearer all round. - I also didn't make it optional. I'm unsure about whether it should be optional or not, given the number of cases where it will make a difference to be very few. - The tuple counter for sampling restarts every loop. Thus a node that is called repeatedly only returning one value each time will still measure every tuple, though its parent node won't. We'll need some field testing to see if that remains a significant effect. - I don't let the user know anywhere how many samples it took. Is this something users should care about? Any comments? -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [DOCS] Proposed doc-patch: Identifying the Current WAL file
Simon, I understand this is only for the 8.1.X and 8.0.X branches. I am hesitant to put something in back branches when the main branch does not have this functionality. I will hold the patch until we are sure where the head branch is going. --- Simon Riggs wrote: On Sun, 2006-04-16 at 15:22 +0100, Simon Riggs wrote: On Sat, 2006-04-15 at 16:20 -0400, Bruce Momjian wrote: Simon Riggs wrote: On Sat, 2006-04-15 at 12:24 -0400, Bruce Momjian wrote: And if we can't provide one, should we supply an SQL function to return the current WAL name? I'll do this. Just give me a few days to get my feet under the new desk. I know its well past time I sorted this and a few other things out. If we get some mechanism to write those partial WAL files, we might not need the ability to identify the current WAL file, and because a new function is going to require an initdb, I am thinking we can't get this done until 8.2 anyway, so Simon, please come up with a plan to finish the missing PITR pieces. I am getting tired of trying to explain workarounds to PITR users, especially when the workarounds are not easy. For 8.0. and 8.1 users, I'd suggest we release an external function as a contrib module, so that we don't compromise reliability and not force an initdb for them. With docs, of course. I suggest we have two functions: 1. pg_xlog_file_from_offset(text) This allows the output of pg_stop_backup to be formatted into a filename, so it would be used like this: select pg_xlog_file_from_offset(pg_stop_backup()); Patch to implement this as a contrib module enclosed. No main manual doc patch yet, awaiting review. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [PATCH] Round 2: Magic block for modules
Patch applied. Thanks. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. Per feedback, here is an updated version. As was pointed out, the prior version was checking stuff that either changed too often to be useful or was never going to change at all. The error reporting is cleaned up too, it now releases the module before throwing the error. It now only checks four things: Major version number (7.4 or 8.1 for example) NAMEDATALEN FUNC_MAX_ARGS INDEX_MAX_KEYS The three constants were chosen because: 1. We document them in the config page in the docs 2. We mark them as changable in pg_config_manual.h 3. Changing any of these will break some of the more popular modules: FUNC_MAX_ARGS changes fmgr interface, every module uses this NAMEDATALEN changes syscache interface, every PL as well as tsearch uses this INDEX_MAX_KEYS breaks tsearch and anything using GiST. I considered others but ultimatly rejected them. For example, HAVE_INT64_TIMESTAMP, while changing the way timestamps are stored and being configurable by a configure option, doesn't actually break anything important (only the btree_gist example in contrib). Any more comments? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
Bruce Momjian pgman@candle.pha.pa.us writes: It seems like a cool feature. The fundamental problem with it is that plpgsql isn't designed to deal with dynamically changing data types. The patch as submitted contained some hacks that sort of dealt with this in some cases (I don't think it covered them all), but really some serious thought is going to have to go into making that work. It'd be good to do, because the existing RECORD-variable feature already creates cases where it's needed; but AFAICS it's not something that can be fixed off-the-cuff. regards, tom lane ---(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] [PATCH] Add support for GnuTLS
Tom Lane wrote: FWIW, Red Hat's legal department thinks that the FSF has overreached in claiming that the GPL is incompatible with OpenSSL's license. Which is why Red Hat isn't worrying about GPL apps that use OpenSSL, of which there are quite a few ... I'm quite happy if we hang onto Red Hat's coat tails on this one. Do we use any GPL libraries other than libreadline? It would be nice to be able to get out of this game altogether - getting libedit up to scratch and portable would be very nice, and I know for a fact that commercial postgres vendors would welcome such a development. cheers andrew ---(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] PL/PGSQL: Dynamic Record Introspection
[EMAIL PROTECTED] said: The patch was now hanging around more than 9 months, and it was already accepted during the original discussion by Neil Conway. Nonsense. I provided some specific code cleanup suggestions and said that I didn't object to the general feature. That should not be taken as an endorsement of everything that I didn't specifically comment on. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [PATCH] Round 2: Magic block for modules
Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. I hadn't gotten around to reviewing the revised version. Just to let you know, I'm going to remove the separate header file pgmagic.h and put the macro into fmgr.h as I'd suggested originally. The reason is that the separate file turns the problem of making backward-compatible modules from a simple #ifdef PG_MAGIC_BLOCK into a big does-that- header-exist autoconf pushup. It's not worth that. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [PATCH] Round 2: Magic block for modules
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. I hadn't gotten around to reviewing the revised version. Is it just me or is this happening a lot lately? cheers andrew ---(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
Re: [PATCHES] [PATCH] Round 2: Magic block for modules
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I hadn't gotten around to reviewing the revised version. Is it just me or is this happening a lot lately? That security stuff took up a *lot* of time behind the scenes :-( Normality is returning, slowly. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection
No, the author would not. Tom did participate in the discussion at the time when the original patch was developed. The patch was now hanging around more than 9 months, and it was already accepted during the original discussion by Neil Conway. Please figure out by yourselves who might be the one to really, really, finally accept the patch. A word about the discussion style in general: I personally don't like general objections on the code *after* I - again - spent some hours of work to comply to Bruce's wish to rewrite the patch for HEAD. After all, Tom, you don't pay me? And I don't like quoting my comments while at the same time complaining about poorly coded software. This simply is nonsense. The other attributes you gave to the patch are simply bad discussion style and at the same time nonsense as well: The patch tries to *minimize* changes to plpgsql and does not deal with fundamental problems of the interpreter. For this reason, of course the patch is more or less a hack. Apparently, the RECORD construct without that patch does not really make much sense; ROWTYPE would suffice. This is why the patch is a cool feature. If now Tom or the community (being identical?) in general have the feeling to start some kind of complete or otherwise fundamental rewrite of plpgsql to handle constructs like the one implemented by me, I suggest someone else should do that. I do not have the time to rewrite plpgsql or to participate in this kind of discussions. Regards Titus Bruce Momjian wrote: OK, patch reverted, and attached. Would the author please revise? Thanks. It seems like a cool feature. --- Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. I wish to object to this patch; it's poorly designed, poorly coded, and badly documented. The philosophy seems to be I want this feature and I don't care what I have to do to the semantics and performance of plpgsql to get it. In particular I don't like the bits that go /* Do not allow typeids to become narrowed by InvalidOids causing specialized typeids from the tuple restricting the destination */ The incoherence of the comment is a good guide to how poorly thought out the code is. These bits are positioned so that they change the language semantics even when not using a dynamic field reference; what's more, they don't make any sense when you *are* using a dynamic field reference, because you need to keep the actual field type not try (probably vainly) to cast it to whatever the previous field's type was. I also dislike the loop added to exec_eval_cleanup(), which will impose a significant performance penalty on every single expression evaluation done by any plpgsql function, whether it's ever heard of dynamic field references or not. I doubt it's even necessary; I think the author doesn't understand plpgsql's memory allocation strategy very well. Lastly, and this is maybe a judgement call, I find the changes to PLpgSQL_recfield fairly ugly. It'd be better to make a separate datum type PLpgSQL_dynamic_recfield or some such. This needs to be bounced back for rework. It looks like a first draft that should have been rewritten once the author had learned enough to make it sort-of-work. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
