[SQL] pgAgent stats
Hi list, does anyone know the reason for pgAdmin not showing the stats neither for selected pgAgent step nor whole job ? The pga_joblog and pga_jobsteplog both get populated with data on run so I was thinking that maybe I'm missing some view associated with statistics tabs ?? Any ideas ? regards mk
Re: [SQL] list of all months
On 2010-03-08, query wrote: > --=_484d28810a276e7b5e461f0328ee205f > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I want to display data for all days in a month even if no data > exists for that month. Some of the days in a month might not have any > data at all. With normal query, we can display days only if data > exists.But I want to display rows for all days in a month with blank > data for non-existing day in database. > > How can this be achieved ? > an outer join to (select FIRST_DAY_OF_MONTH + generate_series(1,DAYS_IN_MONTH) -1 ) where the date columns match FIRST_DAY_OF_MONTH and DAYS_IN_MONTH are to be replaced (by you) with the apropriate expressions by some means, possibly date arithmetic. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
On 15/03/10 23:58, Rob Sargent wrote: Stop me if you've heard this one before :) Given that pg_config --libdir yields "/usr/lib64" to where/what would you expect "AS '$libdir/uuid-ossp', 'uuid_generate_v5'" to resolve? The loader script, ~/tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql, generates "tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql:9: ERROR: could not access file "$libdir/uuid-ossp": No such file or directory" Could it be that $libdir doesn't contain uuid-ossp when the .sql script is being executed? It's also worth checking that the pg_config you are executing is the one associated with postgresql-8.4.2 - make sure your PATH is set appropriately. I'm not sure that it would give this error, but I keep making the mistake of setting my PATH with the three versions I have on my dev box. -- Richard Huxton Archonet Ltd -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] DROP RULE ... CASCADE
Hey all, What objects may depend on the rule (and which of them will removed via cascade rule deletion)? Regards, Dmitriy Igrishin
[SQL] SQL code beautifier for PostgreSQL.
Hey all, Is there any good SQL code beautifier for PostgreSQL to use with Emacs or other text editors? Unfortunately, pg_dump(1) does not format views and rules... It would be nice if we could format unreadable views and rules definitions in favorite editor... Regards, Dmitriy Igrishin
Re: [SQL] DROP RULE ... CASCADE
Dmitriy Igrishin writes: > What objects may depend on the rule (and which of them will removed via > cascade rule deletion)? At present I don't think that a rule can have any dependent objects. The CASCADE option is there for symmetry and future-proofing. (The same goes for some other types of objects, too.) regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] I, nead to capture the IP number from the PC how is running the script ...
On 15 mar 2010, at 20.18, John Dizaro wrote: I, nead to capture the IP number from the PC how is running the script Check the documentation for System Information Functions: http://www.postgresql.org/docs/8.4/interactive/functions-info.html The function inet_client_addr() will return the address of the remote connection. Sincerely, Niklas Johansson -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Rename Index - Deadlock
Hi, Each day I'm recreating the index my_index of the table my_table. Therefore I create a new index my_index_new, drop the old index my_index, and rename the new index: ALTER INDEX my_index_new RENAME TO my_index; If an insert or select statement is run at the same time as the "ALTER INDEX ... RENAME TO" statement, it will end up in a deadlock. The index contains a foreign key (don't know if this information is important). Is this a known issue? Thanks, Thomas -- Thomas Kenner -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Rename Index - Deadlock
Thomas Kenner writes: > Each day I'm recreating the index my_index of the table my_table. Therefore I > create a new index my_index_new, drop the old index my_index, and rename the > new index: > ALTER INDEX my_index_new RENAME TO my_index; > If an insert or select statement is run at the same time as the "ALTER INDEX > ... RENAME TO" statement, it will end up in a deadlock. I doubt it's the RENAME that's the problem, more likely the DROP of the old index. That has to get an exclusive lock on the parent table to be sure there is nothing trying to use the index. Why exactly do you feel you need to do this every day? regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Rename Index - Deadlock
On Tue, Mar 16, 2010 at 3:45 AM, Thomas Kenner wrote: > Hi, > > Each day I'm recreating the index my_index of the table my_table. Therefore I > create a new index my_index_new, drop the old index my_index, and rename the > new index: > ALTER INDEX my_index_new RENAME TO my_index; > > If an insert or select statement is run at the same time as the "ALTER INDEX > ... RENAME TO" statement, it will end up in a deadlock. A deadlock or just a lock? What version of pg? What exact error messages do you get? -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
On 03/16/2010 03:20 AM, Richard Huxton wrote: > On 15/03/10 23:58, Rob Sargent wrote: >> Stop me if you've heard this one before :) >> >> Given that pg_config --libdir yields "/usr/lib64" >> to where/what would you expect >> >>"AS '$libdir/uuid-ossp', 'uuid_generate_v5'" >> >> to resolve? >> >> The loader script, >> ~/tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql, generates >> "tools/postgresql-8.4.2/contrib/uuid-ossp/uuid-ossp.sql:9: ERROR: could >> not access file "$libdir/uuid-ossp": No such file or directory" > > Could it be that $libdir doesn't contain uuid-ossp when the .sql script > is being executed? > > It's also worth checking that the pg_config you are executing is the one > associated with postgresql-8.4.2 - make sure your PATH is set > appropriately. I'm not sure that it would give this error, but I keep > making the mistake of setting my PATH with the three versions I have on > my dev box. > Thanks for your suggestions. You were exactly right. I was pointed at an 8.3 server in the hinterland, not my own. Terribly sorry for the noise. (Of course that fact was staring at me from the sql prompt, which contains servername :/) I'm still left worried about the correct procedure for getting uuid-oosp installed properly on SUSE 11. Does the server release's contrib contain uuid-ossp? I didn't see it on my desktop release. (I don't want to have to tell my mates to go through the issues I had building the lib etc.) Now I have to clean up after myself for having dropped links to that .so everywhere! Thanks again. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Avoiding cycles in a directed graph
I'm using the following table to represent an acyclic directed graph: CREATE TABLE edge( id SERIAL PRIMARY KEY, child INTEGER NOT NULL, parent INTEGER, UNIQUE (child, parent) ); I see there is an example in the online docs for detecting cycles in recursive queries, and I've adapted the example query to the table above: WITH RECURSIVE search_graph(parent, child, id, depth, path, cycle) AS ( SELECT e.parent, e.child, e.id, 1, ARRAY[e.id], false FROM edge e UNION ALL SELECT e.parent, e.child, e.id, sg.depth + 1, path || e.id, e.id = ANY(path) FROM edge e, search_graph sg WHERE e.parent = sg.child AND NOT cycle ) SELECT * FROM search_graph; That's great to avoid looping forever on queries, but what about preventing anyone from inserting edges that would create cycles in the first place? I reckon I'll need a trigger of some sort, but nothing I've tried has enabled me to do the cycle check as part of the trigger to avoid inserting an edge that would create a cycle. I tried having the non-recursive SELECT use NEW.parent, NEW.child, etc. but that isn't working. Is there any way to do this, or do I have to just insert the edge, check if it cycles, and delete it if it does? Thanks. -Tony -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
On 16/03/10 18:08, Rob Sargent wrote: I'm still left worried about the correct procedure for getting uuid-oosp installed properly on SUSE 11. Does the server release's contrib contain uuid-ossp? I didn't see it on my desktop release. (I don't want to have to tell my mates to go through the issues I had building the lib etc.) I'd be surprised if there wasn't a -contrib or -extras rpm with the relevant files. The community rpms should have them if the "official" Suse ones don't -- Richard Huxton Archonet Ltd -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
On 16/03/10 19:45, Tony Cebzanov wrote: I'm using the following table to represent an acyclic directed graph: [snip] I see there is an example in the online docs for detecting cycles in recursive queries, and I've adapted the example query to the table above: [snip] That's great to avoid looping forever on queries, but what about preventing anyone from inserting edges that would create cycles in the first place? I reckon I'll need a trigger of some sort, but nothing I've tried has enabled me to do the cycle check as part of the trigger to avoid inserting an edge that would create a cycle. You've got the right idea. If you know that the table doesn't contain any cycles at the moment, then all the trigger has to do is: 1. Check "parent" <> "child" 2. Build the set of parents of "parent". 3. Check "child" isn't in that set. 4. If there is a cycle, raise an error (which will abort the insert or update) If you have a "before" trigger, then step 4 could return NULL rather than raise an error. That would just skip the insert. Also, step #1 could be done with a CHECK constraint which would be checked before your trigger gets run. -- Richard Huxton Archonet Ltd -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
Richard Huxton writes: > On 16/03/10 18:08, Rob Sargent wrote: >> I'm still left worried about the correct procedure for getting uuid-oosp >> installed properly on SUSE 11. Does the server release's contrib >> contain uuid-ossp? I didn't see it on my desktop release. (I don't >> want to have to tell my mates to go through the issues I had building >> the lib etc.) > I'd be surprised if there wasn't a -contrib or -extras rpm with the > relevant files. The community rpms should have them if the "official" > Suse ones don't If there is a contrib rpm but it doesn't seem to contain uuid-ossp, the likely reason is that the maintainer never got around to adding --with-ossp-uuid to the build options. (I know it took me a while to add that to the Fedora build :-(.) You could confirm or deny that theory by looking at the output of pg_config --configure. If so, file a bug report with SUSE asking for that to be added. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
Richard Huxton writes: > On 16/03/10 19:45, Tony Cebzanov wrote: >> That's great to avoid looping forever on queries, but what about >> preventing anyone from inserting edges that would create cycles in the >> first place? I reckon I'll need a trigger of some sort, but nothing >> I've tried has enabled me to do the cycle check as part of the trigger >> to avoid inserting an edge that would create a cycle. > You've got the right idea. > If you know that the table doesn't contain any cycles at the moment, > then all the trigger has to do is: > 1. Check "parent" <> "child" > 2. Build the set of parents of "parent". > 3. Check "child" isn't in that set. > 4. If there is a cycle, raise an error (which will abort the insert or > update) The problem with this approach is that it's not safe against concurrent insertions. If concurrent transactions T1 and T2 each insert a row that, taken together (and in combination with existing entries), create a cycle, then neither of their triggers will see the other's row so they'll both think they can commit. The same kind of problem exists for unique and foreign key constraints, both of which use low-level locking mechanisms to catch such cases. There's no way that I can see to express the "no cycle" constraint as a uniqueness constraint unfortunately. You could solve limited forms of it using the exclusion-constraint mechanism that's new in 9.0, but AFAICS not the general case :-( regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
On 3/16/10 4:34 PM, Tom Lane wrote: > The same kind of problem exists for unique and foreign key constraints, > both of which use low-level locking mechanisms to catch such cases. > There's no way that I can see to express the "no cycle" constraint as a > uniqueness constraint unfortunately. You could solve limited forms of > it using the exclusion-constraint mechanism that's new in 9.0, but > AFAICS not the general case :-( Are you saying there's no way to avoid cycles at all, or just no way to do it using uniqueness constraints? I'm okay with running the big, fat WITH RECURSIVE query in my insert trigger if I have to -- it won't be great for performance, but I don't expect this to be a frequent operation, so I'll accept the performance hit if it works. Unfortunately I can't even get that working. Here's the (not at all functional) trigger I've got right now, which only detects the cycle *after* it's been inserted, which is of no help at all. Any way I can modify this to do the right thing? CREATE OR REPLACE FUNCTION check_edge_cycle() RETURNS trigger AS $$ DECLARE cycles INTEGER; BEGIN WITH RECURSIVE search_graph(parent, child, id, depth, path, cycle) AS ( SELECT NEW.parent, NEW.child, NEW.id, 1, ARRAY[NEW.id], false UNION ALL SELECT g.parent, g.child, g.id, sg.depth + 1, path || g.id, g.id = ANY(path) FROM catalog_edge g, search_graph sg WHERE g.parent = sg.child AND NOT cycle ) SELECT INTO cycles COUNT(*) FROM search_graph WHERE cycle=true; RAISE NOTICE 'cycles: %', cycles; IF cycles > 0 THEN RAISE EXCEPTION 'cycle'; END IF; RETURN NEW; END $$ LANGUAGE plpgsql; -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
Tony Cebzanov writes: > I'm okay with running the big, fat WITH RECURSIVE query in my insert > trigger if I have to -- it won't be great for performance, but I don't > expect this to be a frequent operation, so I'll accept the performance > hit if it works. > Unfortunately I can't even get that working. Here's the (not at all > functional) trigger I've got right now, which only detects the cycle > *after* it's been inserted, which is of no help at all. Any way I can > modify this to do the right thing? Run it in an AFTER trigger? If you don't expect this to be common, maybe you could fix the concurrency issue by taking a table-wide lock that locks out other writers. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
On 16/03/10 21:09, Tom Lane wrote: Tony Cebzanov writes: I'm okay with running the big, fat WITH RECURSIVE query in my insert trigger if I have to -- it won't be great for performance, but I don't expect this to be a frequent operation, so I'll accept the performance hit if it works. Unfortunately I can't even get that working. Here's the (not at all functional) trigger I've got right now, which only detects the cycle *after* it's been inserted, which is of no help at all. Any way I can modify this to do the right thing? Run it in an AFTER trigger? If you don't expect this to be common, maybe you could fix the concurrency issue by taking a table-wide lock that locks out other writers. Surely SELECT FOR UPDATE on the parents would be sufficient? If there's no overlap between (currently non-cyclic) graphs being altered then there can't be any conflict. -- Richard Huxton Archonet Ltd -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Avoiding cycles in a directed graph
Richard Huxton writes: > On 16/03/10 21:09, Tom Lane wrote: >> If you don't expect this to be common, maybe you could fix the >> concurrency issue by taking a table-wide lock that locks out >> other writers. > Surely SELECT FOR UPDATE on the parents would be sufficient? If there's > no overlap between (currently non-cyclic) graphs being altered then > there can't be any conflict. Um, what if the cycle is being formed from whole cloth? For instance T1 inserts an edge A->B while T2 is inserting B->A. There are no pre-existing rows to lock, but there will still be a cycle after they both commit. Also it seems pretty deadlock-prone if there are multiple existing rows to try to lock. Perhaps you could work around the risk by locking those rows one at a time in an application-defined ordering ... but I'm afraid the performance would be poor, unless the connected graphs are always very small. On the whole I think Tony's better off with a KISS approach, ie just lock the whole table against other writers. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
On 03/16/2010 02:26 PM, Tom Lane wrote: > Richard Huxton writes: >> On 16/03/10 18:08, Rob Sargent wrote: >>> I'm still left worried about the correct procedure for getting uuid-oosp >>> installed properly on SUSE 11. Does the server release's contrib >>> contain uuid-ossp? I didn't see it on my desktop release. (I don't >>> want to have to tell my mates to go through the issues I had building >>> the lib etc.) > >> I'd be surprised if there wasn't a -contrib or -extras rpm with the >> relevant files. The community rpms should have them if the "official" >> Suse ones don't > > If there is a contrib rpm but it doesn't seem to contain uuid-ossp, > the likely reason is that the maintainer never got around to adding > --with-ossp-uuid to the build options. (I know it took me a while > to add that to the Fedora build :-(.) You could confirm or deny > that theory by looking at the output of pg_config --configure. > If so, file a bug report with SUSE asking for that to be added. > > regards, tom lane As Tom suspected the SUSE build doesn't name ossp stuff, to wit: $ pg_config BINDIR = /usr/bin DOCDIR = /usr/share/doc/packages/postgresql HTMLDIR = /usr/share/doc/packages/postgresql INCLUDEDIR = /usr/include/pgsql PKGINCLUDEDIR = /usr/include/pgsql INCLUDEDIR-SERVER = /usr/include/pgsql/server LIBDIR = /usr/lib64 PKGLIBDIR = /usr/lib64/postgresql LOCALEDIR = /usr/share/locale MANDIR = /usr/share/man SHAREDIR = /usr/share/postgresql SYSCONFDIR = /usr/etc/postgresql PGXS = /usr/lib64/postgresql/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--prefix=/usr' '--libdir=/usr/lib64' '--bindir=/usr/bin' '--includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql' '--mandir=/usr/share/man' '--docdir=/usr/share/doc/packages' '--disable-rpath' '--enable-nls' '--enable-thread-safety' '--enable-integer-datetimes' '--without-python' '--without-perl' '--without-tcl' '--with-openssl' '--with-pam' '--with-krb5' '--with-gssapi' '--with-ldap' '--with-libxml' '--with-libxslt' '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g ' CC = gcc CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2 CFLAGS = -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv CFLAGS_SL = -fpic LDFLAGS = -Wl,--as-needed LDFLAGS_SL = LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lz -lreadline -lcrypt -ldl -lm VERSION = PostgreSQL 8.4.2 And I guess --without-perl explains some the machinations necessary to get bucardo working. Thanks to all. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
Rob Sargent writes: > As Tom suspected the SUSE build doesn't name ossp stuff, to wit: > CONFIGURE = '--prefix=/usr' '--libdir=/usr/lib64' '--bindir=/usr/bin' > '--includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql' > '--mandir=/usr/share/man' '--docdir=/usr/share/doc/packages' > '--disable-rpath' '--enable-nls' '--enable-thread-safety' > '--enable-integer-datetimes' '--without-python' '--without-perl' > '--without-tcl' '--with-openssl' '--with-pam' '--with-krb5' > '--with-gssapi' '--with-ldap' '--with-libxml' '--with-libxslt' > '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-fmessage-length=0 > -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables -g ' --without-perl? --without-python? What are these people thinking? (Personally I don't like --without-tcl either, but I know not so many people care about that one anymore.) File an RFE, or find a more clueful distro. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] installing uuid generators
Perl and Python are external packages, not part of the main package. Here's the list: S | Name | Summary | Type --++-+--- i | postgresql | Basic Clients and Utilities for PostgreSQL | package | postgresql | Basic Clients and Utilities for PostgreSQL | srcpackage i | postgresql | postgresql security update | patch i | postgresql-contrib | Contributed Extensions and Additions to PostgreSQL | package i | postgresql-devel | PostgreSQL development header files and libraries | package i | postgresql-docs| HTML Documentation for PostgreSQL | package | postgresql-ip4r| IPv4 and IPv4 range index types for PostgreSQL | srcpackage | postgresql-ip4r| IPv4 and IPv4 range index types for PostgreSQL | package | postgresql-jdbc| JDBC Drivers for PostgreSQL | package | postgresql-jdbc| JDBC Drivers for PostgreSQL | srcpackage i | postgresql-libs| Shared Libraries Required for PostgreSQL Clients| package | postgresql-libs-32bit | Shared Libraries Required for PostgreSQL Clients| package | postgresql-pl | The PL/Tcl, PL/Perl, and PL/Python Procedural Languages for PostgreSQL | srcpackage | postgresql-plperl | The PL/Tcl, PL/Perl, and PL/Python procedural languages for PostgreSQL | package i | postgresql-plpython| The PL/Python Procedural Languages for PostgreSQL | package | postgresql-pltcl | PL/Tcl Procedural Language for PostgreSQL | package i | postgresql-server | The Programs Needed to Create and Run a PostgreSQL Server | package | python-storm-postgresql| PostgreSQL backend for python-storm | package And no, uuid-ossp isn't there. -- Jorge Godoy On Tue, Mar 16, 2010 at 20:29, Tom Lane wrote: > Rob Sargent writes: > > As Tom suspected the SUSE build doesn't name ossp stuff, to wit: > > > CONFIGURE = '--prefix=/usr' '--libdir=/usr/lib64' '--bindir=/usr/bin' > > '--includedir=/usr/include/pgsql' '--datadir=/usr/share/postgresql' > > '--mandir=/usr/share/man' '--docdir=/usr/share/doc/packages' > > '--disable-rpath' '--enable-nls' '--enable-thread-safety' > > '--enable-integer-datetimes' '--without-python' '--without-perl' > > '--without-tcl' '--with-openssl' '--with-pam' '--with-krb5' > > '--with-gssapi' '--with-ldap' '--with-libxml' '--with-libxslt' > > '--with-system-tzdata=/usr/share/zoneinfo' 'CFLAGS=-fmessage-length=0 > > -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > > -fasynchronous-unwind-tables -g ' > > --without-perl? --without-python? What are these people thinking? > (Personally I don't like --without-tcl either, but I know not so > many people care about that one anymore.) > > File an RFE, or find a more clueful distro. > >regards, tom lane > > -- > Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-sql >
