Re: [HACKERS] [GENERAL] to_timestamp() and quarters
In response to Bruce Momjian :
Well, I can easily make it do what you expect, and I don't see many
error returns in that area of the code, so I just wrote a patch that
does what you would expect rather than throw an error.
Well, that's great and better than an error, thx.
test= select to_date('2010-7', '-Q');
to_date
2011-07-04
(1 row)
Is this per SQL-Spec? I would expect an error for a quarter not in
(1,2,3,4).
But stop, now i see:
test=*# select to_date('2010-02-29', '-MM-DD');
to_date
2010-03-01
(1 row)
So it is maybe a congruously behavior ;-)
Regards, Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [pgsql-www] [HACKERS] tribble.postgresql.org - planned maintenance downtime
In response to Alvaro Herrera : Jaime Casanova escribió: had your baby born now? Still waiting ... You are pregnant? ;-) Hey, and yes: i wish you and your wife all the best and many fun with the baby. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] creating index names automatically?
In response to Peter Eisentraut : Could we create an option to create index names automatically, so you'd only have to write CREATE INDEX ON foo (a); which would pick a name like foo_a_idx. We already do this in a number of places such as constraint names and sequences without much trouble. In most cases you don't really need to give an index a smart name since the purpose is obvious. Comments? +1, as an additional option, only if no index-name specified. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New PostgreSQL Committers
In response to Dave Page : On behalf of the core team, I'm pleased to announce that the PostgreSQL Project has expanded it's team of committers, those people who are able to make direct changes to the PostgreSQL source code respository. As the project is extremely conservative about any changes made to the source code to minimise the risk of introducing any bugs, commit access is only given to contributors who have consistently shown they work to a very high standard and have shown commitment to the project. The new committers are: Congratulations! +1 Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Update on Insert
SebiF sfe...@gmail.com wrote: Hi Everyone, Given a table Items with a PK item1 and Qty - a numeric column I'd like to define a way in Postgres to insert when item11 doesn't exist already in Items and update the Qty by adding the new quantity to the existent when the item11 exists. What is a good approach and where should I be looking for details. Thanks. 21:53 akretschmer ??upsert 21:53 rtfm_please For information about upsert 21:53 rtfm_please see http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE Read that. Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) If I was god, I would recompile penguin with --enable-fly. (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889° -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] happy birthday Tom Lane ...
In response to Hans-Juergen Schoenig -- PostgreSQL : Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. +1 -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] use of pg_stat_database
In response to abdelhak benmohamed : Hellow, I like to track the number of committed transaction for my database So I use the following command Select * from pg_stat_database; The column xact_commit gives me the number of transaction committed But if I execute the same command another time, the column xact_commit gives me an other number. I can't reproduce that: test=*# Select sum(xact_commit) from pg_stat_database; sum --- 73470 (1 row) -- 5 minutes later: test=*# Select sum(xact_commit) from pg_stat_database; sum --- 73470 (1 row) Between the first select and the second select I don?t execute any transaction on my database Autovacuum? Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] View running statements
In response to Vlad Arkhipov : Is there any way to inspect current running statements (optionally full stack of these statements)? I've found there is error_context_stack variable in each backend, but it seems there is no way to get this variable from another backend. It will be great if Postgres have such kind of mechanism, for instance a system table that consists statements running longer than certain time (5-10 seconds). select * from pg_stat_activity; Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Validating problem in the isn contrib module
In response to Andreas 'ads' Scherbaum :
Hello all,
test=# select is_valid('978-3-937514-69-7'::isbn13);
is_valid
--
t
(1 row)
Nice advertisement for your book...
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to insert the values of .sql file (dump file) into postgresql 8.1
In response to sai srujan : Hi This is srujan and I am beginner of postgresql 8.1 and I have just stopped using mysql and i would like to use the dump (.sql file) created in it. I would like transfer the databases in my sql to postgresql 8.1. Please do reply. I am waiting for it. Thanks in Advance You can try to import your dump with psql -f your_file, but maybe you need to edit the file to change the syntax to postgresql-compatible. You can also use some tools to convert from mysql to postgresql, read the links below: 09:44 pg_docbot_adz http://sql-info.de/mysql/gotchas.html :: http://www.raditha.com/mysql/mysql2pgsql.php :: http://www.in-nomine.org/~asmodai/mysql-to-pgsql.html :: http://pgfoundry.org/projects/mysql2pgsql/ :: http://www.metatrontech.com/wpapers/mysql2postgresql.pdf 09:44 pg_docbot_adz http://www.data-conversions.net/products.php?prod_num=5dest=MENUID=200 :: http://forums.mysql.com/read.php?25,93181,93181 :: http://www.postgresql.org/docs/techdocs.83 :: http://www.scribd.com/doc/2575733/The-future-of-MySQL-The-Project 09:44 pg_docbot_adz http://pgfoundry.org/projects/mysqlcompat :: http://www.xaprb.com/blog/2007/05/31/why-is-null-doesnt-always-work-in-mysql/ :: http://weblogs.asp.net/alex_papadimoulis/archive/2005/10/26/428527.aspx 09:44 pg_docbot_adz http://mike.kruckenberg.com/archives/2006/07/jim_starkey_int_1.html Some of the links are appropriate for you, it is the output from the irc-docbot about mysql. HTH, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] non unique value error... pgsql,,help needed.
In response to Shri : Dear friends, I am trying to import db from oracle to pgsql, meanwhile facing a difficulty during importing oracle numeric(38) to pgsql numeric(38) column, Because in oracle that column is unique, but PGsql not able to correctly identify different and unique values with numeric(38) field. for eg. column: a numeric(38) primary giving me error of non unique value in following two data. 1. 2. 9997 (- both are different.) When i enter first data into column (using EMS SQL MANAGER),it converts it to 1.111444E35 Can you try to insert such values with plain psql? I have tried that and it works without trouble: test=# create table foo (id serial, n numeric(38)); NOTICE: CREATE TABLE will create implicit sequence foo_id_seq for serial column foo.id CREATE TABLE test=*# insert into foo (n) values (); INSERT 0 1 test=*# select * from foo; id | n +-- 1 | (1 row) test=*# insert into foo (n) values (9997); INSERT 0 1 test=*# select * from foo; id | n +-- 1 | 2 | 9997 (2 rows) test=*# Which version do you have? I think, it's a problem with EMS SQL MANAGER, but i don't know that tool. Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] blatantly a bug in the documentation
I hope this is the right place to report a bug/issue in the official
documentation...
In
http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
there is an example for a function, cs_refresh_mviews(), chapter 38.6.4.
Within this function there are a PERFORM cs_log('Refreshing
materialized views...');, but such a function cs_log() are not in the
core distibution.
I think, this is a problem for users which read the doc and try to
reproduce the example or write own code based on the example.
Regards, and many thanks for PostgreSQL to the developer, Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] blatantly a bug in the documentation
am Mon, dem 24.11.2008, um 7:24:47 -0500 mailte Merlin Moncure folgendes:
On Mon, Nov 24, 2008 at 6:02 AM, A. Kretschmer
[EMAIL PROTECTED] wrote:
I hope this is the right place to report a bug/issue in the official
documentation...
In
http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
there is an example for a function, cs_refresh_mviews(), chapter 38.6.4.
Within this function there are a PERFORM cs_log('Refreshing
materialized views...');, but such a function cs_log() are not in the
core distibution.
The example in the docs is pseudo-code. None of the tables referenced
exist either...the purpose of the example was to demonstrate the
syntax of for loops.
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked, why his funktion
don't work. I think, such examples should not contain such code. It is
not apparent that this function are not available.
Again, thx to all people behind PostgreSQL, it is a great thing and it
has a really informatively documentation. My post was only a hint to
make it better.
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] blatantly a bug in the documentation
am Mon, dem 24.11.2008, um 13:47:54 + mailte Dave Page folgendes: On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: A. Kretschmer wrote: Okay, it is an argument. On the other side, it was a question today in the irc-channel (#postgresql) today, someone asked, why his funktion don't work. I think, such examples should not contain such code. It is not apparent that this function are not available. Perhaps the whole chapter could be improved if all the examples referred to a set of tables and functions previously defined in the introduction of the chapter. It would be good if the user could cut'n paste the code and try it out directly, instead of having to reverse engineer the tables/columns used for each example (and they're quite inconsistent). Also, some examples give the complete code including CREATE FUNCTION and others don't. It might also be useful to create such a database at initdb time so newbies have something interesting to look at right away. Nice idea. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] blatantly a bug in the documentation
am Mon, dem 24.11.2008, um 9:02:37 -0500 mailte Tom Lane folgendes: Andrew Dunstan [EMAIL PROTECTED] writes: Dave Page wrote: It might also be useful to create such a database at initdb time so newbies have something interesting to look at right away. No, there is no need to clutter every installation in the world with such a database. You could make it an addon module, or a pgfoundry project. The whole thing strikes me as extreme overkill, not to mention a misunderstanding of what an example is supposed to be for. If we're going to insist that every example in the docs work when copied-and-pasted into an empty database, then simple and to-the-point examples will be history. Instead of one-liners we'll have clutter. For a beginner, a relation 'foo' does not exist is a clean message, but a function foo() does not exist from an example in the doc are a real problem. And, in this example in my first post, the call to the nonexistent function are neither necessary nor 'to-the-point' to explain a for-loop. The starting point for my post was a real question on IRC today. Someone was really confused because he tried to use this nonexistent funktion to log something into a log-file. I think, this example can rewritten, either without this funktion-call or with raise notice ... Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Website request -- developer docs along with release docs
am Mon, dem 27.10.2008, um 19:01:14 +0100 mailte Stefan Kaltenbrunner folgendes: Webb Sprague wrote: Could I request that a link to the developer docs be posted along with the release docs on http://www.postgresql.org/docs/manuals/ they are already referenced in the development section of the website: http://www.postgresql.org/developer/testing I'm not sure we actively should put them on the same page as the release docs - I could imagine people getting confused about that. I think - no. Mark this as dev-docu, but i think, this is a nice feature. Sometimes I'm searching the doc for the next version ( okay, i know where i can find this ), but i'm sure, somebody can't find this docu. The docu for the next version is definitively more important as the docu for, for instance, 7.4 ( this are available via http://www.postgresql.org/docs/manuals/). Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trigger functions broken?
am Wed, dem 08.10.2008, um 14:29:23 -0400 mailte Alvaro Herrera folgendes: Hi, Trigger functions are supposed to be able to be called only as triggers, but apparently the check is not working in CVS HEAD: alvherre=# create or replace function foo () returns trigger as $$ begin perform 1; return new; end; $$ language plpgsql; CREATE FUNCTION alvherre=# select foo(); foo - (1 fila) And? The function returns a TRIGGER, not a value. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command execution
am Thu, dem 03.07.2008, um 23:15:33 +1000 mailte Aaron Spiteri folgendes: Hi guys, I have been following the mailing list and reading the source code for a little while, and was wandering if someone could fill in the gaps for me. Does PostgresQL view updates and inserts performed in a function as part of the same transaction or are they considered separate transactions: For instance say I had a function name foo and ran the command: SELECT foo(); Inside foo there was a INSERT and UPDATE, and the INSERT failed but the UPDATE succeeded would the UPDATE be rolled back? The whole function is an own transaction. Fails the INSERT, the complete function foo failed. In other words; yes, also the UPDATE rolled back. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Strange issue with GiST index scan taking far too long
am Mon, dem 09.06.2008, um 14:18:50 +0100 mailte Mark Cave-Ayland folgendes: Hi there, I'm currently looking at a bug report in PostGIS where we are getting extremely long index scan times querying an index in one case, but the same scan can take much less time if the input geometry is calculated as the result of another function. First of all, I include the EXPLAIN ANALYZE of the basic query which looks like this: postgis=# explain analyze select count(*) from geography where centroid (select the_geom from geography where id=69495); QUERY PLAN - Aggregate (cost=7157.29..7157.30 rows=1 width=0) (actual time=2691.783..2691.784 rows=1 loops=1) InitPlan - Seq Scan on geography (cost=0.00..7149.00 rows=1 width=4559) (actual time=60.987..61.373 rows=1 loops=1) Filter: (id = 69495::numeric) - Index Scan using geography_geom_centroid_idx on geography (cost=0.00..8.28 rows=1 width=0) (actual time=79.241..2645.722 rows=32880 loops=1) Index Cond: (centroid $0) Filter: (centroid $0) Total runtime: 2692.288 ms (8 rows) There are a BIG difference between estimated rows and real rows (1 vs. 32880). Why? Do you have recent statistics? The only real thing to know about the query is that the id field within the geography table is a primary key, and hence only a single geometry Sure? I can't believe this because the rows=32880. is being returned from within the subselect. Note that most of the time is disappearing into the index scan. Where things start getting really strange is when we add an extra function called force_2d() into the mix. All this function does is scan through the single geometry returned from the subselect and remove any 3rd dimension coordinates. Now the resulting EXPLAIN ANALYZE for this query looks like this: postgis=# explain analyze select count(*) from geography where centroid (select force_2d(the_geom) from geography where id=69495); QUERY PLAN Aggregate (cost=7157.29..7157.30 rows=1 width=0) (actual time=343.004..343.005 rows=1 loops=1) InitPlan - Seq Scan on geography (cost=0.00..7149.00 rows=1 width=4559) (actual time=48.714..49.016 rows=1 loops=1) Filter: (id = 69495::numeric) - Index Scan using geography_geom_centroid_idx on geography (cost=0.00..8.28 rows=1 width=0) (actual time=49.367..235.296 rows=32880 loops=1) Index Cond: (centroid $0) Filter: (centroid $0) Total runtime: 343.084 ms (8 rows) So by adding in an extra function around the subselect result, we have speeded up the index lookup by several orders of magnitude, and the Wild guess: you have a big cache. But i'm not a PostGIS-Expert. Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
am Thu, dem 17.04.2008, um 14:39:43 +0200 mailte Peter Eisentraut folgendes: Around http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php it was proposed to truncate the psql welcome screen. What do you think about that? Personally, I'd get rid of it all, because it gets boring after about three uses, so that we would be at [EMAIL PROTECTED]:~$ psql testdb testdb=# I'd vote No, because i see very often on #irc people asking something like 'how can i see the table definition' or other, and in this cases it's easy to say: hey dude, read the fine welcome message *g* Okay, maybe a new switch on the command-line or a .psqlrc-parameter to suppress this message... Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator suggest interval / interval = numeric
am Wed, dem 09.01.2008, um 17:33:00 +0700 mailte Ilya A. Kovalenko folgendes: I suggest one more standard date/time operator, to divide one interval by another with numeric (or float, for example) result. I.e. something like that: database=# SELECT '5400 seconds'::interval / '1 hour'::interval; ?column? -- 1.5 (1 row) test=# SELECT extract(epoch from '5400 seconds'::interval) / extract(epoch from '1 hour'::interval); ?column? -- 1.5 Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Slow count(*)
am Wed, dem 02.01.2008, um 9:29:24 -0600 mailte Abraham, Danny folgendes: Hi, We are looking for a patch that will help us count using the indexes. Our product is about 20 times slower on Postgres compared to MS SQL Server. Any ideas? Please show us your SQL and the execution plan (EXPLAIN or, better, EXPLAIN ANALYSE) and read our FAQ. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
