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 y
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
l
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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 = DatumGetInt3
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.
regard
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
h
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 here
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 o
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 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 applicat
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
> an
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, 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 thinki
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
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) DEF
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
applicati
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.
> >
> > Is
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
18 matches
Mail list logo
