Re: [PATCHES] still alive?
Simon Riggs wrote: On Thu, 2008-09-11 at 15:39 +0300, Peter Eisentraut wrote: Bruce Momjian wrote: Abhijit Menon-Sen wrote: I thought -patches was supposed to die. What happened? I was wondering the same thing. Peter? Hmm, let's try this: Anyone who thinks the patches list should remain as separate from hackers, shout now (with rationale)! Kill it now, long enough before the next patchfest for it to stick. I think what we need now, for patches, ports, and the others, is someone to actually kill it. All the talk has been talked, everything has been decided, now someone with the right permission bits just turn it off. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] still alive?
Bruce Momjian wrote: Abhijit Menon-Sen wrote: I thought -patches was supposed to die. What happened? I was wondering the same thing. Peter? Hmm, let's try this: Anyone who thinks the patches list should remain as separate from hackers, shout now (with rationale)! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Am Freitag, 4. Juli 2008 schrieb Tom Raney: Regarding the XML datum, in order to support that, will all users need to compile with libxml? Are there any lighter weight solutions to serialize other than libxml? You can create XML without libxml. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Regression test database name
For some experiments I wanted to run the regression tests using a different
database (possibly using pg_regress --dbname=), but the name regression is
hardcoded in a few places. It's trivial to fix, see attached patch. Quick
explanation: The fact that psql's \z prints the database name has always been
an inconsistency, so it's good to get rid of anyway. The majority of the
diff in prepare.out is whitespace differences. Objections?
diff -ur ../cvs-pgsql/doc/src/sgml/ref/grant.sgml ./doc/src/sgml/ref/grant.sgml
--- ../cvs-pgsql/doc/src/sgml/ref/grant.sgml 2008-06-08 10:31:25.0 +0200
+++ ./doc/src/sgml/ref/grant.sgml 2008-07-01 16:06:32.0 +0200
@@ -419,7 +419,7 @@
to obtain information about existing privileges, for example:
programlisting
=gt; \z mytable
- Access privileges for database lusitania
+Access privileges
Schema | Name | Type | Access privileges
+-+---+--
public | mytable | table | miriam=arwdxt/miriam
diff -ur ../cvs-pgsql/src/bin/psql/describe.c ./src/bin/psql/describe.c
--- ../cvs-pgsql/src/bin/psql/describe.c 2008-06-08 10:31:43.0 +0200
+++ ./src/bin/psql/describe.c 2008-07-01 16:05:32.0 +0200
@@ -515,8 +515,7 @@
}
myopt.nullPrint = NULL;
- printfPQExpBuffer(buf, _(Access privileges for database \%s\),
- PQdb(pset.db));
+ printfPQExpBuffer(buf, _(Access privileges));
myopt.title = buf.data;
myopt.trans_headers = true;
myopt.trans_columns = trans_columns;
diff -ur ../cvs-pgsql/src/test/regress/expected/dependency.out ./src/test/regress/expected/dependency.out
--- ../cvs-pgsql/src/test/regress/expected/dependency.out 2008-06-08 10:32:04.0 +0200
+++ ./src/test/regress/expected/dependency.out 2008-07-01 16:12:04.0 +0200
@@ -68,7 +68,7 @@
GRANT ALL ON deptest1 TO regression_user2;
RESET SESSION AUTHORIZATION;
\z deptest1
-Access privileges for database regression
+ Access privileges
Schema | Name | Type | Access privileges
+--+---+
public | deptest1 | table | regression_user0=arwdxt/regression_user0
@@ -79,7 +79,7 @@
DROP OWNED BY regression_user1;
-- all grants revoked
\z deptest1
- Access privileges for database regression
+ Access privileges
Schema | Name | Type |Access privileges
+--+---+--
public | deptest1 | table | regression_user0=arwdxt/regression_user0
diff -ur ../cvs-pgsql/src/test/regress/expected/prepare.out ./src/test/regress/expected/prepare.out
--- ../cvs-pgsql/src/test/regress/expected/prepare.out 2008-06-08 10:32:05.0 +0200
+++ ./src/test/regress/expected/prepare.out 2008-07-01 16:14:37.0 +0200
@@ -16,7 +16,7 @@
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
--+--+-
- q1 | PREPARE q1 AS SELECT 1 AS a; | {}
+ q1 | PREPARE q1 AS SELECT 1 AS a; | {}
(1 row)
-- should fail
@@ -35,8 +35,8 @@
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
--+--+-
- q1 | PREPARE q1 AS SELECT 2; | {}
- q2 | PREPARE q2 AS SELECT 2 AS b; | {}
+ q1 | PREPARE q1 AS SELECT 2; | {}
+ q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)
-- sql92 syntax
@@ -44,7 +44,7 @@
SELECT name, statement, parameter_types FROM pg_prepared_statements;
name | statement | parameter_types
--+--+-
- q2 | PREPARE q2 AS SELECT 2 AS b; | {}
+ q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(1 row)
DEALLOCATE PREPARE q2;
@@ -58,10 +58,10 @@
PREPARE q2(text) AS
SELECT datname, datistemplate, datallowconn
FROM pg_database WHERE datname = $1;
-EXECUTE q2('regression');
- datname | datistemplate | datallowconn
-+---+--
- regression | f | t
+EXECUTE q2('postgres');
+ datname | datistemplate | datallowconn
+--+---+--
+ postgres | f | t
(1 row)
PREPARE q3(text, int, float, boolean, oid, smallint) AS
@@ -71,35 +71,35 @@
EXECUTE q3('xx', 5::smallint, 10.5::float, false, 500::oid, 4::bigint);
unique1 | unique2 | two | four | ten | twenty | hundred | thousand | twothousand | fivethous | tenthous | odd | even | stringu1 | stringu2 | string4
-+-+-+--+-++-+--+-+---+--+-+--+--+--+-
- 2 |2716 | 0 |2 | 2 | 2 | 2 |2 | 2 |
Re: [PATCHES] Explain XML patch v2
Am Mittwoch, 2. Juli 2008 schrieb Tom Raney: This is an update to my EXPLAIN XML patch submitted a few days ago. Could you explain how you came up with the XML schema design? I suppose you just made something up that went along with the existing XML output. I would like to see more integration with the spirit of the existing XML functionality. For example, instead of things like runtime ms=\%.3f\ /\n we ought to be using XML Schema data types for time intervals and so on. We might also want to use an XML namespace. Table and index names should be escaped using the existing escape mechanism for identifiers. There might also be encoding issues. It would also be interesting if EXPLAIN could optionally be a function that returns a datum of type XML, to allow further processing. Any thoughts on these issues? -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Updatable views
Am Donnerstag, 8. Mai 2008 schrieb Simon Riggs: CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ... which seems straightforward, no? Double evaluation is the key word. The conclusion was more or less that you can't implement check constraints using the rules system. You need to check them in the executor. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] column level privileges
Am Mittwoch, 7. Mai 2008 schrieb Tom Lane: 1.1 Add a column named 'attrel' in pg_attribute catalog to store column privileges. Now all column privileges are stored, no matter whether they could be implied from table-level privilege. What this actually means, but doesn't say, is that there's no table-level representation of INSERT/UPDATE privilege any more at all. I think this is a pretty fundamental design error. In the first place it bloats pg_attribute with data that's entirely redundant for the typical case where per-column privileges aren't used. In the second place it slows privilege checking for the typical case, since instead of one check for the relation you have to do one for each attribute. There are some other problems too, like having to extend pg_shdepend to include an objsubid column, and some other places where the patch has to do awkward things because it's now lacking table-level information about privilege checks. I haven't read the patch, but there is also a semantic issue, namely what happens to columns added after the grant. If the GRANT was to the table, new columns should get the same privileges. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] bug in numeric_power() function
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have developed the attached patch which fixes 0 ^ 123.3. Did you actually read the wikipedia entry you cited? Considering that 0::float8 ^ 0::float8 yields 1, making the numeric operator do the same might not be completely unreasonable, but I find the rationale that it is better for discrete mathematics fairly ludicrous on multiple levels. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [COMMITTERS] pgsql: Sigh ...
Andrew Dunstan wrote: This patch should fix things for both sets of changes. And it demonstrates pretty much what you need to do for config options for MSVC. Btw., it is quite easily possible to use the autom4te tracing facility to parse the configure.ac file, in case you are interested in generating some of the Windows build code automatically. For example: $ autoconf -t 'AC_ARG_ENABLE:$1' configure.in integer-datetimes nls shared rpath spinlocks debug profiling dtrace segmented-files depend cassert thread-safety thread-safety thread-safety-force largefile Let me know if you want to do something with that. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Exposing keywords to clients
Dave Page wrote: Perhaps use a separate string for machine parse (say R, T, C, U), and let the string be translatable. I considered that, but wasn't sure if folks would like the redundancy. It's trivial to do of course - any objections? Is there anything useful you would do with this information? Or would you just quote all listed words anyway? -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Coding standards
Alvaro Herrera wrote: The developer's FAQ is supposed to contain this kind of thing, but I think it's rather thin on actual details. (Some time ago it was proposed to create a style guide, but people here thought it was a waste of time and it will not cover what's really important, so we're stuck with repeating the advice over and over.) Excellent wiki material ... -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
Bruce Momjian wrote: I checked the use of COLUMNS and it seems bash updates the environment variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS isn't set. We already had a call in print.c for detecting the number of rows on the screen to determine if the pager should be used. Seems COLUMNS should take precedence over ioctl(), right? Considering that the code to determine the row count is undisputed so far, the column count detection should work the same. That is, we might not need to look at COLUMNS at all. Unless there is a use case for overriding the column count (instead of just turning off the wrapping). -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
Am Donnerstag, 3. April 2008 schrieb Gregory Stark: To be more explicit what I meant was someone doing #= \alias old select version(); ... #= \oldd oops #= \old #= select 'where is all my output going?' #= select 'what happened to my ldd file?' This is a valid concern, but it is orthogonal to the alias feature. You have the same problem already if you mistype \oo instead of \o \ofoo instead of \obar \o instead of \p \oset instead of \pset or even more amusingly \o foo instead of \i foo -- check your keyboard layout and so on. If you want to guard against typos, you need to remove the \o command in its current form. Prohibiting the addition of new commands, by whichever means, is not going to help. And we have never had a policy or real analysis whether new or existing commands are typo-proof. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
Am Donnerstag, 3. April 2008 schrieb Gregory Stark: \old means something *today*. In the proposed syntax by creating the alias you're changing what it means. Yes. There are two complementary responses to that: 1. That's an intentional, useful feature of aliases. 2. If you don't like it, don't use it. By your line of argument, we couldn't ever add any new commands in psql anyway. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] psql command aliases support
Am Donnerstag, 3. April 2008 schrieb Brendan Jurd: psql allows you to omit the space between the command and argument? Does anybody else find that weird? What is the virtue of allowing such a syntax in the first place? Combatability with hysterial practice. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Changes to building dynamically loadable modules
The attached patch implements a few changes to how shared libraries and dynamically loadable modules are built. Foremost, it creates a solid distinction between these two types of targets based on what had already been implemented and duplicated in ad hoc ways before. Specifically, - Dynamically loadable modules no longer get a soname. The numbers previously set in the makefiles were dummy numbers anyway, and the presence of a soname upset a few packaging tools, so it is nicer not to have one. - The cumbersome detour taken on installation (build a libfoo.so.0.0.0 and then override the rule to install foo.so instead) is removed. - Lots of duplicated code simplified. diff --git a/src/Makefile.shlib b/src/Makefile.shlib index ba488d5..75b2494 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -19,13 +19,18 @@ # variables: # # NAME Name of library to build (no suffix nor lib prefix) -# SO_MAJOR_VERSION Major version number to use for shared library -# SO_MINOR_VERSION Minor version number to use for shared library # OBJS List of object files to include in library # SHLIB_LINKIf shared library relies on other libraries, # additional stuff to put in its link command # SHLIB_EXPORTS (optional) Name of file containing list of symbols to # export +# +# When building a shared library, the following version information +# must also be set. It should be omitted when building a dynamically +# loadable module. +# +# SO_MAJOR_VERSION Major version number to use for shared library +# SO_MINOR_VERSION Minor version number to use for shared library # (If you want a patchlevel, include it in SO_MINOR_VERSION, e.g., 6.2.) # # Optional flags when building DLL's (only applicable to win32 and cygwin @@ -42,6 +47,7 @@ # # all-lib build the static and shared (if applicable) libraries # install-lib install the libraries into $(libdir) +# installdirs-lib create installation directory $(libdir) # uninstall-lib remove the libraries from $(libdir) # clean-lib delete the static and shared libraries from the build dir # maintainer-clean-lib delete .def files built for win32 @@ -72,18 +78,34 @@ LINK.static = $(AR) $(AROPT) -ifeq ($(enable_shared), yes) - # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) # Need a -L-free version of LDFLAGS to use in combination with SHLIB_LINK LDFLAGS_NO_L = $(filter-out -L%, $(LDFLAGS)) -# Default shlib naming convention used by the majority of platforms +ifdef SO_MAJOR_VERSION +# Default library naming convention used by the majority of platforms +ifeq ($(enable_shared), yes) shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) shlib_major = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) shlib_bare = lib$(NAME)$(DLSUFFIX) +endif +# Testing the soname variable is a reliable way to determine whether a +# linkable library is being built. +soname = $(shlib_major) +stlib = lib$(NAME).a +else +# Naming convention for dynamically loadable modules +ifeq ($(enable_shared), yes) +shlib = $(NAME)$(DLSUFFIX) +endif +endif + +ifndef soname +# additional flags for backend modules +SHLIB_LINK := $(BE_DLLLIBS) $(SHLIB_LINK) +endif # For each platform we support shared libraries on, set shlib to the # name of the library (if default above is not right), set @@ -94,29 +116,29 @@ shlib_bare = lib$(NAME)$(DLSUFFIX) override CFLAGS += $(CFLAGS_SL) -soname = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) - ifeq ($(PORTNAME), aix) - shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) + ifdef SO_MAJOR_VERSION +shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) + endif haslibarule = yes exports_file = lib$(NAME).exp endif ifeq ($(PORTNAME), darwin) - ifneq ($(SO_MAJOR_VERSION), 0) -version_link = -compatibility_version $(SO_MAJOR_VERSION) -current_version $(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) - endif - ifeq ($(DLTYPE), library) + ifdef soname # linkable library DLSUFFIX = .dylib +ifneq ($(SO_MAJOR_VERSION), 0) + version_link = -compatibility_version $(SO_MAJOR_VERSION) -current_version $(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) +endif LINK.shared = $(COMPILER) -dynamiclib -install_name $(libdir)/lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX) $(version_link) $(exported_symbols_list) -multiply_defined suppress +shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX) +shlib_major = lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX) else -# loadable module (default case) +# loadable module DLSUFFIX = .so LINK.shared = $(COMPILER) -bundle -multiply_defined suppress endif - shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX) - shlib_major =
Re: [PATCHES] psql command aliases support
Am Dienstag, 1. April 2008 schrieb Tom Lane: Do we really want such a thing? Yes! The space of backslash command names is so densely populated already that it's hard to imagine creating aliases without conflicting with existing (or future) command names --- as indeed your example does. It seems like mostly a recipe for confusion. This is a standard feature and effect on shells. Shells have even more likely commands and conflicts, and still aliases are widely used. If people are concerned about conflicts, they shouldn't use aliases. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
Zdenek Kotala wrote: But how it was mentioned in this thread maybe somethink like this CREATE TABLESPACE name LOCATION '/my/location' SEGMENTS 10GB should good solution. If segments is not mentioned then default value is used. I think you would need a tool to resegmentize a table or tablespace offline, usable for example when recovering a backup. Also, tablespace configuration information is of course also stored in a table. pg_tablespace probably won't become large, but it would probably still need to be special-cased, along with other system catalogs perhaps. An then, how to coordindate offline resegmenting and online tablespace operations in a crash-safe way? Another factor I just thought of is that tar, commonly used as part of a backup procedure, can on some systems only handle files up to 8 GB in size. There are supposed to be newer formats that can avoid that restriction, but it's not clear how widely available these are and what the incantation is to get at them. Of course we don't use tar directly, but if we ever make large segments the default, we ought to provide some clear advice for the user on how to make their backups. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] DTrace probe patch for OS X Leopard
Am Donnerstag, 6. März 2008 schrieb Robert Lor: Attached is the updated patch which addressed all the concerns from Peter and Tom. * The header file containing the probe macros is now included only in the .c files that need it. * All probe macro names now start with TRACE_ (eg: TRACE_POSTGRESQL_TRANSACTION_START). Patch applied. I also added a small sed script that generates the dummy probes.h file automatically, so it doesn't need to be manually maintained. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Suppress compiler warnings on mingw
ITAGAKI Takahiro wrote: DWORD is an alias for 'unsigned long' in 32bit Windows. Then try using %lu and no casts. That should get rid of the warnings the proper way. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Suppress compiler warnings on mingw
ITAGAKI Takahiro wrote: - Cast DWORD to unsigned integer explicitly. DWORD is always 32bit integer on both 32bit and 64bit Windows. I think if that is so, you wouldn't need to add any casts. Instead you would only need to use the right format specifier. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
Tom Lane wrote: I think this needs to be treated as experimental until it's got a few more than zero miles under its belt. OK, then maybe we should document that. I wouldn't be too surprised to find that we have to implement it as a run-time switch instead of compile-time, in order to not fail miserably when somebody sticks a tablespace on an archaic filesystem. Yes, that sounds quite useful. Let's wait and see what happens. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
Zdenek Kotala wrote: Yes, agree. It seems only ZFS is OK at this moment and if somebody sets 32TB he gets nonsegment mode anyway. Surely if you set the segment size to INT64_MAX, you will get nonsegmented behavior anyway, so two code paths might not be necessary at all. I looked into posix standard and there is useful function which can be used. See http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html Maybe we can put additional test into configure and collect appropriate data from buildfarm. It might be good to just check first if it returns realistic values for the example cases that have been mentioned. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: There is latest version of nonsegment support patch. I changed LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added -disable-segmented-files switch to configure. I kept tuplestore behavior and it still split file in both mode. Applied with minor corrections. Why is this not the default when supported? I am wondering both from the point of view of the user, and in terms of development direction. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%'
Am Donnerstag, 6. März 2008 schrieb Tom Lane: To help out Peter's client, who's running 8.1.x, we'd have to backpatch at least that far. We backpatched the last round of LIKE selectivity fixes to 8.1, so I don't have too much hesitation about doing the same here. Thanks for the offer. Personally, I'd be OK with not backpatching and dealing with the patch myself. We've patched that area before, but I'm not sure what the original cause of that was, but this here sounds more like a feature improvement. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] DTrace probe patch for OS X Leopard
Am Freitag, 29. Februar 2008 schrieb Robert Lor: My concern is that when we start adding more probes (not just the backend), we will have to add the following 5 lines in .c files that use the Dtrace macros. I had already solved this in my intermediate patch I sent you by symlinking probes_null.h to probes.h. ---(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] DTrace probe patch for OS X Leopard
Am Freitag, 29. Februar 2008 schrieb Robert Lor: Currently, pg_trace.h is included in c.h, and I feel strongly that it should remains there because by design I'd like to 1) have the tracing feature be available both in the frontend and backend without having to do anything extra, I think each component would have its own probes definition file. which also means that probes.h needs to be generated before any compilation Well, you are going to have to do a lot more work on the makefiles if you want to do it that way. Make works by defining dependencies between files, not by hoping that people will execute the commands in the order you write them. If you want every single file in the tree to depend on a rule, you will have to do something different. 2) centralize the include of this header just in case the implementation needs to be changed for some reason (eg, if this file needs to be splitted, etc) We have no evidence that anything like that will ever happen. 3) reduce the number of changes to a minimal when adding new probes to new .c files These arguments seem irrelevant in my mind. When you add new function calls, you will usually have to add new header files as well. It's the normal way to do things. I haven't heard any major disadvantages about keeping it in c.h, but if you are still adamant about keeping it out of c.h, I'll will go along with that. Including only what you need is a principle. It keeps the namespace clean, it speads up compilation time, it makes the build system simpler and more efficient. Otherwise we'd only need one header file for everything. ---(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] DTrace probe patch for OS X Leopard
Robert Lor wrote: dtrace call in src/Makefile is to generate probes.h before any file is compiled so it can be used in c.h to avoid probes.h not found error. The dtrace call in src/backend/Makefile is only needed for Solaris. Is c.h the right place to include this? The probes are only in the backend code, so perhaps postgres.h would be more appropriate. Or just include it in the .c files that need it, of which there are only 3. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] DTrace probe patch for OS X Leopard
Robert Lor wrote: 3) Note on src/backend/Makefile The current rule below does not work. After expansion, utils/probes.d needs to come right after -s, but currently it shows up at the end after all the .o files. I fixed that part. Note again that a buildfarm animal testing the dtrace support could be helpful. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] DTrace probe patch for OS X Leopard
Robert Lor wrote: Please find the patch attached per this thread http://archives.postgresql.org/pgsql-hackers/2008-02/msg00912.php Why do we have two dtrace calls in the makefiles now? I understand you added the new mechanism to support Mac OS X, but doesn't Solaris support that mechanism as well, so the old one could be dropped? Btw., probes_null.h is missing in your patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] DTrace probe patch for OS X Leopard
Robert Lor wrote:
2) Need help figuring out how to copy src/backend/util/probes.d from src
tree to
bld tree at build time. It works fine if compilation is done in the src
tree.
I have reworked your build rules so they look more like the idioms that we
already use for other similar cases. This should fix the troubles you
describe and others.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Index: src/backend/Makefile
===
RCS file: /cvsroot/pgsql/src/backend/Makefile,v
retrieving revision 1.127
diff -u -3 -p -r1.127 Makefile
--- src/backend/Makefile 26 Feb 2008 14:42:27 - 1.127
+++ src/backend/Makefile 27 Feb 2008 21:05:40 -
@@ -20,9 +20,11 @@ SUBDIRS = access bootstrap catalog parse
include $(srcdir)/common.mk
+ifeq ($(PORTNAME), solaris)
ifeq ($(enable_dtrace), yes)
LOCALOBJS += utils/probes.o
endif
+endif
OBJS = $(SUBDIROBJS) $(LOCALOBJS) $(top_builddir)/src/port/libpgport_srv.a
@@ -122,6 +124,9 @@ $(srcdir)/parser/parse.h: parser/gram.y
utils/fmgroids.h: utils/Gen_fmgrtab.sh $(top_srcdir)/src/include/catalog/pg_proc.h
$(MAKE) -C utils fmgroids.h
+utils/probes.h: utils/probes.d
+ $(MAKE) -C utils probes.h
+
# Make symlinks for these headers in the include directory. That way
# we can cut down on the -I options. Also, a symlink is automatically
# up to date when we update the base file.
@@ -135,9 +140,15 @@ $(top_builddir)/src/include/utils/fmgroi
cd $(dir $@) rm -f $(notdir $@) \
$(LN_S) ../../../$(subdir)/utils/fmgroids.h .
+$(top_builddir)/src/include/utils/probes.h: utils/probes.h
+ cd $(dir $@) rm -f $(notdir $@) \
+ $(LN_S) ../../../$(subdir)/utils/probes.h .
+
+ifeq ($(PORTNAME), solaris)
utils/probes.o: utils/probes.d $(SUBDIROBJS)
$(DTRACE) $(DTRACEFLAGS) -G -s $(call expand_subsys,$^) -o $@
+endif
##
Index: src/backend/access/transam/xact.c
===
RCS file: /cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.257
diff -u -3 -p -r1.257 xact.c
--- src/backend/access/transam/xact.c 15 Jan 2008 18:56:59 - 1.257
+++ src/backend/access/transam/xact.c 27 Feb 2008 21:05:41 -
@@ -1479,7 +1479,7 @@ StartTransaction(void)
Assert(MyProc-backendId == vxid.backendId);
MyProc-lxid = vxid.localTransactionId;
- PG_TRACE1(transaction__start, vxid.localTransactionId);
+ POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
/*
* set transaction_timestamp() (a/k/a now()). We want this to be the same
@@ -1604,7 +1604,7 @@ CommitTransaction(void)
*/
latestXid = RecordTransactionCommit();
- PG_TRACE1(transaction__commit, MyProc-lxid);
+ POSTGRESQL_TRANSACTION_COMMIT(MyProc-lxid);
/*
* Let others know about no transaction in progress by me. Note that this
@@ -1990,7 +1990,7 @@ AbortTransaction(void)
*/
latestXid = RecordTransactionAbort(false);
- PG_TRACE1(transaction__abort, MyProc-lxid);
+ POSTGRESQL_TRANSACTION_ABORT(MyProc-lxid);
/*
* Let others know about no transaction in progress by me. Note that this
Index: src/backend/storage/lmgr/lock.c
===
RCS file: /cvsroot/pgsql/src/backend/storage/lmgr/lock.c,v
retrieving revision 1.181
diff -u -3 -p -r1.181 lock.c
--- src/backend/storage/lmgr/lock.c 2 Feb 2008 22:26:17 - 1.181
+++ src/backend/storage/lmgr/lock.c 27 Feb 2008 21:05:41 -
@@ -787,11 +787,11 @@ LockAcquire(const LOCKTAG *locktag,
* Sleep till someone wakes me up.
*/
- PG_TRACE2(lock__startwait, locktag-locktag_field2, lockmode);
+ POSTGRESQL_LOCK_STARTWAIT(locktag-locktag_field2, lockmode);
WaitOnLock(locallock, owner);
- PG_TRACE2(lock__endwait, locktag-locktag_field2, lockmode);
+ POSTGRESQL_LOCK_ENDWAIT(locktag-locktag_field2, lockmode);
/*
* NOTE: do not do any material change of state between here and
Index: src/backend/storage/lmgr/lwlock.c
===
RCS file: /cvsroot/pgsql/src/backend/storage/lmgr/lwlock.c,v
retrieving revision 1.50
diff -u -3 -p -r1.50 lwlock.c
--- src/backend/storage/lmgr/lwlock.c 1 Jan 2008 19:45:52 - 1.50
+++ src/backend/storage/lmgr/lwlock.c 27 Feb 2008 21:05:41 -
@@ -447,7 +447,7 @@ LWLockAcquire(LWLockId lockid, LWLockMod
block_counts[lockid]++;
#endif
- PG_TRACE2(lwlock__startwait, lockid, mode);
+ POSTGRESQL_LWLOCK_STARTWAIT(lockid, mode);
for (;;)
{
@@ -458,7 +458,7 @@ LWLockAcquire(LWLockId lockid, LWLockMod
extraWaits++;
}
- PG_TRACE2(lwlock__endwait, lockid, mode);
+ POSTGRESQL_LWLOCK_ENDWAIT(lockid, mode);
LOG_LWDEBUG(LWLockAcquire, lockid, awakened);
@@ -469,7 +469,7 @@ LWLockAcquire(LWLockId lockid, LWLockMod
/* We are done updating shared state of the lock itself. */
SpinLockRelease(lock-mutex);
- PG_TRACE2(lwlock__acquire
Re: [PATCHES] DTrace not working after SUBSYS.o reorg
Am Dienstag, 26. Februar 2008 schrieb Magne Mæhre: I noticed that the dtrace code wouldn't build after the recent SUBSYS.o reorganization. Fixed. Is there no buildfarm coverage of dtrace? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] lc_time and localized dates
Am Dienstag, 26. Februar 2008 schrieb Zdenek Kotala: But how you handle situation when you have multi language application which needs correct output for all languages? You cannot use any of the pattern because it will be wrong for some group of languages. This is what you get when you copy a proprietary, poorly specified interface. The to_char functions are supposed to be Oracle-compatible, so we need to check what Oracle does. Whether that is useful in practice is a bit secondary. I'm beginning to think, if you want formatting functions that are more sane, stable, and standardized, export sprintf and strftime to PostgreSQL. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Avahi support for Postgresql
Am Dienstag, 27. November 2007 schrieb Mathias Hasselmann: Postmaster already has code to announce its services via DNS-SD (ZeroConf) by using Apple's Bonjour API. This series of patches implements that capability on top of the Avahi library[1] which is free software, available for a wider variety of platforms. One thing I found curious: The Bonjour code uses service type _postgresql._tcp. whereas your code uses _postgresql._tcp (note the dot). Is that an expected difference? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Avahi support for Postgresql
Am Samstag, 23. Februar 2008 schrieb Mathias Hasselmann: The patches were in my initial mail, but now I've also uploaded them to my personal site for convenience: http://taschenorakel.de/files/pgsql-avahi-support/ I have reworked the first three of your patches (mostly formatting and some refactoring) and published them here: http://git.postgresql.org/?p=~petere/postgresql.git;a=shortlog;h=avahi-support -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Shlib exports file refactoring
After seeing four nearly-identical copies of multiplatform shared library
exports file generation code, I figured this should be put in a common place.
If you like, please test the attached patch on darwin and win32, since these
platforms are mostly affected (besides linux) and I can't test them. Just
see if it builds and runs correctly. Thanks.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/interfaces/ecpg/compatlib/Makefile ./src/interfaces/ecpg/compatlib/Makefile
--- ../cvs-pgsql/src/interfaces/ecpg/compatlib/Makefile 2008-02-17 16:30:26.0 +0100
+++ ./src/interfaces/ecpg/compatlib/Makefile 2008-02-25 21:43:46.0 +0100
@@ -25,16 +25,14 @@
SHLIB_LINK = -L../ecpglib -lecpg -L../pgtypeslib -lpgtypes $(libpq) -lm \
$(PTHREAD_LIBS)
+SHLIB_EXPORTS = exports.txt
+
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
OBJS= informix.o $(filter snprintf.o, $(LIBOBJS))
-ifeq ($(PORTNAME), win32)
-DLL_DEFFILE=libecpg_compatdll.def
-endif
-
-all: def-files all-lib
+all: all-lib
# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
@@ -42,55 +40,6 @@
snprintf.c: % : $(top_srcdir)/src/port/%
rm -f $@ $(LN_S) $ .
-# We need several not-quite-identical variants of .DEF files to build libecpg
-# DLLs for Windows. These are made from the single source file exports.txt.
-# Since we can't assume that Windows boxes will have sed, the .DEF files are
-# always built and included in distribution tarballs.
-
-distprep: def-files
-
-.PHONY: def-files
-
-def-files: $(srcdir)/libecpg_compatdll.def $(srcdir)/blibecpg_compatdll.def
-
-$(srcdir)/libecpg_compatdll.def: exports.txt
- echo '; DEF file for MS VC++' $@
- echo 'LIBRARY LIBECPG_COMPAT' $@
- echo 'EXPORTS' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/\1@ \2/' $ $@
-
-$(srcdir)/blibecpg_compatdll.def: exports.txt
- echo '; DEF file for Borland C++ Builder' $@
- echo 'LIBRARY BLIBECPG_COMPAT' $@
- echo 'EXPORTS' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/_\1@ \2/' $ $@
- echo '' $@
- echo '; Aliases for MS compatible names' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/\1= _\1/' $ | sed 's/ *$$//' $@
-
-# Where possible, restrict the symbols exported by the library to just the
-# official list, so as to avoid unintentional ABI changes.
-
-ifeq ($(PORTNAME), darwin)
-$(shlib): exports.list
-
-exports.list: exports.txt
- $(AWK) '/^[^#]/ {printf _%s\n,$$1}' $ $@
-
-exported_symbols_list = -exported_symbols_list exports.list
-endif
-
-ifeq ($(PORTNAME), linux)
-$(shlib): exports.list
-
-exports.list: exports.txt
- echo '{ global:' $@
- $(AWK) '/^[^#]/ {printf %s;\n,$$1}' $ $@
- echo ' local: *; };' $@
-
-exported_symbols_list = -Wl,--version-script=exports.list
-endif
-
install: all installdirs install-lib
installdirs:
@@ -99,7 +48,6 @@
uninstall: uninstall-lib
clean distclean: clean-lib
- rm -f $(OBJS) snprintf.c exports.list
+ rm -f $(OBJS) snprintf.c
-maintainer-clean: distclean
- rm -f $(srcdir)/libecpg_compatdll.def $(srcdir)/blibecpg_compatdll.def
+maintainer-clean: distclean maintainer-clean-lib
diff -ur ../cvs-pgsql/src/interfaces/ecpg/ecpglib/Makefile ./src/interfaces/ecpg/ecpglib/Makefile
--- ../cvs-pgsql/src/interfaces/ecpg/ecpglib/Makefile 2008-02-17 16:30:26.0 +0100
+++ ./src/interfaces/ecpg/ecpglib/Makefile 2008-02-25 21:43:45.0 +0100
@@ -36,13 +36,14 @@
SHLIB_LINK = -L../pgtypeslib -lpgtypes $(libpq) -lm $(PTHREAD_LIBS)
+SHLIB_EXPORTS = exports.txt
+
ifeq ($(PORTNAME), win32)
# Link to shfolder.dll instead of shell32.dll
SHLIB_LINK += -lshfolder
-DLL_DEFFILE=libecpgdll.def
endif
-all: def-files all-lib
+all: all-lib
# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
@@ -60,55 +61,6 @@
$(top_builddir)/src/port/pg_config_paths.h:
$(MAKE) -C $(top_builddir)/src/port pg_config_paths.h
-# We need several not-quite-identical variants of .DEF files to build libecpg
-# DLLs for Windows. These are made from the single source file exports.txt.
-# Since we can't assume that Windows boxes will have sed, the .DEF files are
-# always built and included in distribution tarballs.
-
-distprep: def-files
-
-.PHONY: def-files
-
-def-files: $(srcdir)/libecpgdll.def $(srcdir)/blibecpgdll.def
-
-$(srcdir)/libecpgdll.def: exports.txt
- echo '; DEF file for MS VC++' $@
- echo 'LIBRARY LIBECPG' $@
- echo 'EXPORTS' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/\1@ \2/' $ $@
-
-$(srcdir)/blibecpgdll.def: exports.txt
- echo '; DEF file for Borland C++ Builder' $@
- echo 'LIBRARY BLIBECPG' $@
- echo 'EXPORTS' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/_\1@ \2/' $ $@
- echo '' $@
- echo '; Aliases for MS compatible names' $@
- sed -e '/^#/d' -e 's/^\(.* \)\([0-9][0-9]*\)/\1= _\1/' $ | sed 's/ *$$//' $@
-
-# Where possible, restrict the symbols exported by the library to just the
-# official list, so as to avoid unintentional ABI
Re: [PATCHES] Avahi support for Postgresql
Mathias Hasselmann wrote: Congratulations to the 8.3 release. No, that pre-release stress is over I'd really like to put attention on my Avahi patches again. I've added your item to the patch list (http://developer.postgresql.org/index.php/Todo:PatchStatus). It would help if you could include or point to your actual patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] fix in --help output
Am Freitag, 22. Februar 2008 schrieb Zdenek Kotala: Peter Eisentraut napsal(a): Zdenek Kotala wrote: However, I get following error on Solaris: bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000 /usr/postgres/8.2/bin/postgres: illegal option -- share_buffers=16000 Try postgres --help for more information. but following command works fine: /usr/postgres/8.2/bin/postgres -D /tmp/db -c shared_buffers=16000 share_buffers is not the same as shared_buffers. Yeah, it was a typo but it does not work anyway. Well, if it doesn't work you can use the -c option. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] fix in --help output
Zdenek Kotala wrote: I attach fix for --help output. I replaced --NAME... with -NAME But that is wrong. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] fix in --help output
Zdenek Kotala wrote: However, I get following error on Solaris: bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000 /usr/postgres/8.2/bin/postgres: illegal option -- share_buffers=16000 Try postgres --help for more information. but following command works fine: /usr/postgres/8.2/bin/postgres -D /tmp/db -c shared_buffers=16000 share_buffers is not the same as shared_buffers. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Backend makefile refactoring
I want to work on getting rid of the SUBSYS.o things in the backend build, ideally in some way to supports both the current and the new way of building things (details to be defined). To prepare for that, I have refactored some common rules in the backend makefiles. See attached patch. This should not change any functionality of the build system at the moment. -- Peter Eisentraut http://developer.postgresql.org/~petere/ diff --git a/src/backend/access/Makefile b/src/backend/access/Makefile index 4753eac..df05f8e 100644 --- a/src/backend/access/Makefile +++ b/src/backend/access/Makefile @@ -9,19 +9,5 @@ top_builddir = ../../.. include $(top_builddir)/src/Makefile.global SUBDIRS = common gist hash heap index nbtree transam gin -SUBDIROBJS = $(SUBDIRS:%=%/SUBSYS.o) -all: SUBSYS.o - -SUBSYS.o: $(SUBDIROBJS) - $(LD) $(LDREL) $(LDOUT) $@ $^ - -$(SUBDIROBJS): $(SUBDIRS:%=%-recursive) ; - -.PHONY: $(SUBDIRS:%=%-recursive) -$(SUBDIRS:%=%-recursive): - $(MAKE) -C $(subst -recursive,,$@) SUBSYS.o - -clean: - for dir in $(SUBDIRS); do $(MAKE) -C $$dir $@ || exit; done - rm -f SUBSYS.o +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/common/Makefile b/src/backend/access/common/Makefile index 7adc66b..a334816 100644 --- a/src/backend/access/common/Makefile +++ b/src/backend/access/common/Makefile @@ -16,8 +16,4 @@ OBJS = heaptuple.o indextuple.o printtup.o reloptions.o scankey.o tupdesc.o all: SUBSYS.o -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/gin/Makefile b/src/backend/access/gin/Makefile index 5bab415..c5872d3 100644 --- a/src/backend/access/gin/Makefile +++ b/src/backend/access/gin/Makefile @@ -16,10 +16,4 @@ OBJS = ginutil.o gininsert.o ginxlog.o ginentrypage.o gindatapage.o \ ginbtree.o ginscan.o ginget.o ginvacuum.o ginarrayproc.o \ ginbulk.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/gist/Makefile b/src/backend/access/gist/Makefile index d1e3266..8d3a6d0 100644 --- a/src/backend/access/gist/Makefile +++ b/src/backend/access/gist/Makefile @@ -15,10 +15,4 @@ include $(top_builddir)/src/Makefile.global OBJS = gist.o gistutil.o gistxlog.o gistvacuum.o gistget.o gistscan.o \ gistproc.o gistsplit.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/hash/Makefile b/src/backend/access/hash/Makefile index f653a83..df7563c 100644 --- a/src/backend/access/hash/Makefile +++ b/src/backend/access/hash/Makefile @@ -15,10 +15,4 @@ include $(top_builddir)/src/Makefile.global OBJS = hash.o hashfunc.o hashinsert.o hashovfl.o hashpage.o hashscan.o \ hashsearch.o hashutil.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/heap/Makefile b/src/backend/access/heap/Makefile index abd3212..1674467 100644 --- a/src/backend/access/heap/Makefile +++ b/src/backend/access/heap/Makefile @@ -14,10 +14,4 @@ include $(top_builddir)/src/Makefile.global OBJS = heapam.o hio.o pruneheap.o rewriteheap.o syncscan.o tuptoaster.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/index/Makefile b/src/backend/access/index/Makefile index d849b26..5469970 100644 --- a/src/backend/access/index/Makefile +++ b/src/backend/access/index/Makefile @@ -14,10 +14,4 @@ include $(top_builddir)/src/Makefile.global OBJS = genam.o indexam.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/nbtree/Makefile b/src/backend/access/nbtree/Makefile index b833ef9..323a2f3 100644 --- a/src/backend/access/nbtree/Makefile +++ b/src/backend/access/nbtree/Makefile @@ -15,10 +15,4 @@ include $(top_builddir)/src/Makefile.global OBJS = nbtcompare.o nbtinsert.o nbtpage.o nbtree.o nbtsearch.o \ nbtutils.o nbtsort.o nbtxlog.o -all: SUBSYS.o - -SUBSYS.o: $(OBJS) - $(LD) $(LDREL) $(LDOUT) SUBSYS.o $(OBJS) - -clean: - rm -f SUBSYS.o $(OBJS) +include $(top_srcdir)/src/backend/common.mk diff --git a/src/backend/access/transam/Makefile b/src/backend/access/transam/Makefile index 9d7c23c..8532d28 100644 --- a/src/backend/access/transam/Makefile +++ b/src/backend/access/transam/Makefile @@ -14,13 +14,7 @@ include $(top_builddir)/src/Makefile.global OBJS = clog.o transam.o varsup.o xact.o xlog.o xlogutils.o rmgr.o slru.o subtrans.o multixact.o twophase.o
Re: [PATCHES] WIP: plpgsql source code obfuscation
Am Montag, 28. Januar 2008 schrieb Pavel Stehule: this patch define new function flag - OBFUSCATE. With this flag encrypted source code is stored to probin column. Password is stored in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server does (where privileged users can access system tables with source code or can use debugger). Have you thought about a solution that applies the regular access privileges to pg_proc in order to hide some content from less privileged users? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] WIP: plpgsql source code obfuscation
Am Montag, 28. Januar 2008 schrieb Tom Lane: My recollection is that certain cryptography laws make hooks for crypto just as problematic as actual crypto code. We'd have to tread very carefully --- general purpose hooks are OK but anything narrowly tailored to encryption purposes would be a hazard. PostgreSQL already has built-in support for SSL and Kerberos, so it is already infested with enough weaponized code to fail most applicable regulations. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
[PATCHES] NUMERIC key word
In 8.3, it appears that NUMERIC doesn't need to be a key word any longer. See
attached patch. Was there a reason this was kept in the parser? Otherwise
we could remove it in 8.4.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/parser/gram.y ./src/backend/parser/gram.y
--- ../cvs-pgsql/src/backend/parser/gram.y 2008-01-04 15:55:24.0 +0100
+++ ./src/backend/parser/gram.y 2008-01-29 16:00:59.0 +0100
@@ -412,7 +412,7 @@
NAME_P NAMES NATIONAL NATURAL NCHAR NEW NEXT NO NOCREATEDB
NOCREATEROLE NOCREATEUSER NOINHERIT NOLOGIN_P NONE NOSUPERUSER
- NOT NOTHING NOTIFY NOTNULL NOWAIT NULL_P NULLIF NULLS_P NUMERIC
+ NOT NOTHING NOTIFY NOTNULL NOWAIT NULL_P NULLIF NULLS_P
OBJECT_P OF OFF OFFSET OIDS OLD ON ONLY OPERATOR OPTION OR
ORDER OUT_P OUTER_P OVERLAPS OVERLAY OWNED OWNER
@@ -6986,12 +6986,6 @@
$$-typmods = $2;
$$-location = @1;
}
- | NUMERIC opt_type_modifiers
-{
- $$ = SystemTypeName(numeric);
- $$-typmods = $2;
- $$-location = @1;
-}
| BOOLEAN_P
{
$$ = SystemTypeName(bool);
@@ -9266,7 +9260,6 @@
| NCHAR
| NONE
| NULLIF
- | NUMERIC
| OUT_P
| OVERLAY
| POSITION
diff -ur ../cvs-pgsql/src/backend/parser/keywords.c ./src/backend/parser/keywords.c
--- ../cvs-pgsql/src/backend/parser/keywords.c 2008-01-04 15:55:24.0 +0100
+++ ./src/backend/parser/keywords.c 2008-01-29 16:01:09.0 +0100
@@ -251,7 +251,6 @@
{null, NULL_P, RESERVED_KEYWORD},
{nullif, NULLIF, COL_NAME_KEYWORD},
{nulls, NULLS_P, UNRESERVED_KEYWORD},
- {numeric, NUMERIC, COL_NAME_KEYWORD},
{object, OBJECT_P, UNRESERVED_KEYWORD},
{of, OF, UNRESERVED_KEYWORD},
{off, OFF, RESERVED_KEYWORD},
---(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] Friendly help for psql
Greg Sabino Mullane wrote: Why not run help when someone enters help (or HELP ME!) on the command line? \? is hardly an easy thing to remember (and some people can't be bothered to actually read the screen...) Then surely the help output won't be of use to them either. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Friendly help for psql
Greg Sabino Mullane wrote: No. While the original poster may have been making a separate comparison to MySQL, I can assure you that my impetus for doing this is not being driven by the behavior of the mysql client. Then what is the motivation for this? We have many sources of help. I have never heard of any user not being able to find help. Having help do something other than throw a syntax error is a very common feature in many interactive programs, for example openssl, gdb, ftp, bash, mail, telnet, and vim. The difference with these tools is that they don't already tell you how to get help when you log in. Now I have actually thought for a while whether we could get rid of the login text altogether. I would support trading that for extended help options. But if the login note is there, then we don't need more help options. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] [HACKERS] SSL over Unix-domain sockets
Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan: I agree. I remain of the opinion that this is not a problem than can be solved purely within the bounds of postgres. Well, the SSL patch I showed certainly solves the problem. (I am not saying it is the best possible solution.) Of course there also need to be prudent users, but that is the case for any security system. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Freitag, 18. Januar 2008 schrieb Magnus Hagander: Not that much more than moving the socket file to a secure directory. Both rely on configuring the client properly. It's arguably a lot easier to configure the client to connect to the correct socket, than to make sure the client has a root certificate installed. How would a client check whether the socket file is in a secure location? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Donnerstag, 17. Januar 2008 schrieb Bruce Momjian: It creates a lock file that is the same name as the socket file that a default-configured client would use, so it prevents a spoofed socket from being created. A counter-spoofing solution must be implemented in the client. No moving around of files by the server will ever solve the problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Freitag, 18. Januar 2008 schrieb Alvaro Herrera: I propose to create a dangling symlink on system startup in /tmp/.s.PGSQL.port to the real socket, which is not on a world-writable directory. This avoids the spoofer, because he cannot create the socket -- the symlink is occupying its place. This approaches the issue from the wrong end. Spoofing attacks the client, so the defense must be in the client. If the defense of the client is to rely on a carefully configured server, then that might exclude some possible attack vectors, but it is not a defense the client can rely on. To look at this in another way, if we relied on every browser user to type in web addresses correctly and all server administrators to make sure their socket address cannot be hijacked, we wouldn't need SSL on the web. The proper approach, however, is to configure the client to only talk to servers that can prove their identity. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [GENERAL] Forgot to dump old data before re-installing machine
Tom Lane wrote:
What would work better is to add some code that checks whether
pg_control_version looks like the byte-swap of a small number,
and prints a suitably modified error message if so.
Here is a possible patch. Example output:
$ pg-install/bin/postgres -D pg-install/var/data
FATAL: database files are incompatible with server
DETAIL: The database cluster was initialized with PG_CONTROL_VERSION
1090715648 (0x4103), but the server was compiled with PG_CONTROL_VERSION
833 (0x0341).
HINT: This could be a mismatched byte order. It looks like you need to initdb.
I didn't follow how the user got into this mess, so I don't know whether the
suggestion you need to initdb is appropriate.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/access/transam/xlog.c ./src/backend/access/transam/xlog.c
--- ../cvs-pgsql/src/backend/access/transam/xlog.c 2008-01-05 11:58:44.0 +0100
+++ ./src/backend/access/transam/xlog.c 2008-01-18 20:04:59.0 +0100
@@ -3888,6 +3888,16 @@
* of bytes. Complaining about wrong version will probably be more
* enlightening than complaining about wrong CRC.
*/
+
+ if (ControlFile-pg_control_version != PG_CONTROL_VERSION ControlFile-pg_control_version % 65536 == 0 ControlFile-pg_control_version / 65536 != 0)
+ ereport(FATAL,
+(errmsg(database files are incompatible with server),
+ errdetail(The database cluster was initialized with PG_CONTROL_VERSION %d (0x%08x),
+ but the server was compiled with PG_CONTROL_VERSION %d (0x%08x).,
+ ControlFile-pg_control_version, ControlFile-pg_control_version,
+ PG_CONTROL_VERSION, PG_CONTROL_VERSION),
+ errhint(This could be a mismatched byte order. It looks like you need to initdb.)));
+
if (ControlFile-pg_control_version != PG_CONTROL_VERSION)
ereport(FATAL,
(errmsg(database files are incompatible with server),
@@ -3895,6 +3905,7 @@
but the server was compiled with PG_CONTROL_VERSION %d.,
ControlFile-pg_control_version, PG_CONTROL_VERSION),
errhint(It looks like you need to initdb.)));
+
/* Now check the CRC. */
INIT_CRC32(crc);
COMP_CRC32(crc,
diff -ur ../cvs-pgsql/src/bin/pg_controldata/pg_controldata.c ./src/bin/pg_controldata/pg_controldata.c
--- ../cvs-pgsql/src/bin/pg_controldata/pg_controldata.c 2007-04-03 22:26:13.0 +0200
+++ ./src/bin/pg_controldata/pg_controldata.c 2008-01-18 19:55:16.0 +0100
@@ -151,6 +151,11 @@
printf(_(pg_control version number:%u\n),
ControlFile.pg_control_version);
+ if (ControlFile.pg_control_version % 65536 == 0 ControlFile.pg_control_version / 65536 != 0)
+ printf(_(WARNING: possibly byte order mismatch\n
+ The byte order used to store the pg_control file might not match the one used\n
+ by this program. In that case the results below would be incorrect, and the\n
+ PostgreSQL installation would be incompatible with this data directory.\n));
printf(_(Catalog version number: %u\n),
ControlFile.catalog_version_no);
printf(_(Database system identifier: %s\n),
---(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] [HACKERS] SSL over Unix-domain sockets
Bruce Momjian wrote: I have written the following documentation addition suggesting the use of external_pid_file. How does that prevent spoofing? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Auto create (top level) directory for create tablespace
Tom Lane wrote: Ignoring this point is actually a fine recipe for destroying your data; see Joe Conway's report a couple years back about getting burnt by a soft NFS mount. If the DB directory is not there, auto-creating it is a horrible idea. Yes, this would be equivalent to the old behavior of the Red Hat RPMs that automatically performed initdb if the data directory is missing. Thankfully, that has been abolished. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Is postgres.gif missing in cvs?
Am Freitag, 14. Dezember 2007 schrieb Bruce Momjian: I have applied the attached patch to give a helpful message if you try to create postgres.ps or postgres.pdf. I have corrected this to use $(MAKE) instead of gmake, because the latter might not be available. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] fulltext parser strange behave
Am Montag, 19. November 2007 schrieb Tom Lane: Maybe, but HTML-type is an unhelpful description. Isn't there a more general markup standard that subsumes both HTML and XML? (I seem to recall that SGML might be that, but not sure.) I think XML tag would actually cover anything that would be valid as an HTML tag. (As opposed to the fact that an XML document is not a superset of an HTML document.) SGML might be too broad. It would require us to recognize / and and perhaps a few other odd things. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Hibernate Dialects for PostgreSQL
Am Montag, 12. November 2007 schrieb Simon Riggs:
On Mon, 2007-11-12 at 14:28 +0100, Peter Eisentraut wrote:
Simon Riggs wrote:
I enclose 3 Dialects for PostgreSQL, as discussed on -hackers.
There is no such thing as PostgreSQL 8. Please don't do that; it would
confuse users about the versioning scheme.
Would 8x be the right thing then?
So PostgreSQL8xDialect or PostgreSQL80Dialect or ...
If you know it doesn't work before 8.0, PostgreSQL80Dialect sounds right.
Otherwise just PostgreSQLDialect or perhaps something like PostgreSQL{Base|
Abstract}Dialect.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Hibernate Dialects for PostgreSQL
Simon Riggs wrote: I enclose 3 Dialects for PostgreSQL, as discussed on -hackers. There is no such thing as PostgreSQL 8. Please don't do that; it would confuse users about the versioning scheme. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] mingw autoconf again
Am Montag, 29. Oktober 2007 schrieb Magnus Hagander: 1) does it look ok? yes 2) is it ok to put checks for win32-only this way? Well, the available replacement implementation only works on win32, so this is about as correct as we should care to be at the moment. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Using system time zone database
Because there seems to be an increasing trend among packagers to drop the
PostgreSQL-supplied time zone data and use the operating system's instead, I
figured it would be good to define an official and documented way to do this.
If we could get, say, the Linux, BSD, and Solaris packagers to adopt this,
this would eliminate the bulk of essentially redundant efforts to upgrade the
PostgreSQL packages whenever the time zone data changes.
Here is a proposed patch that you would use like this:
./configure ... --with-system-tzdata=/usr/share/zoneinfo
I'm not sure to what extent the regression tests exercise the specifics of the
time zone data, but when you specify something totally wrong some tests fail,
so it would be easy to catch that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur cvs-pgsql/configure pgsql/configure
--- cvs-pgsql/configure 2007-08-11 19:12:23.0 +0200
+++ pgsql/configure 2007-08-16 22:30:56.0 +0200
@@ -314,7 +314,7 @@
# include unistd.h
#endif
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_args build build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGES default_port enable_shared enable_rpath enable_debug enable_profiling DTRACE DTRACEFLAGS enable_dtrace CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP GCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_gssapi with_krb5 krb_srvtab with_pam with_ldap with_bonjour with_openssl with_ossp_uuid XML2_CONFIG with_libxml with_libxslt with_zlib EGREP ELF_SYS LDFLAGS_SL LD with_gnu_ld ld_R_works RANLIB ac_ct_RANLIB STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB TAR LN_S AWK YACC YFLAGS FLEX FLEXFLAGS PERL perl_archlibexp perl_privlibexp perl_useshrplib perl_embed_ldflags PYTHON python_version python_configdir python_includespec python_libdir python_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBS PTHREAD_CFLAGS LDAP_LIBS_FE LDAP_LIBS_BE HAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILE TCL_LIBS TCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPL vpath_build LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS configure_args build build_cpu build_vendor build_os host host_cpu host_vendor host_os PORTNAME docdir enable_nls WANTED_LANGUAGES default_port enable_shared enable_rpath enable_debug enable_profiling DTRACE DTRACEFLAGS enable_dtrace CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT CPP GCC TAS autodepend INCLUDES enable_thread_safety with_tcl with_perl with_python with_gssapi with_krb5 krb_srvtab with_pam with_ldap with_bonjour with_openssl with_ossp_uuid XML2_CONFIG with_libxml with_libxslt with_system_tzdata with_zlib EGREP ELF_SYS LDFLAGS_SL LD with_gnu_ld ld_R_works RANLIB ac_ct_RANLIB STRIP ac_ct_STRIP STRIP_STATIC_LIB STRIP_SHARED_LIB TAR LN_S AWK YACC YFLAGS FLEX FLEXFLAGS PERL perl_archlibexp perl_privlibexp perl_useshrplib perl_embed_ldflags PYTHON python_version python_configdir python_includespec python_libdir python_libspec python_additional_libs HAVE_IPV6 LIBOBJS acx_pthread_config PTHREAD_CC PTHREAD_LIBS PTHREAD_CFLAGS LDAP_LIBS_FE LDAP_LIBS_BE HAVE_POSIX_SIGNALS MSGFMT MSGMERGE XGETTEXT localedir TCLSH TCL_CONFIG_SH TCL_INCLUDE_SPEC TCL_LIB_FILE TCL_LIBS TCL_LIB_SPEC TCL_SHARED_BUILD TCL_SHLIB_LD_LIBS NSGMLS JADE have_docbook DOCBOOKSTYLE COLLATEINDEX SGMLSPL vpath_build LTLIBOBJS'
ac_subst_files=''
# Initialize some variables set by options.
@@ -899,6 +899,7 @@
--with-ossp-uuidbuild with OSSP UUID library for UUID generation
--with-libxml build with XML support
--with-libxslt build with XSLT support
+ --with-system-tzdata=DIR use system time zone data in DIR
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
@@ -4501,6 +4502,37 @@
#
+# tzdata
+#
+
+pgac_args=$pgac_args with_system_tzdata
+
+
+# Check whether --with-system-tzdata or --without-system-tzdata was given.
+if test ${with_system_tzdata+set} = set; then
+ withval=$with_system_tzdata
+
+ case $withval in
+yes)
+ { { echo $as_me:$LINENO: error: argument required for --with-system-tzdata option 5
+echo $as_me: error: argument required
Re: [PATCHES] Using system time zone database
Am Freitag, 17. August 2007 12:46 schrieb Zdenek Kotala: Yes, e.g. Solaris use this solution for 8.2 packages. I sent little bit different patch few months ago. You can see discussion there: Yes, my patch just uses the symlink solution that people already use. Also could be good to modify also pg_config to show where TZ files are stored. pg_config --configure would show it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Using system time zone database
Am Freitag, 17. August 2007 13:03 schrieb Magnus Hagander: Could there be some way for configure to automatically check that the timezone format used on the system is in fact compatible? Such as checking if it can load a well-known timezone and that it behaves properly? You cannot assume that the build environment is the same as the run environment. Anyway, just run make check and you will know. Anything else would be much too complicated. This patch just provides direct access to the process that people already use anyway. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Default location for docbook stylesheets in Gentoo
Brendan Jurd wrote: This patch adds the default location for the DocBook DSSSL stylesheets in gentoo's package system to the configure script. Uh, could you please send a diff with -u or -c, so we know where to put the change? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] msvc const warnings
Am Dienstag, 24. Juli 2007 17:24 schrieb Gregory Stark: Can we just disable const checking for MSVCC in general without using the #pragmas? It clearly doesn't understand how const works making that warning from it useless. That was my thought. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] configure.in / xml / quoting trouble
Am Freitag, 20. Juli 2007 13:28 schrieb Patrick Welche: Also, why did postgresql choose not to use automake? The was never such a choice made. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] execl() sentinel
Tom Lane wrote: It's too bad that gcc doesn't have a -Wno-snarkiness-about-system-headers-thank-you switch. It does have a switch to *add* snarkiness about system headers, but does not do it by default. The problem in this case is that an uncast null pointer constant is not always a sufficient sentinel for variadic functions, as explained here: http://c-faq.com/null/null2.html. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Async Commit, v21 (now: v22)
Am Dienstag, 17. Juli 2007 20:31 schrieb Simon Riggs: Here's the latest version. I've reviewed this to check that this does what I want it to do, re-written various comments and changed a few minor points in the code. I've also added a chunk to transam/README that describes the workings of the patch from a high level. Now ready for final review. I'm not sure the following explanation is all that clear: +para + Asynchronous commit provides different behaviour to setting + varnamefsync/varname = off, since that is a server-wide + setting that will alter the behaviour of all transactions, + overriding the setting of varnamesynchronous_commit/varname, + as well as risking much wider data loss. With varnamefsync/varname + = off the WAL written but not fsynced, so data is lost only in case + of a system crash. With asynchronous commit the WAL is not written + to disk at all by the user, so data is lost if there is a database + server crash, as well as when the system crashes. +/para On the one hand, it claims that fsync off has much wider data loss implications than asynchronous commit, on the other hand, it states that the risk of a loss due to asynchronous commit happening is larger than fsync off. I *think* I know what this is trying to say, but I suspect that the average user might not be able to make a good choice of settings. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] execl() sentinel
Am Mittwoch, 18. Juli 2007 16:16 schrieb Tom Lane: You should *not* have to inform the machine that NULL is a pointer. For variadic functions, that expectation is invalid, AFAIK. It might be good to check the actual definition of NULL in this case, however, before wondering further. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] execl() sentinel
Am Mittwoch, 18. Juli 2007 17:16 schrieb Alvaro Herrera: Peter Eisentraut wrote: Am Mittwoch, 18. Juli 2007 16:16 schrieb Tom Lane: You should *not* have to inform the machine that NULL is a pointer. For variadic functions, that expectation is invalid, AFAIK. No, what's invalid is that using an unadorned 0 is understood as a null pointer by the compiler. That would happen in a lot of places except on a variadic function. However, the platform may define NULL as it wishes, and indeed in our c.h it is defined (conditionally) as (void *)0. If the platform had such a definition then it would work without issues. I assume the platform in question does something like #define NULL 0 which would be silly. I suggest that you read through http://c-faq.com/null/, which is at odds with your statements. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] script binaries renaming
Am Mittwoch, 4. Juli 2007 17:04 schrieb Zdenek Kotala: I attach complete patch which renames following binaries createdb createlang createuser dropdb droplang dropuser clusterdb vacuumdb reindexdb I just want to say I dislike this idea. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] script binaries renaming
Am Donnerstag, 5. Juli 2007 06:59 schrieb Magnus Hagander: I'm also not sure we really should install copies on win32. Given how seldom these commands are actually used on windows But some people do use them, and they should have the same experience as on any other platform. I don't think disk space is really a concern, is it? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] xml2 contrib patch supporting default XML namespaces
Mike Rylander wrote: I understand that XML support is planned and at least partially implemented for 8.3, but many production instances will be unable (or, in fact, unwilling) to upgrade to 8.3 for quite some time. Because this patch is completely backward compatible it can (theoretically) be included in future 8.1 and 8.2 releases, and for those of us that need more full XML support in the short term the upgrade of a contrib module is probably a very viable option -- it is for me, anyway. 8.3 contains XPath support which should cover the issue that this patch addresses. (Might wanna check.) Since we're not going to put new features into earlier releases, and contrib modules are not necessarily source backward-compatible, I don't think this patch has a place in a future PostgreSQL release. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] boolean = text explicit casts
Neil Conway wrote: Attached is a revised version of this patch that modifies boolin() to ignore leading and trailing whitespace. This makes text = boolean trivial, but boolean = text is still distinct from boolout(). I'm not sure what your rationale was for creating lower-case words instead of upper case, except for it looks nicer. Is there a technical reason? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Synchronized Scan
Am Montag, 21. Mai 2007 00:01 schrieb Jeff Davis: Here is the latest version of my patch that's revised according to my discussions with Heikki and Simon: This patch was apparently done against 8.2.4, but it doesn't apply to CVS head. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Concurrent psql patch
Am Montag, 21. Mai 2007 15:21 schrieb Gregory Stark: Also, I forgot to mention previously there is an unrelated trivial hunk in here. I noticed we free the password early, presumably for security reasons, No, to save memory. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] xpath_array with namespaces support
Am Dienstag, 10. April 2007 14:01 schrieb Nikolay Samokhvalov:
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5. Return empty array in case when XPath expression detects nothing
(previously, NULL was returned in such case), per discussion.
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
7. Some cleanup.
Applied.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(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] On patching without write access to CVS
Am Montag, 14. Mai 2007 03:56 schrieb David Fetter: +For those things which productnameCVS/productname does not do +by itself, such as letting you create patches without write access, I don't think that is accurate. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] [WIP] GUC for temp_tablespaces
Am Mittwoch, 9. Mai 2007 02:21 schrieb Jaime Casanova: What I have been missing all along in these patches is an explanation for what it means to list multiple temporary tablespaces. Are they used in order, or the first one that exists, or what? http://archives.postgresql.org/pgsql-hackers/2007-01/msg00531.php http://archives.postgresql.org/pgsql-patches/2007-01/msg00282.php Those are discussions of possible ideas, not an acceptable documentation of this feature. in src/backend/commands/tablespace.c:assign_temp_tablespaces(): That also isn't an acceptable place to put feature documentation. /* * Select the first tablespace to use */ Assert(num_temp_tablespaces = 0); if (num_temp_tablespaces != 0) next_temp_tablespace = MyProcPid % num_temp_tablespaces; What does this mean? Is there code that selects the second tablespace to use? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] small patch for guc issues
Am Freitag, 4. Mai 2007 18:21 schrieb Joachim Wieland: The appended patch addresses the outstanding issues of the recent guc patch. It makes PGCLIENTENCODING work again and uses bsearch() instead of iterating over the array of guc variables in guc_get_index(). Applied. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [WIP] GUC for temp_tablespaces
Am Samstag, 5. Mai 2007 16:40 schrieb Jaime Casanova: On 5/5/07, Bruce Momjian [EMAIL PROTECTED] wrote: Your patch has been added to the PostgreSQL unapplied patches list at: This is final version of the patch (i hope), at least it fixes the problem i had yesterday. What I have been missing all along in these patches is an explanation for what it means to list multiple temporary tablespaces. Are they used in order, or the first one that exists, or what? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Diagnostic functions
Heikki Linnakangas wrote: Here's an update of Simon's Heap Page Diagnostic Functions. I now consider it ready to commit. How is this better than pg_filedump? diagnostics is an awfully general name, too. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] SPI_psprintf and SPI_pstrdup
Jacob Rief wrote: char *SPI_psprintf(const char *fmt, ...); allocates a block of memory out of the memory pool and prints a formatted string into it Such matters are best solved using the StringInfo API. SPI_pstrdup(const char *src); allocates a block of memory out of the memory pool and copies an existing string into it. How is that different from pstrdup()? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] build/install xml2 when configured with libxml
Andrew Dunstan wrote: I don't think it should go away until we provide for equivalents in core, at least optionally. Well, if we're going to make libxslt an explicit thing, then it'd be trivial to add an xslt transformation function into the core, and then I think we can claim equivalent support. But we'll have to check the details, of course. I have been thinking, however, that I don't want to add more and more library dependencies into the server. libxml2 was necessary to some extent. But xslt functionality could easily be provided as a module. This would be easy to do and might be useful even for 8.3. But I don't really know how to label that. Having a contrib/xslt alongside contrib/xml2 would probably be confusing. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] build/install xml2 when configured with libxml
Andrew Dunstan wrote: The attached patch adds a test for libxslt/xslt.h and only builds contrib/xml2 if it's found, But the policy is that the presence of features in the final build should not depend on the incidental presence of features in the build environment. Either you select a feature, then it's built, or you don't, then it's not. So the only options we really have are adding another switch for libxslt, or including it with libxml. I'm not sure which is better. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] xpath_array with namespaces support
Am Dienstag, 10. April 2007 15:17 schrieb Andrew Dunstan:
Nikolay Samokhvalov wrote:
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
Is that legal XML? I though only documents could have prologs.
It's not a legal XML document, but it's a legal XML content fragment,
specified by SQL/XML.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Tom Lane wrote: True, there doesn't seem to be any point in providing a full syntax summary rather than just saying the SQL spec says you can grant privileges on columns but we don't support that yet. I think it's pretty useful if people see a command of this form from some other implementation and don't know what it means. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Bruce Momjian wrote: True, there doesn't seem to be any point in providing a full syntax summary rather than just saying the SQL spec says you can grant privileges on columns but we don't support that yet. Agreed. Patch attached and applied. I don't see any other cases of this in our documentation. That doesn't mean this one isn't useful. Please revert this. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Correct the spelling of SYMMETRIC
Bruce Momjian wrote: Michael Fuhr wrote: On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote: Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, Thanks. 8.1 and 8.2 have the same typo -- any reason not to backpatch this? OK, fixed in 8.2.X. We don't patch documentation past the most recent major release. Why not? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] xpath_array with namespaces support
Am Mittwoch, 4. April 2007 14:42 schrieb Nikolay Samokhvalov: Maybe it's worth to start keeping additional information in xml datum (i.e. bit IS_DOCUMENT and, what is more important for xpath() function, a bit indicating that XML value has only one root and can be considered as a tree = there is no need to wrap with x .. /x). But this change requires additional time to design xml datum structure and to rework the code (macros, I/O functions...). To determine if an XML datum is a document, call xml_is_document(). The implementation of that function is probably not the best possible one, but what the xpath() code does it totally wrong nevertheless. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] xpath_array with namespaces support
Am Mittwoch, 4. April 2007 14:42 schrieb Nikolay Samokhvalov: Why is the function not strict? Because in case of 3rd argument (NS mappings) being NULL, we shouldn't return NULL immediately: If the namespace mapping is NULL then it is unknown, and therefore the result of the XPath expression cannot be evaluated with certainty. If no namespace mapping is to be passed, then you should pass a list(/array/...) of length zero. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] xpath_array with namespaces support
Am Mittwoch, 4. April 2007 15:20 schrieb Nikolay Samokhvalov: To determine if an XML datum is a document, call xml_is_document(). The implementation of that function is probably not the best possible one, but what the xpath() code does it totally wrong nevertheless. You are proposing 2-3 (depends on the case) parsing times for the one XML value instead of current 1-2 I know it's bad, and something like adding a bit (byte) to mark this in the value would be good, but that doesn't change the fact that (xmlStrncmp((xmlChar *) VARDATA(data), (xmlChar *) ?xml, 5) == 0) is not a valid method to tell apart a document from a fragment. Proof: pei=# select xml '?xml version=1.0?foobar/foo' IS DOCUMENT; ?column? -- t (1 row) pei=# select xml '?xml version=1.0?foobar/foofoobar/foo' IS DOCUMENT; ?column? -- f (1 row) pei=# select xml 'foobar/foo' IS DOCUMENT; ?column? -- t (1 row) pei=# select xml 'foobar/foofoobar/foo' IS DOCUMENT; ?column? -- f (1 row) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] build/install xml2 when configured with libxml
Andrew Dunstan wrote: Since contrib/xml2 seems to be staying with us at least for now, this small patch enables it to be built and installed from the contrib Makefile when --with-libxml is given to configure. contrib/xml2 also requires libxslt. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] build/install xml2 when configured with libxml
Andrew Dunstan wrote: Well, how often is libxslt missing when libxml is present, in practice? A local sample shows a probability of 100%. And if it is, then you have several options: . don't configure with libxml, or . don't build contrib modules from the contrib Makefile (use the individual module Makefiles instead), or . change the xml2 Makefile Any of these could be worth considering, but it needs to be thought through first. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Logging checkpoints and other slowdown causes
Greg Smith wrote: This patch puts entries in the log file around some backend events that regularly cause client pauses, most of which are visible only when running with log_min_messages = debug2. Something that is aimed at a user should not be enabled at a debug level. Debug levels are for debugging, not for very high verbosity. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] COPY-able sql log outputs
Am Dienstag, 3. April 2007 20:33 schrieb FAST PostgreSQL: Attached is the completed patch for the COPY-able sql log outputs. Could you please remove random whitespace changes from this patch? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Current enums patch
Am Dienstag, 27. März 2007 03:36 schrieb Tom Dunstan: Here's the current version of the enums patch. Not much change from last time, the only thought-inducing stuff was fixing up some macros that changed with the VARLENA changes, and adding a regression test to do basic checking of RI behavior, after the discussions that we had recently on the ri_trigger stuff with generic types. The actual behavior was fixed by Tom's earlier patch, so this is just a sanity check. Your patch doesn't compile anymore. ccache cc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I. -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o parse_coerce.o parse_coerce.c -MMD -MP -MF .deps/parse_coerce.Po parse_coerce.c: In function 'can_coerce_type': parse_coerce.c:460: error: too few arguments to function 'find_coercion_pathway' parse_coerce.c: In function 'find_coercion_pathway': parse_coerce.c:1817: error: too few arguments to function 'find_coercion_pathway' parse_coerce.c:1822: error: too few arguments to function 'find_coercion_pathway' This was only changed a few days ago, so you need to update your patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] contrib/spi makefile inconsistency
Magnus Hagander wrote: I would like to change that to actually listing the modules instead. The reason for that is that parsing the Makefile for the msvc build will be a *lot* easier if I don't have to parse $addsuffix rules. Let's not open that can of worms. Even if you think it's only a small can. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] xpath_array with namespaces support
Nikolay Samokhvalov wrote: Here is a new version of the patch. I didn't change any part of docs yet. Since there were no objections I've changed the name of the function to xmlpath(). I didn't see any discussion about changing the name to xmlpath. Seeing that the function implements xpath, and xpath is a recognized name, this change is wrong. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] xpath_array with namespaces support
Bruce Momjian wrote: Patch applied. This code seems to think that if an xml datum starts with ?xml it's a document. That is completely bogus. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] xpath_array with namespaces support
Nikolay Samokhvalov wrote: On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote: I'll fix these issues and extend the patch with resgression tests and docs for xpath_array(). I'll resubmit it very soon. Here is a new version of the patch. I didn't change any part of docs yet. Since there were no objections I've changed the name of the function to xmlpath(). Why is the function not strict? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] xpath_array with namespaces support
Nikolay Samokhvalov wrote: Also, maybe someone can suggest better approach for passing namespace bindings (more convenient than ARRAY[ARRAY[...], ARRAY[...]])? Your code assumes ARRAY[ARRAY['myns', 'myns2'], ARRAY['http://example.com', 'http://example2.com']] Shouldn't it be ARRAY[ARRAY['myns', 'http://example.com'], ARRAY['myns2', 'http://example2.com']] ? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
