psql tab completion for DO blocks
Folks,
Please find enclosed a patch which adds tab completion for DO blocks.
Thanks to Andrew Gierth and Stefan Kaltenbrunner for help putting it
together :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachments:
tc_do.difftext/plain; charset=us-asciiDownload
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***************
*** 408,413 **** static const SchemaQuery Query_for_list_of_views = {
--- 408,419 ----
" WHERE lanname != 'internal' "\
" AND substring(pg_catalog.quote_ident(lanname),1,%d)='%s' "
+ #define Query_for_list_of_languages_inline \
+ "SELECT pg_catalog.quote_ident(lanname) "\
+ " FROM pg_language "\
+ " WHERE lanname != 'internal' "\
+ " AND laninline != 0"
+
#define Query_for_list_of_schemas \
"SELECT pg_catalog.quote_ident(nspname) FROM pg_catalog.pg_namespace "\
" WHERE substring(pg_catalog.quote_ident(nspname),1,%d)='%s'"
***************
*** 618,624 **** psql_completion(char *text, int start, int end)
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
--- 624,630 ----
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DO", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
***************
*** 1543,1548 **** psql_completion(char *text, int start, int end)
--- 1549,1572 ----
COMPLETE_WITH_LIST(list_DISCARD);
}
+ /* DO */
+ /*
+ * Complete DO with LANGUAGE.
+ */
+ else if (pg_strcasecmp(prev_wd, "DO") == 0)
+ {
+ static const char *const list_DO[] =
+ {"LANGUAGE", NULL};
+
+ COMPLETE_WITH_LIST(list_DO);
+ }
+ /*
+ * Complete DO LANGUAGE with in-line-able languages.
+ */
+ else if (pg_strcasecmp(prev2_wd, "DO") == 0 &&
+ pg_strcasecmp(prev_wd, "LANGUAGE") == 0)
+ COMPLETE_WITH_QUERY(Query_for_list_of_languages_inline);
+
/* DROP (when not the previous word) */
/* DROP AGGREGATE */
else if (pg_strcasecmp(prev3_wd, "DROP") == 0 &&
David Fetter <david@fetter.org> writes:
Please find enclosed a patch which adds tab completion for DO blocks.
Seems (a) rather pointless and (b) wrong in detail.
regards, tom lane
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
Please find enclosed a patch which adds tab completion for DO
blocks.Seems (a) rather pointless and
I don't find it so.
(b) wrong in detail.
How? That it can't look back past the code block is reflects
limitations in lexx and yacc, a problem which, to put it mildly, is
much larger than I can address in a single patch.
It does produce correct results for front-loading the language in
which the DO block is to be created.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl<tab>, or just compare
source to the original Query_for_list_of_languages.
regards, tom lane
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl<tab>, or just compare
source to the original Query_for_list_of_languages.
Thanks for the heads-up. New patch attached :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachments:
tc_do.difftext/plain; charset=us-asciiDownload
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***************
*** 408,413 **** static const SchemaQuery Query_for_list_of_views = {
--- 408,420 ----
" WHERE lanname != 'internal' "\
" AND substring(pg_catalog.quote_ident(lanname),1,%d)='%s' "
+ #define Query_for_list_of_languages_inline \
+ "SELECT pg_catalog.quote_ident(lanname) "\
+ " FROM pg_language "\
+ " WHERE lanname != 'internal' "\
+ " AND laninline != 0"\
+ " AND substring(pg_catalog.quote_ident(lanname),1,%d)='%s' "
+
#define Query_for_list_of_schemas \
"SELECT pg_catalog.quote_ident(nspname) FROM pg_catalog.pg_namespace "\
" WHERE substring(pg_catalog.quote_ident(nspname),1,%d)='%s'"
***************
*** 618,624 **** psql_completion(char *text, int start, int end)
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
--- 625,631 ----
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DO", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
***************
*** 1543,1548 **** psql_completion(char *text, int start, int end)
--- 1550,1573 ----
COMPLETE_WITH_LIST(list_DISCARD);
}
+ /* DO */
+ /*
+ * Complete DO with LANGUAGE.
+ */
+ else if (pg_strcasecmp(prev_wd, "DO") == 0)
+ {
+ static const char *const list_DO[] =
+ {"LANGUAGE", NULL};
+
+ COMPLETE_WITH_LIST(list_DO);
+ }
+ /*
+ * Complete DO LANGUAGE with in-line-able languages.
+ */
+ else if (pg_strcasecmp(prev2_wd, "DO") == 0 &&
+ pg_strcasecmp(prev_wd, "LANGUAGE") == 0)
+ COMPLETE_WITH_QUERY(Query_for_list_of_languages_inline);
+
/* DROP (when not the previous word) */
/* DROP AGGREGATE */
else if (pg_strcasecmp(prev3_wd, "DROP") == 0 &&
David Fetter <david@fetter.org> writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl<tab>, or just compare
source to the original Query_for_list_of_languages.
Thanks for the heads-up. New patch attached :)
My inclination is to not have the separate query at all, but just
use Query_for_list_of_languages. The extra maintenance burden of
two almost identical queries is not justified here IMO. Maybe it
would be if we foresaw that most languages would remain without
inline handlers indefinitely, but I think that pretty soon the
only one that the query is actually excluding would be 'C', and
it's not worth trying to remove that from the list.
regards, tom lane
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote:
David Fetter <david@fetter.org> writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pl<tab>, or just compare
source to the original Query_for_list_of_languages.Thanks for the heads-up. New patch attached :)
My inclination is to not have the separate query at all,
I made one so people couldn't tab complete themselves an unpleasant
surprise. The overhead doesn't seem huge.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
My inclination is to not have the separate query at all,
I made one so people couldn't tab complete themselves an unpleasant
surprise. The overhead doesn't seem huge.
What unpleasant surprise is that going to be? They'll get an error
message telling them there's no inline support. That seems to me to
be more user-friendly than forcing them to type out the language name
and then getting the same error message.
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn minimal,
since most people are more likely to rely on default_do_language;
so I don't see the point of carrying an extra query to tweak the
behavior in a way that isn't even obviously an improvement.
regards, tom lane
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;
We really don't have any data on that, and it doesn't seem all that
likely to me.
Peter Eisentraut <peter_e@gmx.net> writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;
We really don't have any data on that, and it doesn't seem all that
likely to me.
I'm not really objecting to putting in the patch entirely. I'm objecting
to carrying an extra completion query for it. I don't think hiding
languages with laninline=0 improves its usefulness at all, let alone
enough to justify extra maintenance burden.
regards, tom lane
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;We really don't have any data on that, and it doesn't seem all that
likely to me.I'm not really objecting to putting in the patch entirely. I'm objecting
to carrying an extra completion query for it. I don't think hiding
languages with laninline=0 improves its usefulness at all, let alone
enough to justify extra maintenance burden.
As a practical matter there aren't that many languages in the first
place, and many of them begin with the same few letters. If you have
both plperl and plpython loaded (and they both have inline handlers)
you'll have to type four characters to disambiguate, and by that time
(especially for plperl) you might as well just finish typing it by
hand.
Having said that, I don't see much value in deliberately making the
tab-completion list fail to match the set of arguments that will
actually work. The maintenance burden of an additional query strikes
me as not worth worrying about. If David finds it useful and/or has
users who want it, I think we should just do it.
...Robert
Robert Haas wrote:
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On l?r, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. ?I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;We really don't have any data on that, and it doesn't seem all that
likely to me.I'm not really objecting to putting in the patch entirely. ?I'm objecting
to carrying an extra completion query for it. ?I don't think hiding
languages with laninline=0 improves its usefulness at all, let alone
enough to justify extra maintenance burden.As a practical matter there aren't that many languages in the first
place, and many of them begin with the same few letters. If you have
both plperl and plpython loaded (and they both have inline handlers)
you'll have to type four characters to disambiguate, and by that time
(especially for plperl) you might as well just finish typing it by
hand.Having said that, I don't see much value in deliberately making the
tab-completion list fail to match the set of arguments that will
actually work. The maintenance burden of an additional query strikes
me as not worth worrying about. If David finds it useful and/or has
users who want it, I think we should just do it.
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/pgpatches/psql_DOtext/x-diffDownload
Index: src/bin/psql/tab-complete.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/tab-complete.c,v
retrieving revision 1.192
diff -c -c -r1.192 tab-complete.c
*** src/bin/psql/tab-complete.c 25 Jan 2010 18:23:09 -0000 1.192
--- src/bin/psql/tab-complete.c 6 Feb 2010 19:09:26 -0000
***************
*** 618,624 ****
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
--- 618,624 ----
static const char *const sql_commands[] = {
"ABORT", "ALTER", "ANALYZE", "BEGIN", "CHECKPOINT", "CLOSE", "CLUSTER",
"COMMENT", "COMMIT", "COPY", "CREATE", "DEALLOCATE", "DECLARE",
! "DELETE FROM", "DISCARD", "DO", "DROP", "END", "EXECUTE", "EXPLAIN", "FETCH",
"GRANT", "INSERT", "LISTEN", "LOAD", "LOCK", "MOVE", "NOTIFY", "PREPARE",
"REASSIGN", "REINDEX", "RELEASE", "RESET", "REVOKE", "ROLLBACK",
"SAVEPOINT", "SELECT", "SET", "SHOW", "START", "TABLE", "TRUNCATE", "UNLISTEN",
***************
*** 1532,1537 ****
--- 1532,1555 ----
COMPLETE_WITH_LIST(list_DISCARD);
}
+ /* DO */
+ /*
+ * Complete DO with LANGUAGE.
+ */
+ else if (pg_strcasecmp(prev_wd, "DO") == 0)
+ {
+ static const char *const list_DO[] =
+ {"LANGUAGE", NULL};
+
+ COMPLETE_WITH_LIST(list_DO);
+ }
+ /*
+ * Complete DO LANGUAGE with in-line-able languages.
+ */
+ else if (pg_strcasecmp(prev2_wd, "DO") == 0 &&
+ pg_strcasecmp(prev_wd, "LANGUAGE") == 0)
+ COMPLETE_WITH_QUERY(Query_for_list_of_languages);
+
/* DROP (when not the previous word) */
/* DROP AGGREGATE */
else if (pg_strcasecmp(prev3_wd, "DROP") == 0 &&
Bruce Momjian <bruce@momjian.us> wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
I don't think we need the patch except adding DO to the top-level sql_commands.
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
We need 'code' before LANGUAGE, but the patch completes "DO" to "DO LANGUAGE".
It will be just a syntax error.
Also, we've already had a completion after LANGUAGE (see words_after_create),
so we don't need an additional Query_for_list_of_languages after LANGUAGE.
BTW, I'm working on psql tab-completion adjustment for new syntax in 9.0.
I'll send it soon.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
Takahiro Itagaki wrote:
Bruce Momjian <bruce@momjian.us> wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.I don't think we need the patch except adding DO to the top-level sql_commands.
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
We need 'code' before LANGUAGE, but the patch completes "DO" to "DO LANGUAGE".
It will be just a syntax error.Also, we've already had a completion after LANGUAGE (see words_after_create),
so we don't need an additional Query_for_list_of_languages after LANGUAGE.
Ah, I see. I had not checked the patch against the actual syntax; shame
on me.
BTW, I'm working on psql tab-completion adjustment for new syntax in 9.0.
I'll send it soon.
OK, thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote:
Bruce Momjian <bruce@momjian.us> wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.I don't think we need the patch except adding DO to the top-level sql_commands.
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
CREATE LANGUAGE plperl;
CREATE TABLE foo(id SERIAL PRIMARY KEY, t TEXT);
DO LANGUAGE plperl $$spi_exec_query(q[INSERT INTO foo(t) VALUES('aaa')]);$$;
SELECT * FROM foo;
The DO LANGUAGE lang_name code syntax is much clearer, as far as I'm
concerned, than putting the code block before the language anyhow. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
Hmmm, but we mention only above syntax in the documentation.
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
Should we fix the documentation when we add the tab completion?
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional parameters in the
middle of the command rather than at the end.
--
Euler Taveira de Oliveira
http://www.timbira.com/
On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote:
David Fetter <david@fetter.org> wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:Hmmm, but we mention only above syntax in the documentation.
http://developer.postgresql.org/pgdocs/postgres/sql-do.htmlShould we fix the documentation when we add the tab completion?
Yes :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote:
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional
parameters in the middle of the command rather than at the end.
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
If it is arbitrary the synopsis is wrong because it is imposing that code
should be written after DO. It should be:
DO { [ LANGUAGE lang_name ] | code } ...
--
Euler Taveira de Oliveira
http://www.timbira.com/
On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote:
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.If it is arbitrary the synopsis is wrong because it is imposing that
code should be written after DO. It should be:DO { [ LANGUAGE lang_name ] | code } ...
Good catch :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate