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.
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
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
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()
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 =
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
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
--
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,
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
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
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
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
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
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,
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 =
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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
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
18 matches
Mail list logo