Re: [GENERAL] release notes/Appendix E in documentation

2004-01-06 Thread Peter Eisentraut
Joshua D. Drake wrote: I think what you are really looking for is a regular summary of the hackers' activity, to know where things are moving. Someone used to do that, but I don't know what become of it. Isn't that the PostgreSQL Weekly news from Robert Treat? Yes, that's the one I meant.

Re: [GENERAL] release notes/Appendix E in documentation

2004-01-06 Thread Alvaro Herrera
On Tue, Jan 06, 2004 at 09:33:39PM +0100, Peter Eisentraut wrote: Joshua D. Drake wrote: I think what you are really looking for is a regular summary of the hackers' activity, to know where things are moving. Someone used to do that, but I don't know what become of it. Isn't that the

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Adam Ruth
1. Modifying the applications to use schemas instead of connecting to specific databases. Getting the authors to use schemas so I do it once. One thing I'd suggest would be to modify the application to issue a set search_path = yourschema; at the beginning, then the rest of the

Re: [GENERAL] Date column that defaults to 'now'

2004-01-06 Thread Gaetano Mendola
John Siracusa wrote: On 1/5/04 4:29 PM, Michael Glaesemann wrote: (If you're not the John Siracusa who writes for Ars Technica, the sentiment still holds. :) ) I am everywhere! (worked, thanks to both of you who replied :) Anyway the two solution solve different problems: 1) DEFAULT now()

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Oliver Elphick
On Tue, 2004-01-06 at 22:06, Adam Ruth wrote: 1. Modifying the applications to use schemas instead of connecting to specific databases. Getting the authors to use schemas so I do it once. One thing I'd suggest would be to modify the application to issue a set search_path =

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Roderick A. Anderson
On Tue, 6 Jan 2004, Adam Ruth wrote: One thing I'd suggest would be to modify the application to issue a set search_path = yourschema; at the beginning, then the rest of the application wouldn't need to change. That's what I did when I did something similar. Neat idea. I was thinking

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Roderick A. Anderson
On Tue, 6 Jan 2004, Oliver Elphick wrote: You can use ALTER DATABASE to set that up permanently, without touching the application. I'd thought of this but since there will be several applications installed and some, I am sure, will have same-named tables this could back-fire. Rod --

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Martijn van Oosterhout
On Tue, Jan 06, 2004 at 03:34:21PM -0800, Roderick A. Anderson wrote: On Tue, 6 Jan 2004, Oliver Elphick wrote: You can use ALTER DATABASE to set that up permanently, without touching the application. I'd thought of this but since there will be several applications installed and some,

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Adam Ruth
On Jan 6, 2004, at 3:27 PM, Oliver Elphick wrote: On Tue, 2004-01-06 at 22:06, Adam Ruth wrote: 1. Modifying the applications to use schemas instead of connecting to specific databases. Getting the authors to use schemas so I do it once. One thing I'd suggest would be to modify the

[GENERAL] problems with transaction blocks

2004-01-06 Thread Chris Ochs
I want to do a series of inserts within a single transaction block, but with postgresql if one insert fails, the whole block is aborted. Is there any way to get around this behavior so that postgresql won't abort the entire transaction if a single insert returns an error? Chris

Re: [GENERAL] DBs and Schemas

2004-01-06 Thread Roderick A. Anderson
On Wed, 7 Jan 2004, Martijn van Oosterhout wrote: Are you actually going to be doing joins between these applications? If not, why not setup multiple databases, then you can be sure they won't conflict. Well in at least one situation I can think of there will be joins. And with a minimum of

[GENERAL] SPI question (or not): trying to read from Large Objects from within a function

2004-01-06 Thread David Helgason
What: I'm having trouble finding out how to find the current PGconn connection inside a C function. Looking through the documentation didn't give this up. Could anyone suggest where to look? I didn't even see anything similar to this in the SPI_* documentation. Perhaps I am totally mislead

[GENERAL] Loading a dumped databse from cd

2004-01-06 Thread Paul Mc Gee
hi everybody i have postgresql installed on my red hat linux machine and i want to load up a dumped postgresql database which i have on cdrom. does anyone know how i could do this? thanks paul __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes

Re: [GENERAL] SPI question (or not): trying to read from Large Objects from within a function

2004-01-06 Thread Tom Lane
David Helgason [EMAIL PROTECTED] writes: I'm having trouble finding out how to find the current PGconn connection inside a C function. What makes you think that *the* current PGconn is a valid concept? libpq has always supported multiple active connections. regards,

Re: [GENERAL] SPI question (or not): trying to read from Large Objects from within a function

2004-01-06 Thread David Helgason
Thank you very much, I figured I needed to open my own using SPI_connect(). I had assumed that there was sth like a the-connection-this-functions-is-begin-run-through. Now I'm having problems with size_t inBufSize = 8192; char* inBuffer = (char*)palloc(inBufSize); int bytes_read =

[GENERAL] unsubscribe

2004-01-06 Thread Jiri D. Hoogeveen
---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [GENERAL] SPI question (or not): trying to read from Large Objects from within a function

2004-01-06 Thread David Helgason
Sorry for spamming I'm getting the hang of this, and figured this one out myself :) These internal functions (loread/lowrite) have quite different signatures from their C equivalents (as opposed to lo_lseek). Found out from the sources that I was using it very incorrectly. But discovered

Re: [GENERAL] SPI question (or not): trying to read from Large Objects from within a function

2004-01-06 Thread Tom Lane
David Helgason [EMAIL PROTECTED] writes: These internal functions (loread/lowrite) have quite different signatures from their C equivalents (as opposed to lo_lseek). Found out from the sources that I was using it very incorrectly. I had just realized from reading your last message that you