Re: [PATCHES] [subxacts] Savepoint syntax

2004-07-26 Thread Alvaro Herrera
On Sun, Jul 25, 2004 at 04:58:01PM -0400, Alvaro Herrera wrote: Attached is the savepoints syntax patch, hopefully last try. Essentially the same as the last patch, with the following differences: Brown paper bag patch. Please disregard. I'll post a good patch tomorrow morning. Sorry for

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Dave Page
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 26 July 2004 04:46 To: Dave Page Cc: Magnus Hagander; Bruce Momjian; Josh Berkus; PostgreSQL-patches Subject: Re: [PATCHES] [HACKERS] Function to kill backend If you don't mind plastering a use at your own risk

[PATCHES] fix for parameterized queries in DECLARE CURSOR statements

2004-07-26 Thread Oliver Jowett
Here's a patch that allows parameterized queries to be used in a DECLARE CURSOR statement. Previously, the DECLARE would succeed but any FETCHes would fail as the parameter values supplied to DECLARE were not propagated to the portal it created. This patch adds that propagation. See

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Andreas Pflug
Tom Lane wrote: If you don't mind plastering a use at your own risk sign on it, then go for it. killing a backend is obviously much more at your own risk than a descent function. Taken from your mail, I understand that a killed backend might leave some loose ends, eg. open locks, which would

Re: [PATCHES] pg_config

2004-07-26 Thread Andrew Dunstan
Bruce Momjian wrote: Andrew Dunstan wrote: 2. these cases need to be fixed: else if (strcmp(argv[i],--includedir-server) ==0) get_pkginclude_path(mypath,otherpath); else if (strcmp(argv[i],--libdir) == 0)

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes: Taken from your mail, I understand that a killed backend might leave some loose ends, eg. open locks, which would degrade the cluster's performance. Still, it should not corrupt the shared mem, just leave it as if the backend's still alive and

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Christopher Kings-Lynne
If you want to put in the function and document that it may cause problems, I won't object; it's not like we don't have other features that are poorly implemented :-(. But my vote would be to remove it. I'm down with removing it - people don't read documentation :/ Chris

Re: [PATCHES] pg_config

2004-07-26 Thread Peter Eisentraut
Andrew Dunstan wrote: I don't see a function there to report the libdir at all (only pkglibdir), and for includedir-server we would need either to append /server or to have a function in path.c that reported it for us correctly. These paths can all be more or less independently (or at least

Re: [PATCHES] pgxs: build infrastructure for extensions v4

2004-07-26 Thread Peter Eisentraut
Tom Lane wrote: Peter, do you have time before the end of the month to sort this out? It would be nice to have a real solution in this area, because certainly we have some problems here. Yes, I'll make sure it gets done. By the way, extra credit for someone who manages to get slony1 to build

[PATCHES] win32 version info

2004-07-26 Thread Magnus Hagander
This patch along with the attached files (.tar.gz unpacks in src/) adds VERSIONINFO to all binaries under win32. This is generally considered a good thing (actually, I think it's required to be allowed to call your program Designed for Microsoft Windows. We're not going to get that anyway, but it

Re: [PATCHES] win32 version info

2004-07-26 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: This patch along with the attached files (.tar.gz unpacks in src/) adds VERSIONINFO to all binaries under win32. Ya know, this is the sort of invasive junk that I was afraid people would try to force on us for the Windows port :-(. Can't you localize

Re: [PATCHES] win32 version info

2004-07-26 Thread Magnus Hagander
This patch along with the attached files (.tar.gz unpacks in src/) adds VERSIONINFO to all binaries under win32. This is generally considered a good thing Out of curiosity: Why? Well, because it allows the user as well as other programs to identify what version of a file is installed. For

Re: [PATCHES] win32 version info

2004-07-26 Thread Magnus Hagander
This patch along with the attached files (.tar.gz unpacks in src/) adds VERSIONINFO to all binaries under win32. Ya know, this is the sort of invasive junk that I was afraid people would try to force on us for the Windows port :-(. I fail to see how this is so invasive. And I definitly don't

Re: [PATCHES] win32 version info

2004-07-26 Thread Andrew Dunstan
Magnus Hagander wrote: Can't you localize this into a single build rule somewhere? And surely we do not need to maintain a boilerplate .rc file for every executable. There is a field in the RC file that is file description. It's pretty much different for every file. (There is also a

Re: [PATCHES] win32 version info

2004-07-26 Thread Peter Eisentraut
Magnus Hagander wrote: Well, because it allows the user as well as other programs to identify what version of a file is installed. psql --version For error-checking purposes (which DLL version is really there? And debugger will also tell you which version of the DLL is actually loaded in

Re: [PATCHES] win32 version info

2004-07-26 Thread Magnus Hagander
Well, because it allows the user as well as other programs to identify what version of a file is installed. psql --version That works for an executable. And that works for the user. Doesn't work as well for a piece of software that does this. How is it supposed to know which .EXEs it can send

Re: [PATCHES] win32 version info

2004-07-26 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Makefile.global or similar could define the build rule once, like %.o: %.rc windres -DFILEDESC=$(FILEDESC) $ -o $@ --include-dir=$(top_builddir)/src/include Actually, I was wondering if we could not include this in a build rule for executables,

Re: [PATCHES] win32 version info

2004-07-26 Thread Magnus Hagander
Makefile.global or similar could define the build rule once, like %.o: %.rc windres -DFILEDESC=$(FILEDESC) $ -o $@ --include-dir=$(top_builddir)/src/include Actually, I was wondering if we could not include this in a build rule for executables, so that it's not necessary for the

Re: [PATCHES] win32 version info

2004-07-26 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: All that is then needed is to teach each binary to link in win32ver.o. For initdb, I've done this like: ifeq ($(PORTNAME), win32) FILEDESC=initdb - initialize a new database cluster OBJS+=win32ver.o endif I assume what you would like is to have

Re: [PATCHES] win32 version info

2004-07-26 Thread Peter Eisentraut
Magnus Hagander wrote: 1) How would I go about to have the Makefile actually build those files and link them in without explicitly teaching it about it? There is no (useful) implicit rule to build executables. Either you make one up (difficult), or you just do the explicit thing. -- Peter

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] writes: What about implementing kill as cancel then exit? Does that guarantee a safe exit in all cases? That was exactly what Bruce's patch turned it into. That would be workable if we separated this case from the existing elog(FATAL) behavior, but doing it

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Oliver Jowett
Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a shared-mem flag saying exit after cancel then send SIGINT? I guess this is

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a shared-mem flag saying exit

Re: [PATCHES] win32 version info

2004-07-26 Thread Peter Eisentraut
Tom Lane wrote: I was originally thinking of somehow migrating the executable build rules into a single pattern rule, but given the lack of any suffix on executable names it's not clear how to use a pattern rule for the purpose. You can write a rule for that using %: %.o but... And the

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Bruce Momjian
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a

Re: [PATCHES] win32 version info

2004-07-26 Thread Bruce Momjian
Magnus Hagander wrote: This patch along with the attached files (.tar.gz unpacks in src/) adds VERSIONINFO to all binaries under win32. This is generally considered a good thing Out of curiosity: Why? Well, because it allows the user as well as other programs to identify what version

[PATCHES] More fixes for pg_dump

2004-07-26 Thread Christopher Kings-Lynne
This patch does two things to pg_dump: * Dumps comments on columns of composite types * Instead of putting all the OWNER TO commands at the end, it dumps then after each object. This is WAY more readable and nice. ACLs are still at the end. Chris pg_dump5.txt.gz Description: GNU Zip

Re: [PATCHES] [subxacts] Savepoint syntax

2004-07-26 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Attached is the savepoints syntax patch, hopefully last try. - Tab completion patch from Gaetano is included. Reviewed and committed. I did not apply your changes to spi.c, instead choosing to revert it to the former coding that disallowed any