Re: [HACKERS] XML index support
Thank you all for these kind answers. Cheers, JMP -- 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] stat() vs cygwin
Dave Page schrieb:
On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
Yes.
As in the cygwin build does build. Nobody really has verified if the fix
is needed there. But frankly, if you are likely to care about the
effects of this issue, you won't be running cygwin anyway. It's mostly a
dead platform for postgresql anyway, AFAICS we only keep it building for
legacy compatibility. Once it starts taking lots of resources to keep
building (which it doesn't now), I think we should just drop it instead...
Dead is interesting. We see a lot of cygwin users having postgresql
installed.
FWIW, the most recent packages from Cygwin themselves are 8.2.5.
Update: 8.2.9 is latest.
8.3.x not because the new SSPI doesn't work yet.
currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java
--with-ossp-uuid --with-ldap
(but ldap works okay with 8.2.9)
currently testing is: --enable-nls --with-CXX --with-openssl --with-perl
--with-python --with-libxml --with-libxslt
current cygwin patch in testing is attached.
--
Reini Urban
postgresql cygwin maintainer
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x 'postgresql-8.2.0-1.cygport~' -x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x 'postgresql-8.2.9-1.cygport~' -x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x 'postgresql7.4-7.4.13-1.cygport~' -x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/auth.c src/postgresql-8.3.3/src/backend/libpq/auth.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/auth.c 2008-02-08 17:58:46.0 +
+++ src/postgresql-8.3.3/src/backend/libpq/auth.c 2008-06-28 08:27:03.53125 +
@@ -32,6 +32,9 @@
#include libpq/pqformat.h
#include storage/ipc.h
+#ifdef __CYGWIN__
+#define WIN32
+#endif
static void sendAuthRequest(Port *port, AuthRequest areq);
static void auth_failed(Port *port, int status);
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x 'README~' -x 'pathmax.c~' -x 'postgresql-8.2.0-1.cygport~' -x 'postgresql-8.2.3-1.cygport~' -x 'postgresql-8.2.6-1.cygport~' -x 'postgresql-8.2.9-1.cygport~' -x 'postgresql-8.3.0-1.cygport~' -x 'postgresql-8.3.3-1.cygport~' -x 'postgresql7.4-7.4.13-1.cygport~' -x 'postgresql7.4-java.hint~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in -x TAGS -x Makefile.shlib -x libpq.rc origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c src/postgresql-8.3.3/src/backend/libpq/be-secure.c
--- origsrc/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-01-01 19:45:49.0 +
+++ src/postgresql-8.3.3/src/backend/libpq/be-secure.c 2008-06-28 08:27:03.546875000 +
@@ -280,9 +280,26 @@
case SSL_ERROR_WANT_WRITE:
#ifdef WIN32
pgwin32_waitforsinglesocket(SSL_get_fd(port-ssl),
- (err == SSL_ERROR_WANT_READ) ?
- FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
- INFINITE);
+ (err == SSL_ERROR_WANT_READ) ?
+ FD_READ | FD_CLOSE : FD_WRITE | FD_CLOSE,
+ INFINITE);
+#elif defined(__CYGWIN__)
+/* be nicer on cygwin also */
+{
+fd_set rset;
+int sel_res;
+struct timeval tv;
+FD_ZERO(rset);
+FD_SET(SSL_get_fd(port-ssl), rset);
+tv.tv_sec = 0;
+tv.tv_usec = 50;
+sel_res = select(FD_SETSIZE,
+ (err ==
[HACKERS] interval madness ...
hello everybody ... i am sitting here in a training and i am wondering about the following issue ... test=# select now() + '3 years 2 decades 4000 seconds 9 minutes'::interval; ?column? --- 2031-06-28 11:58:35.052423+02 (1 row) test=# select now() + '3 years 2 decades 4000 seconds 9 minutes 1 century'::interval; ?column? --- 2131-06-28 11:59:01.635835+01 (1 row) why do i get a different timezone just because of adding one more century? i cannot see an obvious reason. many thanks, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com
Re: [HACKERS] interval madness ...
Hans-Juergen Schoenig [EMAIL PROTECTED] writes: why do i get a different timezone just because of adding one more century? i cannot see an obvious reason. What version of Postgres and what setting of TZ? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] interval madness ...
Hans-Juergen Schoenig [EMAIL PROTECTED] writes: why do i get a different timezone just because of adding one more century? i cannot see an obvious reason. This thread may be enlightening: http://archives.postgresql.org/pgsql-patches/2007-09/msg00292.php I can't find the message for the later commits but they weren't backpatched to 8.3 so unless you're using HEAD you won't get properly working timezones for post-2038 -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- 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] interval madness ...
On Jun 28, 2008, at 11:39 AM, Gregory Stark wrote: Hans-Juergen Schoenig [EMAIL PROTECTED] writes: why do i get a different timezone just because of adding one more century? i cannot see an obvious reason. What version of Postgres and what setting of TZ? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers i am on OS X. test=# select now(); now -- 2008-06-28 11:42:58.59121+02 (1 row) test=# select version(); version - PostgreSQL 8.3.0 on i386-apple-darwin8.11.1, compiled by GCC i686- apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370) (1 row) many thanks, hans -- Cybertec Schönig Schönig GmbH PostgreSQL Solutions and Support Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql-support.de, www.postgresql-support.com
Re: [HACKERS] Posting to hackers and patches lists
On 5/7/08, Tom Lane [EMAIL PROTECTED] wrote: Matthew T. O'connor [EMAIL PROTECTED] writes: By the way, what is the actual size limit on hackers vs patches. They do have different size limits; we'd have to raise the limit on -hackers if we do this. Marc would know exactly what the limits are. Seems it's below 30k as my 34k (gz) patch was dropped yesterday. -- marko -- 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] Posting to hackers and patches lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Try now, just raised it to the same as -patches (100k) ... - --On Saturday, June 28, 2008 12:59:18 +0300 Marko Kreen [EMAIL PROTECTED] wrote: On 5/7/08, Tom Lane [EMAIL PROTECTED] wrote: Matthew T. O'connor [EMAIL PROTECTED] writes: By the way, what is the actual size limit on hackers vs patches. They do have different size limits; we'd have to raise the limit on -hackers if we do this. Marc would know exactly what the limits are. Seems it's below 30k as my 34k (gz) patch was dropped yesterday. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhmMjkACgkQ4QvfyHIvDvPuNgCgj0qvwSIkI3nuqa1tHpcaNzd5 n4gAoJXJFJUiTPN5qWQ/hUBiaCBXniCK =blIw -END PGP SIGNATURE- -- 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] stat() vs cygwin
Reini Urban wrote: Dave Page schrieb: On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote: Yes. As in the cygwin build does build. Nobody really has verified if the fix is needed there. But frankly, if you are likely to care about the effects of this issue, you won't be running cygwin anyway. It's mostly a dead platform for postgresql anyway, AFAICS we only keep it building for legacy compatibility. Once it starts taking lots of resources to keep building (which it doesn't now), I think we should just drop it instead... Dead is interesting. We see a lot of cygwin users having postgresql installed. Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. FWIW, the most recent packages from Cygwin themselves are 8.2.5. Update: 8.2.9 is latest. Good! 8.3.x not because the new SSPI doesn't work yet. currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java --with-ossp-uuid --with-ldap (but ldap works okay with 8.2.9) currently testing is: --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt current cygwin patch in testing is attached. I assume this is a WIP and not actually for application, right? Please look it over because it contains a number of pure-whitespace changes that make it harder to read, and that will just end up being undone by pgindent at a later date anyway. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. There's also a number of: -#ifndef·WIN32 +#if·!defined(WIN32)·||·defined(__CYGWIN__) If I read that right, it shouldn't be necessary as long as the WIN32 define is not set on CYGWIN? And finally: -VALUE·OriginalFilename,·libpq.dll\0 +VALUE·OriginalFilename,·cygpq.dll\0 This obviously has to be done another way, because that change will affect the win32 platform as well... //Magnus -- 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] ecpg generated files ignorable?
Alvaro Herrera wrote: Michael Meskes wrote: Well, in my source tree I have two, one for MS VC++ and one for Borland C++ Builder. And yes, I can build a third one for MS VC++ as well by just issuing the corresponding make call. However, I have no idea whether we need both, the only differ in the lib name: --- libecpgddll.def 2008-06-20 12:33:29.0 +0200 +++ libecpgdll.def 2008-06-20 12:33:16.0 +0200 @@ -1,5 +1,5 @@ ; DEF file for MS VC++ -LIBRARY LIBECPGD +LIBRARY LIBECPG EXPORTS ECPGallocate_desc@ 1 ECPGconnect @ 2 Maybe someone with more Windows knowledge can explain this? Magnus? (without looking at the actual code :-P): LIBRARY should match the name of the DLL file. LIBECPGD is the debugging version, which is the one linked against the debugging version of the runtime. It needs to exist in any case where CRT pointers (FILE*, va_args, things like that) is passed between DLLs. If one is linked against release and one against debug, a crash will occur, so to build you need to have a debug-linked version of the DLL as well. Wow. That turned into quite a messy explanation, I hope it's readable :) //magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [patch] plproxy v2
We have written a FAQ, where are common issues collected, there are also discussion about design decisions and why concentrating only to functions is good idea. http://plproxy.projects.postgresql.org/faq/faq.html The patch itself is attached, and also made available here: http://plproxy.projects.postgresql.org/plproxy-v2.diff.gz Changes since v1: - dynamic record patch from Lei Yonghua. That makes functions that require result types specified with AS clause work. - accepts int2/4/8 from hash function - removed get_cluster_config() - draft sgml documentation - disabled binary I/O by default. - parser.y: remove use of alloca, define malloc/free to palloc/pfree - scanner.l: fix crash if palloc() throws exception by reinitializing flex properly - make installcheck work - removed backwards compat code - use bool instead bitfields to conform to Postgres coding style. Todo: - the docs should be more fleshed out - should regtest moved to src/test/regress? - make GUC vars for binary i/o and connection_lifetime? I mentioned that I planned to remove SELECT/CONNECT too. Now I've thought about it more and it seems to me that its better to keep them. As they give additional flexibility. CONNECT - allows to test plproxy without creating plproxy schema. Good for quick hacks, RPC-s. Main problem is that as soon user starts to have several environments - dev/test/live - he will get hurt, but that could be solved by giving suggestions in docs how to avoid that. Eg. suggest using service= or fake hostnames. SELECT - main reason to keep it would be to allow calling different functions, having different argument/result names or types. -- marko plproxy-v2.diff.gz Description: GNU Zip compressed data -- 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] stat() vs cygwin
Magnus Hagander wrote: 8.3.x not because the new SSPI doesn't work yet. current cygwin patch in testing is attached. I assume this is a WIP and not actually for application, right? Please look it over because it contains a number of pure-whitespace changes that make it harder to read, and that will just end up being undone by pgindent at a later date anyway. The patch also seems to hint that pgwin32_waitforsinglesocket needs a specific Cygwin implementation too (rather than patching every caller). -- 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] interval madness ...
Gregory Stark [EMAIL PROTECTED] writes: Hans-Juergen Schoenig [EMAIL PROTECTED] writes: why do i get a different timezone just because of adding one more century? i cannot see an obvious reason. This thread may be enlightening: http://archives.postgresql.org/pgsql-patches/2007-09/msg00292.php I can't find the message for the later commits but they weren't backpatched to 8.3 so unless you're using HEAD you won't get properly working timezones for post-2038 Yeah, that patch did get in earlier this year: 2008-02-16 16:16 tgl * src/: test/regress/expected/timestamptz.out, test/regress/sql/timestamptz.sql, timezone/README, timezone/ialloc.c, timezone/localtime.c, timezone/pgtz.c, timezone/pgtz.h, timezone/private.h, timezone/scheck.c, timezone/strftime.c, timezone/tzfile.h, timezone/zic.c: Update timezone code to track the upstream changes since 2003. In particular this adds support for 64-bit tzdata files, which is needed to support DST calculations beyond 2038. Add a regression test case to give some minimal confidence that that really works. Heikki Linnakangas I believe the behavior now is that the code will assume the last known DST rule for a zone applies indefinitely far into the future. But in 8.3 and before all times past 2038 are taken as local standard time. 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] stat() vs cygwin
Magnus Hagander schrieb: Reini Urban wrote: Dave Page schrieb: On Tue, Jun 24, 2008 at 9:32 AM, Magnus Hagander [EMAIL PROTECTED] wrote: Yes. As in the cygwin build does build. Nobody really has verified if the fix is needed there. But frankly, if you are likely to care about the effects of this issue, you won't be running cygwin anyway. It's mostly a dead platform for postgresql anyway, AFAICS we only keep it building for legacy compatibility. Once it starts taking lots of resources to keep building (which it doesn't now), I think we should just drop it instead... Dead is interesting. We see a lot of cygwin users having postgresql installed. Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. FWIW, the most recent packages from Cygwin themselves are 8.2.5. Update: 8.2.9 is latest. Good! 8.3.x not because the new SSPI doesn't work yet. currently failing is: --with-gssapi --with-krb5 --with-tcl --with-java --with-ossp-uuid --with-ldap (but ldap works okay with 8.2.9) currently testing is: --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt current cygwin patch in testing is attached. I assume this is a WIP and not actually for application, right? Please look it over because it contains a number of pure-whitespace changes that make it harder to read, and that will just end up being undone by pgindent at a later date anyway. Sure. This is just the current status of my patch (still from 8.3beta2), nothing to actually submit. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. SSPI has some direct winapi calls to libsecure32 which are simpliest to declare by this cygwin == WIN32 declaration in the backend. For the client libpq this is not so easy, I still have troubles seperating this. There's also a number of: -#ifndef·WIN32 +#if·!defined(WIN32)·||·defined(__CYGWIN__) If I read that right, it shouldn't be necessary as long as the WIN32 define is not set on CYGWIN? This is only for the special case cygwin == WIN32. Just to be sure while testing I wrote it this way. And finally: -VALUE·OriginalFilename,·libpq.dll\0 +VALUE·OriginalFilename,·cygpq.dll\0 This obviously has to be done another way, because that change will affect the win32 platform as well... Sure :) This is only vendor private. -- Reini -- 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] stat() vs cygwin
Magnus Hagander wrote: Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. AIUI, only the gssapi stuff is broken. Most users are not likely to want it on Cygwin I should think. (And plenty of distros are still on 8.2 and earlier, anyway). What would be nice would be for Reini to set up a Cygwin buildfarm member that uses all the switches that the Cygwin distro wants to use. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. Right. We have had significant grief from this in the past, and don't need to return there. If we need it to get correct behaviour from some header file, then it needs to be heavily commented and localised. But I bet there are other ways to get the right result - that's what we've tended to find in the past. 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] stat() vs cygwin
Andrew Dunstan schrieb: Magnus Hagander wrote: Heh. Maybe not dead, but certainly not really alive either ;-) Given the evidence in your patch that clearly 8.3 isn't quite up to speed on cygwin, and nobody has really noticed until now. AIUI, only the gssapi stuff is broken. Most users are not likely to want it on Cygwin I should think. (And plenty of distros are still on 8.2 and earlier, anyway). Well, native windows users is a very nice to have. Actually a killer feature. What would be nice would be for Reini to set up a Cygwin buildfarm member that uses all the switches that the Cygwin distro wants to use. Without ENABLE_SSPI I just need --enable-nls --with-CXX --with-openssl --with-perl --with-python --with-libxml --with-libxslt --with-ldap and these build out of the box. I also notice this in auth.c: +#ifdef·__CYGWIN__ +#define·WIN32 +#endif What is the need to change this for just one file? Seems very fragile - the rest of our codebase assumes WIN32 != CYGWIN, and I think we should keep that consistent. Right. We have had significant grief from this in the past, and don't need to return there. If we need it to get correct behaviour from some header file, then it needs to be heavily commented and localised. But I bet there are other ways to get the right result - that's what we've tended to find in the past. Ok, I copy then the required lines from WIN32. This was the shortest patch I could come up with and it worked nice for the auth backend, with SSPI enabled. -- Reini -- 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] Git Repository for WITH RECURSIVE and others
On Tue, Jun 24, 2008 at 10:27:28PM +0200, Magnus Hagander wrote: Now, if you can give us a step-by-step on how to set it up, that would certainly help ;-) Gitosis does not, as far as I can tell, have that delegation capability, but I've come up with a way to do this: 1. Use git-shell. Yes, this does involve creating one shell account for each project, but git-shell is, by design, very short on exploitable capability. 2. Make the .ssh directory a git repository. 3. Edit .ssh/authorized_keys and push via git. I was looking into being able to do it using gitosis, with an interface on top of it's existing GIT repository for being able to delegate this. I discussed this with gitosis's author, and he wants to keep gitosis from becoming a sourceforge reimplementation. He did, however, commit to stamping it 1.0 and putting up a TODO list. I'd like to package it up for FreeBSD and Fedora, those being two common platforms. That would be good. It *would* be good, if the author seemed even vaguely interested in packaging up so much as a tarball, but he is not. His attitude is (paraphrasing from conversations with him the past few days), it's good enough as a git repository, and everybody who's using it is a git administrator, so they should know how to wrangle git repositories. While he may someday outgrow this, we really should not put him and his attitude in critical paths for our project. Let's go with git-shell, which is supported and packaged software on just about every platform, and stop waiting for Godot^Wgitosis. What do you think of this idea? It's complicated :( Wouldn't it be easier to have a gitosis admin team with the needed access? Yes, that'd probably be easier, and it's what I'd start the implementation out at. Here's an even simpler implementation: git-ssh and public keys. Yes, it involves work by administrators, which I'd be delighted to do. Cheers, David (cutting a few Gordian knots here) -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Buildfarm client code 3.1 released
I have just released version 3.1 of the buildfarm client code, which includes a fix for a perl quoting bug made 15 months ago that probably accounts for some odd failures we have been seeing. See http://pgfoundry.org/frs/?group_id=140 to download. All users are strongly recommended to upgrade to the latest version. 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
