Re: [HACKERS] PGXS problem with pdftotext
Hi, Le 2 juil. 09 à 22:20, Kevin Grittner a écrit : Here's the Makefile contents: You could compare to this: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/backports/uuid-ossp/Makefile?rev=1.1.1.1content-type=text/x-cvsweb-markup SHLIB_LINK = -lpoppler -L/usr/local/lib SHLIB_LINK += $(OSSP_UUID_LIBS) Dunno how far it'll get you, but it may help some :) Regards, -- dim -- 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] First CommitFest: July 15th
On Friday 03 July 2009 05:16:41 Robert Haas wrote: On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote: Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700: Folks, There's been a lot of discussion/argument around how to handle the last commitfest, but there seems to be a total consensus that we want to have the first CF on July 15th. Can we add flags like bump catalog version, bump page layout version, modify AM for each patch? It should help to track pg_upgrade changes. That's not a bad idea, and it wouldn't be hard to add various flags and things to the CommitFest app I wrote, but how would we maintain the information and keep it correct? It seems like there might be a danger that patch authors wouldn't know whether or not they were doing those things. Also, how would we handle changes by committers, who don't always go through the CommitFest process? I think this information could be computed automatically, if someone cared enough. It shouldn't be necessary to bother every single participant in the process with this. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Provide support for multiplexing SIGUSR1 signal
Hi, http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php In line with Robert's suggestion, I submit the signal multiplexing patch as self-contained one. This patch provides support for multiplexing SIGUSR1 signal. The upcoming synchronous replication patch needs a signal, but we've already used SIGUSR1 and SIGUSR2 in normal backends. This patch allows reusing SIGUSR1 for that, and for other purposes too if the need arises. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center diff -rcN base/src/backend/bootstrap/bootstrap.c new/src/backend/bootstrap/bootstrap.c *** base/src/backend/bootstrap/bootstrap.c 2009-06-30 15:02:41.0 +0900 --- new/src/backend/bootstrap/bootstrap.c 2009-06-30 15:02:42.0 +0900 *** *** 35,40 --- 35,41 #include storage/bufmgr.h #include storage/ipc.h #include storage/proc.h + #include storage/procsignal.h #include tcop/tcopprot.h #include utils/builtins.h #include utils/fmgroids.h *** *** 388,393 --- 389,405 InitAuxiliaryProcess(); #endif + /* + * Assign backend ID to auxiliary processes like backends, in order to + * allow multiplexing signal to auxiliary processes. Since backends use + * ID in the range from 1 to MaxBackends (inclusive), we assign + * auxiliary processes with MaxBackends + AuxProcType + 1 as an unique ID. + */ + MyBackendId = MaxBackends + auxType + 1; + MyProc-backendId = MyBackendId; + + ProcSignalInit(); + /* finish setting up bufmgr.c */ InitBufferPoolBackend(); diff -rcN base/src/backend/postmaster/autovacuum.c new/src/backend/postmaster/autovacuum.c *** base/src/backend/postmaster/autovacuum.c 2009-06-30 15:02:41.0 +0900 --- new/src/backend/postmaster/autovacuum.c 2009-06-30 15:02:42.0 +0900 *** *** 91,96 --- 91,97 #include storage/pmsignal.h #include storage/proc.h #include storage/procarray.h + #include storage/procsignal.h #include storage/sinvaladt.h #include tcop/tcopprot.h #include utils/dynahash.h *** *** 1501,1507 pqsignal(SIGALRM, handle_sig_alarm); pqsignal(SIGPIPE, SIG_IGN); ! pqsignal(SIGUSR1, CatchupInterruptHandler); /* We don't listen for async notifies */ pqsignal(SIGUSR2, SIG_IGN); pqsignal(SIGFPE, FloatExceptionHandler); --- 1502,1508 pqsignal(SIGALRM, handle_sig_alarm); pqsignal(SIGPIPE, SIG_IGN); ! pqsignal(SIGUSR1, procsignal_sigusr1_handler); /* We don't listen for async notifies */ pqsignal(SIGUSR2, SIG_IGN); pqsignal(SIGFPE, FloatExceptionHandler); diff -rcN base/src/backend/storage/ipc/Makefile new/src/backend/storage/ipc/Makefile *** base/src/backend/storage/ipc/Makefile 2009-06-30 15:02:41.0 +0900 --- new/src/backend/storage/ipc/Makefile 2009-06-30 15:02:42.0 +0900 *** *** 15,21 endif endif ! OBJS = ipc.o ipci.o pmsignal.o procarray.o shmem.o shmqueue.o \ sinval.o sinvaladt.o include $(top_srcdir)/src/backend/common.mk --- 15,21 endif endif ! OBJS = ipc.o ipci.o pmsignal.o procarray.o procsignal.o shmem.o shmqueue.o \ sinval.o sinvaladt.o include $(top_srcdir)/src/backend/common.mk diff -rcN base/src/backend/storage/ipc/ipci.c new/src/backend/storage/ipc/ipci.c *** base/src/backend/storage/ipc/ipci.c 2009-06-30 15:02:41.0 +0900 --- new/src/backend/storage/ipc/ipci.c 2009-06-30 15:02:42.0 +0900 *** *** 30,35 --- 30,36 #include storage/pg_shmem.h #include storage/pmsignal.h #include storage/procarray.h + #include storage/procsignal.h #include storage/sinvaladt.h #include storage/spin.h *** *** 114,119 --- 115,121 size = add_size(size, PMSignalShmemSize()); size = add_size(size, BgWriterShmemSize()); size = add_size(size, AutoVacuumShmemSize()); + size = add_size(size, ProcSignalShmemSize()); size = add_size(size, BTreeShmemSize()); size = add_size(size, SyncScanShmemSize()); #ifdef EXEC_BACKEND *** *** 210,215 --- 212,218 PMSignalShmemInit(); BgWriterShmemInit(); AutoVacuumShmemInit(); + ProcSignalShmemInit(); /* * Set up other modules that need some shared memory space diff -rcN base/src/backend/storage/ipc/procsignal.c new/src/backend/storage/ipc/procsignal.c *** base/src/backend/storage/ipc/procsignal.c 1970-01-01 09:00:00.0 +0900 --- new/src/backend/storage/ipc/procsignal.c 2009-06-30 15:02:42.0 +0900 *** *** 0 --- 1,216 + /*- + * + * procsignal.c + * routines for signaling processes + * + * + * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group + * Portions Copyright (c) 1994, Regents of the University of California + * + * IDENTIFICATION + * $PostgreSQL$ + * +
[HACKERS] Non-blocking communication between a frontend and a backend (pqcomm)
Hi, http://archives.postgresql.org/pgsql-hackers/2009-07/msg00191.php In line with Robert's suggestion, I submit non-blocking pqcomm patch as a self-contained one. This patch provides support for non-blocking communication between a frontend and a backend. The upcoming synchronous replication patch needs this to make walsender send XLOG records and receive a reply from the standby server concurrently. Specifically, this patch provides the function to check for a socket by using select() / poll(), and the functions to read the data from local buffer instead of the connection. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center nonblocking_pqcomm_0703.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] tsvector extraction patch
hello,
this patch has not made it through yesterday, so i am trying to send it
again.
i made a small patch which i found useful for my personal tasks.
it would be nice to see this in 8.5. if not core then maybe contrib.
it transforms a tsvector to table format which is really nice for text
processing and comparison.
test=# SELECT * FROM tsvcontent(to_tsvector('english', 'i am pretty sure
this is a good patch'));
lex | rank
+--
good |8
patch |9
pretti |3
sure |4
(4 rows)
many thanks,
hans
--
Cybertec Schoenig Schoenig GmbH
Reyergasse 9 / 2
A-2700 Wiener Neustadt
Web: www.postgresql-support.de
--
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] tsvector extraction patch
Hans-Juergen Schoenig -- PostgreSQL wrote:
hello,
this patch has not made it through yesterday, so i am trying to send
it again.
i made a small patch which i found useful for my personal tasks.
it would be nice to see this in 8.5. if not core then maybe contrib.
it transforms a tsvector to table format which is really nice for text
processing and comparison.
test=# SELECT * FROM tsvcontent(to_tsvector('english', 'i am pretty
sure this is a good patch'));
lex | rank
+--
good |8
patch |9
pretti |3
sure |4
(4 rows)
many thanks,
hans
--
Cybertec Schoenig Schoenig GmbH
Reyergasse 9 / 2
A-2700 Wiener Neustadt
Web: www.postgresql-support.de
diff -dcrpN postgresql-8.4.0.old/contrib/Makefile postgresql-8.4.0/contrib/Makefile
*** postgresql-8.4.0.old/contrib/Makefile 2009-03-26 00:20:01.0 +0100
--- postgresql-8.4.0/contrib/Makefile 2009-06-29 11:03:04.0 +0200
*** WANTED_DIRS = \
*** 39,44
--- 39,45
tablefunc \
test_parser \
tsearch2 \
+ tsvcontent \
vacuumlo
ifeq ($(with_openssl),yes)
diff -dcrpN postgresql-8.4.0.old/contrib/tsvcontent/Makefile postgresql-8.4.0/contrib/tsvcontent/Makefile
*** postgresql-8.4.0.old/contrib/tsvcontent/Makefile 1970-01-01 01:00:00.0 +0100
--- postgresql-8.4.0/contrib/tsvcontent/Makefile 2009-06-29 11:20:21.0 +0200
***
*** 0
--- 1,19
+ # $PostgreSQL: pgsql/contrib/tablefunc/Makefile,v 1.9 2007/11/10 23:59:51 momjian Exp $
+
+ MODULES = tsvcontent
+ DATA_built = tsvcontent.sql
+ DATA = uninstall_tsvcontent.sql
+
+
+ SHLIB_LINK += $(filter -lm, $(LIBS))
+
+ ifdef USE_PGXS
+ PG_CONFIG = pg_config
+ PGXS := $(shell $(PG_CONFIG) --pgxs)
+ include $(PGXS)
+ else
+ subdir = contrib/tsvcontent
+ top_builddir = ../..
+ include $(top_builddir)/src/Makefile.global
+ include $(top_srcdir)/contrib/contrib-global.mk
+ endif
diff -dcrpN postgresql-8.4.0.old/contrib/tsvcontent/tsvcontent.c postgresql-8.4.0/contrib/tsvcontent/tsvcontent.c
*** postgresql-8.4.0.old/contrib/tsvcontent/tsvcontent.c 1970-01-01 01:00:00.0 +0100
--- postgresql-8.4.0/contrib/tsvcontent/tsvcontent.c 2009-06-29 11:18:35.0 +0200
***
*** 0
--- 1,169
+ #include postgres.h
+
+ #include fmgr.h
+ #include funcapi.h
+ #include miscadmin.h
+ #include executor/spi.h
+ #include lib/stringinfo.h
+ #include nodes/nodes.h
+ #include utils/builtins.h
+ #include utils/lsyscache.h
+ #include utils/syscache.h
+ #include utils/memutils.h
+ #include tsearch/ts_type.h
+ #include tsearch/ts_utils.h
+ #include catalog/pg_type.h
+
+ #include tsvcontent.h
+
+ PG_MODULE_MAGIC;
+
+ PG_FUNCTION_INFO_V1(tsvcontent);
+
+ Datum
+ tsvcontent(PG_FUNCTION_ARGS)
+ {
+ FuncCallContext *funcctx;
+ TupleDesc ret_tupdesc;
+ AttInMetadata *attinmeta;
+ int call_cntr;
+ int max_calls;
+ ts_to_txt_fctx *fctx;
+ Datum result[2];
+ bool isnull[2] = { false, false };
+ MemoryContext oldcontext;
+
+ /* input value containing the TS vector */
+ TSVector in = PG_GETARG_TSVECTOR(0);
+
+ /* stuff done only on the first call of the function */
+ if (SRF_IS_FIRSTCALL())
+ {
+ TupleDesc tupdesc;
+ int i, j;
+ char *wepv_base;
+
+ /* create a function context for cross-call persistence */
+ funcctx = SRF_FIRSTCALL_INIT();
+
+ /*
+ * switch to memory context appropriate for multiple function calls
+ */
+ oldcontext = MemoryContextSwitchTo(funcctx-multi_call_memory_ctx);
+
+ switch (get_call_result_type(fcinfo, NULL, tupdesc))
+ {
+ case TYPEFUNC_COMPOSITE:
+ /* success */
+ break;
+ case TYPEFUNC_RECORD:
+ /* failed to determine actual type of RECORD */
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg(function returning record called in context
+ that cannot accept type record)));
+ break;
+ default:
+ /* result type isn't composite */
+ elog(ERROR, return type must be a row type);
+ break;
+ }
+
+ /* make sure we have a persistent copy of the tupdesc */
+ tupdesc = CreateTupleDescCopy(tupdesc);
+
+ /*
+ * Generate attribute metadata needed later to produce tuples from raw
+ * C strings
+ */
+ attinmeta = TupleDescGetAttInMetadata(tupdesc);
+ funcctx-attinmeta = attinmeta;
+
+ /* allocate memory */
+ fctx = (ts_to_txt_fctx *) palloc(sizeof(ts_to_txt_fctx));
+
+ wepv_base = (char *)in + offsetof(TSVectorData, entries) + in-size * sizeof(WordEntry);
+
+ fctx-n_tsvt = 0;
+ for (i = 0; i in-size; i++)
+ {
+ if (in-entries[i].haspos)
+ {
+ WordEntryPosVector *wepv = (WordEntryPosVector *)
+ (wepv_base + in-entries[i].pos + SHORTALIGN(in-entries[i].len));
+
+ fctx-n_tsvt += wepv-npos;
+ }
+ else
+ fctx-n_tsvt++;
+ }
+
+ fctx-tsvt = palloc(fctx-n_tsvt * sizeof(tsvec_tuple));
+
+ for (i = 0, j = 0; i in-size; i++)
+ {
+ int pos = in-entries[i].pos;
+
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? This is where we left off: http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com I was in the process of simplifying Simon's last patch, by removing the concept of recovery procs, and simplifying the association between subxids and top xids is communicated to the slave. The above link contains an experimental patch for that. The simplifications probably left behind some more crud that can now be removed, or things that were broken. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] bug in Google translate snippet
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Hi,
I was having a look at this snippet:
http://wiki.postgresql.org/wiki/Google_Translate
and it turns out that it doesn't work if the result contains non-ASCII
chars. Does anybody know how to fix it?
alvherre=# select gtranslate('en', 'es', 'he');
ERROR: plpython: function gtranslate could not create return value
DETALLE: type 'exceptions.UnicodeEncodeError': 'ascii' codec can't
encode character u'\xe9' in position 0: ordinal not in range(128)
This looks like a python issue rather than a Postgres issue. The problem
is probably in python-simplejson.
I think the problem happens when the PL tries to create the output
value. Otherwise I wouldn't be able to see the value in plpy.log.
The problem is that the thing you are trying to return
(resp['responseData']['translatedText']) is a Unicode object, so you
can't just print it. The error comes from Python complaining that you
are trying to output an 8-bit character using the 'ascii' codec, that
cannot encode that.
One solution is to explicitly encode the Unicode string with some codec,
that is: ask Python to convert the Unicode object into a blob using some
serialization method, UTF-8 being a good method here. For instance
return resp['responseData']['translatedText'].encode('utf-8')
worked for me.
See also http://docs.python.org/tutorial/introduction.html#unicode-strings
Cheers,
Jan
--
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] GRANT ON ALL IN schema
Petr Jelinek wrote:
So, here is the first version of the patch.
Attached is v2 with slightly improved code, nothing has changed
feature-wise.
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bf963b8..7ddbd25 100644
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
*** PostgreSQL documentation
*** 23,39
synopsis
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER
}
[,...] | ALL [ PRIVILEGES ] }
! ON [ TABLE ] replaceable class=PARAMETERtablename/replaceable [,
...]
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( replaceable
class=PARAMETERcolumn/replaceable [, ...] )
[,...] | ALL [ PRIVILEGES ] ( replaceable
class=PARAMETERcolumn/replaceable [, ...] ) }
! ON [ TABLE ] replaceable class=PARAMETERtablename/replaceable [,
...]
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { USAGE | SELECT | UPDATE }
[,...] | ALL [ PRIVILEGES ] }
! ON SEQUENCE replaceable class=PARAMETERsequencename/replaceable [,
...]
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [,...] | ALL [ PRIVILEGES ] }
--- 23,41
synopsis
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER
}
[,...] | ALL [ PRIVILEGES ] }
! ON { { [ TABLE | VIEW ] replaceable
class=PARAMETERtablename/replaceable [, ...] }
! | ALL [ TABLES | VIEWS ] IN replaceableschemaname/replaceable [, ...]
}
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( replaceable
class=PARAMETERcolumn/replaceable [, ...] )
[,...] | ALL [ PRIVILEGES ] ( replaceable
class=PARAMETERcolumn/replaceable [, ...] ) }
! ON [ TABLE | VIEW ] replaceable
class=PARAMETERtablename/replaceable [, ...]
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { USAGE | SELECT | UPDATE }
[,...] | ALL [ PRIVILEGES ] }
! ON { SEQUENCE replaceable class=PARAMETERsequencename/replaceable
[, ...]
! | ALL SEQUENCES IN replaceableschemaname/replaceable [, ...] }
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [,...] | ALL [ PRIVILEGES ] }
*** GRANT { USAGE | ALL [ PRIVILEGES ] }
*** 49,55
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
! ON FUNCTION replaceablefuncname/replaceable ( [ [ replaceable
class=parameterargmode/replaceable ] [ replaceable
class=parameterargname/replaceable ] replaceable
class=parameterargtype/replaceable [, ...] ] ) [, ...]
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
--- 51,58
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
! ON { FUNCTION replaceablefuncname/replaceable ( [ [ replaceable
class=parameterargmode/replaceable ] [ replaceable
class=parameterargname/replaceable ] replaceable
class=parameterargtype/replaceable [, ...] ] ) [, ...]
! | ALL FUNCTIONS IN replaceableschemaname/replaceable [, ...] }
TO { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
*** GRANT replaceable class=PARAMETERrol
*** 143,148
--- 146,158
/para
para
+There is also the posibility of granting permissions to all objects of
+given type inside one or multiple schemas. This functionality is supported
+for tables, views, sequences and functions and can done by using
+ALL TABLES IN schemanema syntax in place of object name.
+ /para
+
+ para
The possible privileges are:
variablelist
diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml
index 8d62580..ac0905f 100644
*** a/doc/src/sgml/ref/revoke.sgml
--- b/doc/src/sgml/ref/revoke.sgml
*** PostgreSQL documentation
*** 24,44
REVOKE [ GRANT OPTION FOR ]
{ { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[,...] | ALL [ PRIVILEGES ] }
! ON [ TABLE ] replaceable class=PARAMETERtablename/replaceable [,
...]
FROM { [ GROUP ] replaceable class=PARAMETERrolename/replaceable |
PUBLIC } [, ...]
[ CASCADE | RESTRICT ]
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com writes: Please let us know if you encounter any problems with withe app, or have suggestions for improvement. It looks like every patch and comment is timestamped ... but with yesterday (the time of data import, I suppose). This is much worse than useless. If you can't get the actual date, leave it off. regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. regards, tom lane -- 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] bug in Google translate snippet
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Hi,
I was having a look at this snippet:
http://wiki.postgresql.org/wiki/Google_Translate
and it turns out that it doesn't work if the result contains non-ASCII
chars. Does anybody know how to fix it?
alvherre=# select gtranslate('en', 'es', 'he');
ERROR: plpython: function gtranslate could not create return value
DETALLE: type 'exceptions.UnicodeEncodeError': 'ascii' codec can't
encode character u'\xe9' in position 0: ordinal not in range(128)
This looks like a python issue rather than a Postgres issue. The problem
is probably in python-simplejson.
I think the problem happens when the PL tries to create the output
value. Otherwise I wouldn't be able to see the value in plpy.log.
The problem is that the thing you are trying to return
(resp['responseData']['translatedText']) is a Unicode object, so you
can't just print it. The error comes from Python complaining that you
are trying to output an 8-bit character using the 'ascii' codec, that
cannot encode that.
One solution is to explicitly encode the Unicode string with some codec,
that is: ask Python to convert the Unicode object into a blob using some
serialization method, UTF-8 being a good method here. For instance
return resp['responseData']['translatedText'].encode('utf-8')
worked for me.
See also http://docs.python.org/tutorial/introduction.html#unicode-strings
Cheers,
Jan
--
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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. You've asked to view a commitfest. The id of that commitfest is 2. What more do you want to know? If you're advocating for the use of wiki-style names, where the URL actually contains the name of the things that it points to, then you have incompatible requirements, because things can, do, and will continue to get renamed. If the URL is built around the name, then the URL will change when the name changes. If you want it to be stable, a non-natural key is your only option. And I frankly don't see what's wrong with that. We regularly deal in message-IDs or other links to the archives, which are certainly totally opaque. Fortunately, they're links. You can click on them, and then you see what they are. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 10:40 AM, Tom Lanet...@sss.pgh.pa.us wrote: I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. The message-ID is the (optional) ID of a message you'd like to link to. The comment is the text of your comment. If there's a legitimate reason for confusion here, I have no idea what it is. I agree that the comment box probably needs to be converted into a text area rather than a single line. But I also think that comments on the wiki should be kept short. If you have more than a few lines of text, there's a good chance you should be sending an email to -hackers and then linking to it. There are some projects that are managed using a discussion forum or a bug tracker and as far as I know you've always been opposed to that, as am I. So complaining that this system doesn't work that way seems disingenuous. Also, if you think this interface is inconvenient for leaving a comment, have you tried doing it on the wiki lately? Anyway, I'm sure there's room for improvement in this tool. I intend to make improvements. I still think it's already better than the wiki. Moving things to a different commitfest or a different section of the same commitfest (like, particularly relevant to you, the committed section) is takes me minutes on the wiki and seconds with this app. ...Robert -- 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] [PATCH] SE-PostgreSQL Updates rev.2096
On Fri, Jul 3, 2009 at 1:18 AM, KaiGai Koheikai...@kaigai.gr.jp wrote: OK, I'll re-organize my patch set. Please wait for a few days. Note that your patch will need to include docs and regression test updates, and those things need to be coherent with the rest of the patch. You can't submit a subset of the patches that implement 25% of the feature set you ultimately want to have, and docs that describe the entire feature set as if it's already all committed. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas wrote: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. We have redirects to the previous, open, and in-progress commitfests in the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those redirects are bookmarkable. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:40 AM, Tom Lanet...@sss.pgh.pa.us wrote: I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. The message-ID is the (optional) ID of a message you'd like to link to. The comment is the text of your comment. If there's a legitimate reason for confusion here, I have no idea what it is. It's not apparent that the message-ID is optional, nor what it is for really. And the fact that the boxes are the same size leaves one wondering what the comment is supposed to be too. The basic complaint is that the page assumes you already know what to do with it. Given the vast amount of white space left behind by the omission of any context information, it doesn't seem unreasonable to include a couple sentences of explanation. I agree that the comment box probably needs to be converted into a text area rather than a single line. But I also think that comments on the wiki should be kept short. If you have more than a few lines of text, there's a good chance you should be sending an email to -hackers and then linking to it. There are some projects that are managed using a discussion forum or a bug tracker and as far as I know you've always been opposed to that, as am I. So complaining that this system doesn't work that way seems disingenuous. Also, if you think this interface is inconvenient for leaving a comment, have you tried doing it on the wiki lately? I spent a large part of the last year leaving comments on the wiki. Yeah, it was a bit tedious to use wiki markup, but at least all the information you needed was a click away. (The wiki wasn't designed on the assumption that users already know how to use it.) And the context didn't all disappear from view the moment you wanted to add something. I still think it's already better than the wiki. Maybe to you, but right now I think the wiki is far more usable and far more flexible. It hasn't got arbitrary assumptions about what size comment people are allowed to leave, for example. regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 11:46 AM, Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote: Robert Haas wrote: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. We have redirects to the previous, open, and in-progress commitfests in the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those redirects are bookmarkable. We can do the same thing here. It's a SMOP. ...Robert -- 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] pg_migrator mention in documentation
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Also, the recommendation to specify prefix here is redundant and error-prone. It can get the correct prefix from pg_config. Again, see my email just posted about using pg_migrator in a multi-pg_config-binary environment. What's your point? If the wrong pg_config is first in the path, PGXS will do the wrong things anyway. Specifying install prefix manually is not enough to prevent that. If the pg_migrator makefiles conformed to the accepted syntax for PGXS invocation (click click ... which they do now) then the preferred solution for this would be to explicitly specify the pg_config location, *and nothing else*, on the make command line. gmake USE_PGXS=1 PG_CONFIG=/path/to/pg_config install I'm inclined to agree with Peter that the current documentation is just going to confuse people by giving them too many options. I would agree with removing the ifdef USE_PGXS from the makefiles so that the USE_PGXS=1 bit can go away, and then saying If the new installation's pg_config is first in your path, you can just say gmake install Otherwise, or to be extra sure, say gmake PG_CONFIG=/path/to/pg_config install (Although actually, if that pg_config isn't in your path, the installed pg_migrator won't be either. It might be better to just say fix things so that the new installation's executables are first in your PATH, and be done with it.) regards, tom lane -- 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] 8.5 development schedule
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Robert Haas wrote: What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? This is where we left off: http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com There were adjacent remarks suggesting that large other parts of the patch remained to be reviewed, as well. http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php regards, tom lane -- 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] pg_migrator mention in documentation
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: Also, the recommendation to specify prefix here is redundant and error-prone. It can get the correct prefix from pg_config. Again, see my email just posted about using pg_migrator in a multi-pg_config-binary environment. What's your point? If the wrong pg_config is first in the path, PGXS will do the wrong things anyway. Specifying install prefix manually is not enough to prevent that. I already tell them to make sure the new one is first in the path: A third install method is to use PGXS (assuming the new 'pg_config' is the first 'pg_config' in your $PATH): If the pg_migrator makefiles conformed to the accepted syntax for PGXS invocation (click click ... which they do now) then the preferred Good, thanks. solution for this would be to explicitly specify the pg_config location, *and nothing else*, on the make command line. gmake USE_PGXS=1 PG_CONFIG=/path/to/pg_config install OK, I have updated the INSTALL file to use that and not tell them to modify their path. I'm inclined to agree with Peter that the current documentation is just going to confuse people by giving them too many options. I would agree with removing the ifdef USE_PGXS from the makefiles so that the USE_PGXS=1 bit can go away, and then saying If the new installation's pg_config is first in your path, you can just say gmake install Otherwise, or to be extra sure, say gmake PG_CONFIG=/path/to/pg_config install (Although actually, if that pg_config isn't in your path, the installed pg_migrator won't be either. It might be better to just say fix things so that the new installation's executables are first in your PATH, and be done with it.) I am betting many people will do src/pg_migrator to run it. However, there will be no pg_migrator binary in the old cluster (hopefully) so it would still find it even it the new cluster is not first in the path. Here is the new text I am using: The simplest build option is to use PGXS: gmake USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config install Another option is to point to the top of the new PostgreSQL source tree by running something like: gmake top_builddir=/usr/src/pgsql install Replace '/usr/src/pgsql' with your new source directory. pg_migrator also understands the 'prefix=' specification if you installed Postgres in a custom location. I am happy to remove the USE_PGXS from the Makefile, but it seems all the other extensions require that so I want to be consistent. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] pg_migrator mention in documentation
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: (Although actually, if that pg_config isn't in your path, the installed pg_migrator won't be either. It might be better to just say fix things so that the new installation's executables are first in your PATH, and be done with it.) I am betting many people will do src/pg_migrator to run it. However, there will be no pg_migrator binary in the old cluster (hopefully) so it would still find it even it the new cluster is not first in the path. That's not a very future-proof assumption... regards, tom lane -- 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] single bit integer (TINYINT) revisited for 8.5
On Thursday 02 July 2009 12:40:49 Simon Riggs wrote: On Wed, 2009-07-01 at 11:19 -0400, Caleb Cushing wrote: A couple of times I've been told you don't need tinyint, use boolean which is not true, several projects I've worked on I've needed and integer field that supports number within a small range 0-5 1-10 1-100 or something similar. I end up using smallint but it's range is huge for the actual requirements. Completely agree. Blech. More often than not, I find people using all these granular types to be nothing more than premature optimization. And if you really do need a single byte type, you can use char (though again I'm not a big fan of that) I'm most or the way through working on this as an add-on module, rather than a new datatype in core. I don't see much reason to include it in core: its not an SQL standard datatype, it complicates catalog entries and most people don't need or want it. That's too bad. I'd much rather see someone implement something closer to Oracle's number type. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- 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] Upgrading our minimum required flex version for 8.5
Tom Lane píše v čt 02. 07. 2009 v 13:13 -0400: Actually, most of the buildfarm members show which flex version they are running in the configure output. A quick look shows that of the 45 members that have reported on HEAD in the past 2 days, 22 are running 2.5.4, which is a lot higher than I was expecting. Most of these are the Solaris boxen, which I imagine can be updated fairly painlessly since there are some of them that are already running something newer. My three S10 are updated. All of them use version 2.5.35 now. S8, S9 is not yet under my control and they are not migrated yet to new location. Zdenek -- 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] [pgsql-www] commitfest.postgresql.org
On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, 2009-07-03 at 14:06 -0400, Robert Treat wrote: On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. O.k. I am probably blowing something out of the water here but do we need yet another domain? wiki.postgresql.org/commitfest/2009/07 (or www) Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] pg_migrator mention in documentation
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: (Although actually, if that pg_config isn't in your path, the installed pg_migrator won't be either. It might be better to just say fix things so that the new installation's executables are first in your PATH, and be done with it.) I am betting many people will do src/pg_migrator to run it. However, there will be no pg_migrator binary in the old cluster (hopefully) so it would still find it even it the new cluster is not first in the path. That's not a very future-proof assumption... Yep, but pg_migrator will exit quickly if an older version is run. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] PGXS problem with pdftotext
I cleaned up the poppler build situation, and all looks good except: Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: PG_CPPFLAGS =-I/usr/include/poppler -shared -fpic It doesn't seem appropriate to put -shared or -fpic into PG_CPPFLAGS. If you need those, the makefiles should add them automatically. Leaving off -shared was OK, but when I left off -fpic, I got this: /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: poppler_compat.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC poppler_compat.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libpdftotext.so.0.0] Error 1 With -fPIC or -fpic in my Makefile, PGXS now seems to work as intended. Is it worth doing anything to check on why that is needed or how to get rid of it? Might it have something to do with compiling both .c and .cc files? -Kevin -- 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] pg_migrator mention in documentation
Bruce Momjian wrote: I am happy to remove the USE_PGXS from the Makefile, but it seems all the other extensions require that so I want to be consistent. Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. As I pointed out earlier, this nonsense has crept out to external modules without better reason than being copied from contrib. The only problem I see with PGXS is that it cannot be used in certain situations where you want to have custom rules, but this is seldom the case. It would be better to get requests for PGXS enhancements so that it'd support those other cases too. Having PGXS is very useful to allow external modules to be built easily. Being forced to support the in tree method *plus* PGXS is pointless. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 11:50 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. The latter outcome would be disappointing to me, but that's where we're going to end up if we can't actually boil this down to a specific list of changes to be made. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. First of all, one of your arguments is that I might want to change them later. I can promise you that I won't want to do any such thing, or at the VERY least that the old URLs will always be supported. There would be a sort of perverse irony to me changing the application to use a different kind of key for the reason that Tom Lane is afraid that some day I might want to use a different kind of key. Secondly, if we are going to make a change, it would be nice to know what the use case is for the change and to have a set of requirements that are not mutually contradictory. It is not possible to both assign the URLs to the pages based on the names of the objects to which the refer (which are changeable) and to guarantee that the URLs will never change. So you can either have URL stability or you can have wiki-style names, but you can't have both, unless perhaps you include both the ID and the name in the link but make the name just decoration. I am frankly at a loss to why this is a big deal: if you bookmark the page, your browser will record the page title; if you use firefox, you can also find by page title in the address bar. And we've never had pages for individual patches before anyway, so why should it now be critical how those links are formatted? But if it is critical then please describe exactly how you think it should work. ...Robert -- 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] PGXS problem with pdftotext
Kevin Grittner kevin.gritt...@wicourts.gov writes: Leaving off -shared was OK, but when I left off -fpic, I got this: /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: poppler_compat.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC poppler_compat.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libpdftotext.so.0.0] Error 1 Huh. On Linux platforms, the PG makefiles should include -fpic in CFLAGS (via CFLAGS_SL) automatically; you should not need to repeat it in CPPFLAGS. For instance, if I go into contrib/adminpack and make, I see sed 's,MODULE_PATHNAME,$libdir/adminpack,g' adminpack.sql.in adminpack.sql gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I../../src/interfaces/libpq -I. -I../../src/include -D_GNU_SOURCE -c -o adminpack.o adminpack.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -shared adminpack.o -L../../src/port -Wl,-rpath,'/home/tgl/testversion/lib' -o adminpack.so What do you get? What does pg_config report for the various FLAGS variables? regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 2:10 PM, Joshua D. Drakej...@commandprompt.com wrote: O.k. I am probably blowing something out of the water here but do we need yet another domain? Because it's installed on a different VM and I don't want to move it just to make the URL look different? ...Robert -- 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] 8.5 development schedule
On Fri, Jul 3, 2009 at 1:16 PM, Tom Lanet...@sss.pgh.pa.us wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Robert Haas wrote: What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? This is where we left off: http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com There were adjacent remarks suggesting that large other parts of the patch remained to be reviewed, as well. http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php Thanks to both of you, this is very helpful. Two other questions: 1. Are there any chunks of this functionality in this patch that seem like they might be able to be severed and committed separately? 2. Was the latest version of this patch posted to the mailing list, and if so can you provide a link? Thanks, ...Robert -- 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] PGXS problem with pdftotext
Tom Lane t...@sss.pgh.pa.us wrote: What do you get? sed 's,MODULE_PATHNAME,$libdir/adminpack,g' adminpack.sql.in adminpack.sql gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I/usr/local/pgsql-8.3.7/include -I. -I/usr/local/pgsql-8.3.7/include/server -I/usr/local/pgsql-8.3.7/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -c -o adminpack.o adminpack.c ar crs libadminpack.a adminpack.o ranlib libadminpack.a gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -shared -Wl,-soname,libadminpack.so.0 adminpack.o -L/usr/local/pgsql-8.3.7/lib -Wl,-rpath,'/usr/local/pgsql-8.3.7/lib' -o libadminpack.so.0.0 What does pg_config report for the various FLAGS variables? CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2 CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,'/usr/local/pgsql-8.3.7/lib' LDFLAGS_SL = -Kevin -- 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] Have \d show child tables that inherit from the specified parent
On Sunday 10 May 2009 03:05:48 dam...@dalibo.info wrote: Here's a second version. Main changes are : * Child tables are sorted by name * \d only shows the number of child tables * \d+ shows the full list Committed. -- 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] [pgsql-www] commitfest.postgresql.org
Robert Treat wrote: On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. I believe Tom wants details removed from the URL, so future implementation changes don't either a) break bookmarks because more stuff is needed in the URL or b) don't break bookmarks but be limited to existing sutff in the URL (ie. hacky work arounds). If that's the case, your best best is to use some kind of key, like 16 random bytes displayed in hex, that looks up the data. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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] PGXS problem with pdftotext
Tom Lane t...@sss.pgh.pa.us wrote: What do you get? More to the point, here's what I get when I use PGXS with my pdf code. sed 's,MODULE_PATHNAME,$libdir/pdftotext,g' pdftotext.sql.in pdftotext.sql gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I/usr/local/include/poppler -I. -I/usr/local/pgsql-8.3.7/include/server -I/usr/local/pgsql-8.3.7/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -c -o pdftotext.o pdftotext.c g++ -I/usr/local/include/poppler -I. -I/usr/local/pgsql-8.3.7/include/server -I/usr/local/pgsql-8.3.7/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -c -o poppler_compat.o poppler_compat.cc ar crs libpdftotext.a pdftotext.o poppler_compat.o ranlib libpdftotext.a gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -shared -Wl,-soname,libpdftotext.so.0 pdftotext.o poppler_compat.o -L/usr/local/pgsql-8.3.7/lib -lpoppler -Wl,-rpath,'/usr/local/pgsql-8.3.7/lib' -o libpdftotext.so.0.0 /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: poppler_compat.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC poppler_compat.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libpdftotext.so.0.0] Error 1 Since the gcc line has it, it must be the g++ line that's the problem? -Kevin -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:00 PM, Andrew Chernowa...@esilo.com wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. I believe Tom wants details removed from the URL, so future implementation changes don't either a) break bookmarks because more stuff is needed in the URL or b) don't break bookmarks but be limited to existing sutff in the URL (ie. hacky work arounds). If that's the case, your best best is to use some kind of key, like 16 random bytes displayed in hex, that looks up the data. I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. ...Robet -- 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] [pgsql-www] commitfest.postgresql.org
Hi, Le 3 juil. 09 à 20:44, Robert Haas a écrit : - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. May I suggest something looking about like: http://commitfest.postgresql.org/current http://commitfest.postgresql.org/open http://commitfest.postgresql.org/in-progress http://commitfest.postgresql.org/previous With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Your software seems to be better than a wiki, but its potential users are expressing needs and bikescheding. I think you'd better accept both kind of changes as long as it's not making your life much harder than you'd want. Frankly, what URL looks better: http://commitfest.postgresql.org/action/commitfest_view?id=2 http://commitfest.postgresql.org/2009/07 Oh, and while at it, I don't foresee that we would want the commitfest of july 2009 to change its name but not the semantic URL pointing to its management. Or if it's ever wanted, as has been said, have a look at Apache Rewrite Rules system, it's made for supporting content being moved. Something in the spirit of: RedirectPermanent /2009/07 /2009/08 While at it, I imagine that within a given commit fest, a single patch will have a stable shortname, or if it comes to change, we could accept that the URL too change: http://commitfest.postgresql.org/action/patch_view?id=71 http://commitfest.postgresql.org/2009/07/Synch_Rep http://commitfest.postgresql.org/current/Synch_Rep Now, rather than following the names with apache setup, maybe you could add something like some history tables tracking short name changes (maybe some ON UPDATE trigger would do), so that referring to an older name would send a HTTP 302 redirect to the new name URL? I'd like your work to be useful for all of us and appreciated to its real value, and those changes well seem like user interface improvements rather than basic structure or behavior questioning. Regards, -- dim -- 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] PGXS problem with pdftotext
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: What does pg_config report for the various FLAGS variables? CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2 CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g CFLAGS_SL = -fpic LDFLAGS = -Wl,-rpath,'/usr/local/pgsql-8.3.7/lib' LDFLAGS_SL = Well, that looks about right, so the next question is why the CFLAGS value isn't getting used in your build. What's the whole output of make when you try to build your module? regards, tom lane -- 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] PGXS problem with pdftotext
Kevin Grittner kevin.gritt...@wicourts.gov writes: Since the gcc line has it, it must be the g++ line that's the problem? Hmm, try adding CXXFLAGS = $(CFLAGS) Although in general we don't try very hard to support C++ code inside the backend. regards, tom lane -- 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] SQL state in log_line_prefix
On Sunday 10 May 2009 15:32:26 Guillaume Smet wrote: I attached a patch which allows to add the SQL state code into the log_line_prefix. I used %e (as in error) as %s is already used. Committed. -- 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] [pgsql-www] commitfest.postgresql.org
I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) Wasn't aware of exately what you were doing. It sounded like multiple things were in the query_string. If its already a single key, than there is no need to use a different key. And no, I don't like remebering URLs ... thus all the fuss about breaking bookmarks ;-) It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. Using a URL to encode when something occurred was being offered as a solution to know what commitfest it is. I'm not sure where your confusion is? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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] First CommitFest: July 15th
Peter Eisentraut píše v pá 03. 07. 2009 v 09:19 +0300: On Friday 03 July 2009 05:16:41 Robert Haas wrote: On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote: Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700: Folks, There's been a lot of discussion/argument around how to handle the last commitfest, but there seems to be a total consensus that we want to have the first CF on July 15th. Can we add flags like bump catalog version, bump page layout version, modify AM for each patch? It should help to track pg_upgrade changes. That's not a bad idea, and it wouldn't be hard to add various flags and things to the CommitFest app I wrote, but how would we maintain the information and keep it correct? It seems like there might be a danger that patch authors wouldn't know whether or not they were doing those things. Also, how would we handle changes by committers, who don't always go through the CommitFest process? I think this information could be computed automatically, if someone cared enough. It shouldn't be necessary to bother every single participant in the process with this. I think that developer is responsible for his patch. He should know what he doing. When he will send a patch and see checkbox like modified AM? then he should know what he modified? It is also warning for commiter that catalog version has to be bumped during a commit. I don't see any method how to check automatically. Something could be possible - like structure checker. But when meaning of data is going to be different. Zdenek -- 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] pg_migrator mention in documentation
Alvaro Herrera alvhe...@commandprompt.com writes: Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. The main reason contrib still has the alternate method is that PGXS doesn't really work until after you've installed the core build. For modules distributed separately from core, it doesn't seem that exciting to be able to build using the contrib method. Now, having said that, I'm personally interested in being able to build pg_migrator against an uninstalled source tree, because I foresee needing to do that for RPM packaging purposes. But I could easily patch the makefiles if needed to make that happen. I don't think this case should drive the choice of what's the default or common method. regards, tom lane -- 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] PGXS problem with pdftotext
Tom Lane t...@sss.pgh.pa.us wrote: Hmm, try adding CXXFLAGS = $(CFLAGS) Thanks, that worked; I don't need to specify -fpic in my file if I put the above line in. Although in general we don't try very hard to support C++ code inside the backend. I try to avoid it when possible. The C++ code is the thinnest wrapper we could arrange around the poppler code to allow access from the C code. Would it make sense to add the above to the PGXS file somewhere, for those cases (like this) when someone has to access some existing C++ code base? -Kevin -- 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] First CommitFest: July 15th
Robert Haas píše v čt 02. 07. 2009 v 22:16 -0400: On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote: Also, how would we handle changes by committers, who don't always go through the CommitFest process? I think that all head patches should go to through a new tool for recording also in case when developer is commiter itself. Zdenek -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:08 PM, Dimitri Fontainedfonta...@hi-media.com wrote: Your software seems to be better than a wiki, but its potential users are expressing needs and bikescheding. I think you'd better accept both kind of changes as long as it's not making your life much harder than you'd want. Frankly, what URL looks better: http://commitfest.postgresql.org/action/commitfest_view?id=2 http://commitfest.postgresql.org/2009/07 We've definitely gotten to the harder than I'd want point at this point. Oh, and while at it, I don't foresee that we would want the commitfest of july 2009 to change its name but not the semantic URL pointing to its management. Or if it's ever wanted, as has been said, have a look at Apache Rewrite Rules system, it's made for supporting content being moved. Something in the spirit of: RedirectPermanent /2009/07 /2009/08 I humbly submit that it's insane to thing about editing httpd.conf every time somebody renames an object. The point here is to *reduce* the administrative burden of maintaining this thing. While at it, I imagine that within a given commit fest, a single patch will have a stable shortname, or if it comes to change, we could accept that the URL too change: http://commitfest.postgresql.org/action/patch_view?id=71 http://commitfest.postgresql.org/2009/07/Synch_Rep http://commitfest.postgresql.org/current/Synch_Rep Now, rather than following the names with apache setup, maybe you could add something like some history tables tracking short name changes (maybe some ON UPDATE trigger would do), so that referring to an older name would send a HTTP 302 redirect to the new name URL? So, the good thing about the current system is that the URL *doesn't* change and you *don't* need complicated bookkeeping to remember every URL you've ever assigned to the thing to get it. I am well aware that it's possible to design a system that does this, but what benefit do we get out of it? Making it possible to tell what a URL points to without clicking on it, for those occasions when you're stranded on a desert island with a URL and no Internet access? There's a subtle and pernicious danger of the system you're proposing, too. If we regularly change the URLs that refer to certain objects, but compensate for that by remembering the whole history of URLs that have ever referred to that object, then there will multiple URLs that refer to the same object, of which all but one will contain WRONG information about what that link points to. The http://commitfest.postgresql.org/2009/07/Sync_Rep link, for example, might imply to someone that the patch is in the 2009-07 commitfest, but in fact it may well have been moved to the 2009-11, 2010-01, or 2010-03 commitfest, or we might have finally come to our senses and realized that it ought to be called streaming rep and rename it. It's true that the current URLs, without some sort of accompanying text, do not tell you what they point to. But no information can often be better than disinformation. I'd like your work to be useful for all of us and appreciated to its real value, and those changes well seem like user interface improvements rather than basic structure or behavior questioning. I'd like that, too. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:15 PM, Andrew Chernowa...@esilo.com wrote: I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) Wasn't aware of exately what you were doing. It sounded like multiple things were in the query_string. If its already a single key, than there is no need to use a different key. And no, I don't like remebering URLs ... thus all the fuss about breaking bookmarks ;-) Right. The current system has exactly ZERO chance of breaking any bookmarks, and all of the proposed alternatives are much more likely to do so. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. Using a URL to encode when something occurred was being offered as a solution to know what commitfest it is. I'm not sure where your confusion is? The suggestion was to encode the start date of the CommitFest in the URL, instead of using a non-natural key. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. I think it's probably fixable, if you've got some time to put into it between now and the 15th. What's being griped about is user interface details, and it's not surprising that you as the author didn't see these things the same way a new user would. From what I've been able to see, the underlying functionality is mostly there, but it needs some usability/presentation tweaking. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Given your item 3 above, I think we can live with the URLs otherwise. One other thing I was noticing is that the items for a particular patch seem to be listed in reverse date order. Personally I find this strange and would prefer newest-at-the-bottom --- in particular, having the patch itself at the bottom doesn't seem especially usable. We might need to take a vote on that though, since I suppose some people like newest-at-the-top. regards, tom lane -- 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] pg_migrator mention in documentation
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. The main reason contrib still has the alternate method is that PGXS doesn't really work until after you've installed the core build. For modules distributed separately from core, it doesn't seem that exciting to be able to build using the contrib method. Now, having said that, I'm personally interested in being able to build pg_migrator against an uninstalled source tree, because I foresee needing to do that for RPM packaging purposes. But I could easily patch the makefiles if needed to make that happen. I don't think this case should drive the choice of what's the default or common method. Well, PGXS is now the recommended install method in the pg_migrator INSTALL file. What other changes should I make? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:27 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. I think it's probably fixable, if you've got some time to put into it between now and the 15th. What's being griped about is user interface details, and it's not surprising that you as the author didn't see these things the same way a new user would. From what I've been able to see, the underlying functionality is mostly there, but it needs some usability/presentation tweaking. Thanks, that is really good news. I agree that the presentation and usability need some work and I'm trying to address those concerns as expediently as I can. Part of my angst is that I am going to have only sporadic Internet access for the next week, so what I can't get done today (while my wife wonders why I am doing a second job on a holiday for no money) probably isn't going to happen for a bit, and I would like to get cut over so that Brendan doesn't have to keep manually replicating changes between the systems. I will see if I can make the changes below happen today. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Given your item 3 above, I think we can live with the URLs otherwise. /me feels like he has dodged a bullet. One other thing I was noticing is that the items for a particular patch seem to be listed in reverse date order. Personally I find this strange and would prefer newest-at-the-bottom --- in particular, having the patch itself at the bottom doesn't seem especially usable. We might need to take a vote on that though, since I suppose some people like newest-at-the-top. I think it IS newest at the bottom, and I agree that that is how it should be. 24 hours ago it was alpha by topic and then alpha by patch name, but now it is topic by sortorder, then topic by name, then patch by ascending ID number (which works out to newest at the bottom). I thought the other way would be OK, but after Brendan and I imported the data we both said that sucks, so it got changed last night around midnight Eastern +/- an hour. One of the things that I would like to add in the future is the ability to assign a patch a shortname. This would be useful for building command-line tools to interface with the system, e.g. download the sepgsql patch. The idea would be that these names would be stable, though of course it's hard to see how to guarantee that 100%. I am still trying to work out in my mind how best to set that up, though, so it's probably not going to happen right away unless someone else is prepared to do some of the legwork. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) -Kevin -- 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] [pgsql-www] commitfest.postgresql.org
Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
Tom Lane t...@sss.pgh.pa.us wrote: Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Just for purposes of conversion, or as a long-term behavior? -Kevin -- 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] First CommitFest: July 15th
Dickson S. Guedes lis...@guedesoft.net wrote: pgcommitfest tables sctructure [1]? [1] http://git.postgresql.org/gitweb?p=pgcommitfest.git;a=blob;f=etc/table.sql;h=c60a298c863ef3e88dcfd16572781d2b435ca629;hb=HEAD On minor quibble with this schema: I believe that session.login_time should be TIMESTAMP WITH TIME ZONE. -Kevin -- 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] [pgsql-www] commitfest.postgresql.org
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Just for purposes of conversion, or as a long-term behavior? Well, right at the moment I was just thinking of the conversion problem, but it wouldn't be a horrible idea to make it a permanent behavior for entries that include a message reference. regards, tom lane -- 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] commitfest.postgresql.org
Peter Eisentraut pete...@gmx.net writes: And please make Delete Patch into a button instead of a link. Only if there's some kind of confirmation ... regards, tom lane -- 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] commitfest.postgresql.org
On Friday 03 July 2009 07:57:35 Robert Haas wrote: We're still hacking on a few other details of the formatting and interface, but you might want to cruise over and have a look. One thing that I noticed it that it takes too many clicks in general to make a set of changes. When I look at a patch, why not have the controls to add a comment and make changes right there, instead of on another page? For instance, the functionality of action/patch_view?id=69 action/patch_comment_form?patch=69 action/patch_form?id=69 action/patch_bump?id=69 could all be on the same page. And please make Delete Patch into a button instead of a link. -- 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] commitfest.postgresql.org
On Fri, 2009-07-03 at 16:54 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: And please make Delete Patch into a button instead of a link. Only if there's some kind of confirmation ... Should we actually delete patches? I get removing them from the list but it seems there could be benefit from keeping patches that are not quite there or perhaps present an idea that is ahead of its time (or half baked but interesting in genera?). +1 on the confirmation regardless. Joshua D. Drake regards, tom lane -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] First CommitFest: July 15th
On Fri, Jul 3, 2009 at 3:22 PM, Zdenek Kotalazdenek.kot...@sun.com wrote: Robert Haas píše v čt 02. 07. 2009 v 22:16 -0400: On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotalazdenek.kot...@sun.com wrote: Also, how would we handle changes by committers, who don't always go through the CommitFest process? I think that all head patches should go to through a new tool for recording also in case when developer is commiter itself. You'll have to put that argument to the committers; but I expect a cool reception. I think what would be more useful is if we could somehow associated metadata with each commit. Right now, for example, the author of a patch is not stored with the patch in any structured way; it's just typed in, usually but not always as the last line of the commit. So you can't easily find out what lines of code a certain person has touched, for example. The sorts of problems that you're talking about seem broadly in the same vein. ...Robert -- 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] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 5:49 PM, Joshua D. Drakej...@commandprompt.com wrote: On Fri, 2009-07-03 at 16:54 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: And please make Delete Patch into a button instead of a link. Only if there's some kind of confirmation ... Should we actually delete patches? I get removing them from the list but it seems there could be benefit from keeping patches that are not quite there or perhaps present an idea that is ahead of its time (or half baked but interesting in genera?). +1 on the confirmation regardless. There is a confirmation right now, plus it doesn't work at all unless you delete all the comments first, which you can't do either unless you are an administrator or the only person who has ever commented on the patch. Really, deleting patches should be quite rare and only needed in cases where the patch should not have been added in the first place. I guess I'm not really seeing why that particular thing should be a button rather than a link. It would mess up the formatting for no obvious benefit. ...Robert -- 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] commitfest.postgresql.org
On Fri, 2009-07-03 at 17:57 -0400, Robert Haas wrote: I guess I'm not really seeing why that particular thing should be a button rather than a link. It would mess up the formatting for no obvious benefit. Not arguing one way or the other, a button says, I am about to perform X. A link *always* says, I am about to go to a new web page. Joshua D. Drake ...Robert -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 6:19 PM, Joshua D. Drakej...@commandprompt.com wrote: On Fri, 2009-07-03 at 17:57 -0400, Robert Haas wrote: I guess I'm not really seeing why that particular thing should be a button rather than a link. It would mess up the formatting for no obvious benefit. Not arguing one way or the other, a button says, I am about to perform X. A link *always* says, I am about to go to a new web page. Hmm, there is some truth to what you say. I guess the way I think about it, a button says I am about to submit this form and a link says I am about to do something other than submit a form. But it's certainly an arguable point. ...Robert -- 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] SQL state in log_line_prefix
On Fri, Jul 3, 2009 at 9:14 PM, Peter Eisentrautpete...@gmx.net wrote: On Sunday 10 May 2009 15:32:26 Guillaume Smet wrote: I attached a patch which allows to add the SQL state code into the log_line_prefix. I used %e (as in error) as %s is already used. Committed. Thanks Peter. -- Guillaume -- 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] pg_migrator mention in documentation
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Consistency here is pointless. IIRC the dual method is used in contrib because people did not trust the PGXS stuff enough to rip the original Make code out; or maybe because people did not want PGXS to become the default build method, but they allowed it to be used in contrib as a test bed that PGXS worked. The main reason contrib still has the alternate method is that PGXS doesn't really work until after you've installed the core build. For modules distributed separately from core, it doesn't seem that exciting to be able to build using the contrib method. Now, having said that, I'm personally interested in being able to build pg_migrator against an uninstalled source tree, because I foresee needing to do that for RPM packaging purposes. But I could easily patch the makefiles if needed to make that happen. I don't think this case should drive the choice of what's the default or common method. Well, PGXS is now the recommended install method in the pg_migrator INSTALL file. What other changes should I make? Since PGXS does not work under Windows, I think the only way to build non-contrib extensions on Windows is the contrib way (i.e. place in contrib folder and use contrib style Makefile). Joe -- 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] First CommitFest: July 15th
Josh Berkus wrote: Folks,...the first CF on July 15th. Would it make the CommitFest easier if there were an additional column which indicates what CVS-version of Postgres the patch cleanly applies to? Perhaps a patch submitter could indicate the CVS date/time with which he developed the patch. If a reviewer happens to apply the patch on a later version he could update it as cleanly applying at that later date. Commiters could feel free to ignore patches that are sufficiently far off of HEAD, so it might make work easier for them too. -- 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] First CommitFest: July 15th
Ron Mayer wrote: Josh Berkus wrote: Folks,...the first CF on July 15th. Would it make the CommitFest easier if there were an additional column which indicates what CVS-version of Postgres the patch cleanly applies to? Perhaps a patch submitter could indicate the CVS date/time with which he developed the patch. If a reviewer happens to apply the patch on a later version he could update it as cleanly applying at that later date. Commiters could feel free to ignore patches that are sufficiently far off of HEAD, so it might make work easier for them too. I think the patch should apply cleanly to HEAD at the time it is submitted. The actual CVS versions should be visible in the patch. Normally we will try to take care of any subsequent bitrot - I don't think developers should have to pay too high a price for our processes. Occasionally a developer will be asked to help in removing the bitrot, but that is usually the first thing I try to do in a review, after applying the simple eyeballs test. In theory this is an area where a more sophisticated SCM system will help us some. (Actually, you often learn a lot that way - it's a good exercise for all of us.) cheers andrew -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:40 PM, Robert Haasrobertmh...@gmail.com wrote: I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. Done. Done. Done. You guys are harder to please than my boss. He doesn't quite know for sure which things are possible. :-) ...Robert -- 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] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 4:43 PM, Peter Eisentrautpete...@gmx.net wrote: On Friday 03 July 2009 07:57:35 Robert Haas wrote: We're still hacking on a few other details of the formatting and interface, but you might want to cruise over and have a look. One thing that I noticed it that it takes too many clicks in general to make a set of changes. When I look at a patch, why not have the controls to add a comment and make changes right there, instead of on another page? For instance, the functionality of action/patch_view?id=69 action/patch_comment_form?patch=69 action/patch_form?id=69 action/patch_bump?id=69 could all be on the same page. Well, I've added the comment form to that page, by request, but I don't see how you could fit the rest on there in any sort of sane way. But I'm accepting patches... ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. If you see a counterexample, please point it out. If you want to fix the order of the topics, click on the CommitFest Topics link in the upper lefthand corner of the page and frobnicate the sort order. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Brendan, is this something that you can work on? Or does anyone else have some time to put into it? And do we have to fix this before we can declare the new system live, or can we catch up after the fact? Because replicating changes from the old system to the new is a bit of a pain in the neck. ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
2009/7/4 Robert Haas robertmh...@gmail.com: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Brendan, is this something that you can work on? I will take a stab at it. I think Tom's suggestion of harvesting the time of the mail message from the archives could do the job. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Round-Robin Reviewers Needed
All, We are very much in need of round-robin reviewers for the next CommitFest. If you're wondering whether you are qualified to be a round-robin reviewer, the answer is almost certainly yes. In fact, there's a good chance that the answer is yes even if you are pretty sure you aren't qualified. Basically, you just need to be able to download the patch, apply it, and test it, starting with the regression tests (make check) and moving on from there. If you can read the code, that is better, but not required. There is a good introduction to the subject here: http://wiki.postgresql.org/wiki/Reviewing_a_Patch http://wiki.postgresql.org/wiki/RRReviewers My favorite introduction to the subject, though, is this: http://wiki.postgresql.org/images/5/58/11_eggyknap-patch-review.pdf (just don't stop reading before you get to slide 26) If you are are available to review one or more patches for the CommtFest beginning 7/15, please send me an email (no need to copy the list) and let me know. It would be helpful if you could let me know whether you're comfortable testing on Windows, whether you have access to substantial hardware for performance testing, and any other information that might be helpful to me in assigning you a patch that's a good fit for your skillset. (I will be out of town this week so there may be a delay in responding to emails, but I should have sporadic access and will in any event be back in time to get things organized by the fifteenth.) Thanks in advance to all who volunteer! ...Robert -- 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] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. No, what we're complaining about is the ordering of comments for a single patch. If you look at http://commitfest.postgresql.org/action/commitfest_view?id=2 in some cases there are Comments before the Patch itself, and in some cases after, but more often than not the original Patch is at the bottom. regards, tom lane -- 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] [pgsql-www] commitfest.postgresql.org
2009/7/4 Tom Lane t...@sss.pgh.pa.us: No, what we're complaining about is the ordering of comments for a single patch. Now moot, since I've successfully pulled the dates for all comments with a message-id from the archives, and updated the database accordingly. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
