Quoting Mathieu Dube [EMAIL PROTECTED]:
Hi y'all,
Is it a bad idea for an app to keep just a couple of connections to a
database, put semaphore/mutex on them and reuse them all through the
program?
Of course I would check if their PQstatus isnt at CONNECTION_BAD and
reconnect
On Wed, 7 Feb 2001, Hannu Krosing wrote:
Hi,
I've written a small function that should go into contrib for 7.1
As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)
hmm, see you PG sources -- pg_locale.c file?
I mean that
On 29 Jan 2001 at 02:50 (-0500), Lamar Owen wrote:
| Lamar Owen wrote:
| ftp://ftp.postgresql.org/pub/dev/test-rpms is the place.
|
| One note: for whatever reason the date on the uploaded RPM's has the
| wrong year -- but the timestamp on my local copy has the correct date.
| In any case,
Hi out there,
I am looking to use POSTGRESQL as a backend database. However I am
writing the TCP/IP data exchange protocol/and server, and I want to link
interface support to POSTGRESQL data files.
Is there a set of files that I could compile with my application to
access/update the
I have a problem with 7.1 beta 4
Setup :
Debian 2.3(?) (unstable)
Kernel 2.18pre23 (the stock Debian kernel)
PostgreSQL 7.1beta4 as packaged for Debian by Oliver Elphick
unixODBC 2.0.3 compiled from unixODBC.org's sources against the installed and
working PG 7.1b4.
The problem is that an ODBC
Hi,
Having seen that the driver I distribute doesn't work against 7.1 Beta
4, and not wanting to continue the split between the two versions,
I have tried to get the driver in the beta working with unixODBC, but
I have come against a couple of problems, one a show stopper.
First let me say that
Karel Zak wrote:
On Wed, 7 Feb 2001, Hannu Krosing wrote:
Hi,
I've written a small function that should go into contrib for 7.1
As locale issues are quite tricky, being able to find out what locale
backend thinks it is in is a good thing ;)
hmm, see you PG sources --
Tom, Jan, Michael,
While I have not looked closely, I seem to recall that plpgsql handles
INTO by stripping that clause out of the statement before it's passed to
the SQL engine. Evidently that's not happening in the EXECUTE case.
Jan, do you agree this is a bug? Is it reasonable to try
Hannu Krosing [EMAIL PROTECTED] writes:
BTW, does anyone know if setlocale() is an expensive function ?
The variant where you're just querying the current setting should not be
too expensive. I'd expect the variant where you are changing the
setting to be very expensive, however; most likely,
On Sun, 28 Jan 2001 07:57:43 +
"Oliver Elphick" [EMAIL PROTECTED] wrote:
Hannu Krosing wrote:
If it's all your code, then you are free to license it under any licence
you desire.
...
What you probably can't do is to revoke the GPL license.
You can't revoke it from
In the current CVS, the PYTHON build sets LDSHARED to ld -G, not
cc -G. It passes -Wl,-h,... to the ld command, and breaks.
ALL shared library builds on UnixWare should use cc -G or CC -g as
appropriate.
I don't see right off where this is set.
Peter E, can you fix?
Thanks!
--
Larry
Larry Rosenman writes:
In the current CVS, the PYTHON build sets LDSHARED to ld -G, not
cc -G. It passes -Wl,-h,... to the ld command, and breaks.
ALL shared library builds on UnixWare should use cc -G or CC -g as
appropriate.
I have arranged for the -Wl,-h to be left out in the Python
Nick Gorham writes:
First let me say that I want to stop the split between the version, If
I can just point people to your distribution, thats fine by me, but it
needs to work :-). I am not trying to get you to standardise on
unixODBC, just to provide the option.
This is nice, but it
I thought I'd tried pgAccess back in the dim past with success, but as
of current sources it fails on HPUX 10.20 and Tcl 8.3.2:
$ pgaccess regression
Error in startup script: couldn't load file "libpgtcl.sl": no such file or directory
while executing
"load libpgtcl[info sharedlibextension]"
On Wed, Feb 07, 2001 at 01:34:58PM -0500, Tom Lane wrote:
I thought I'd tried pgAccess back in the dim past with success, but as
of current sources it fails on HPUX 10.20 and Tcl 8.3.2:
SNIP problem with dynamic load and Tcl
And the reason for *that* is that Tcl doesn't pass the
I submitted a bug to their SourceForge Bug List.
Thanks!
LER
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 12:34 PM
To: Larry Rosenman
Cc: PostgreSQL Hackers List
Subject: Re: python build/Current CVS/UnixWare
Larry Rosenman
Tom Lane writes:
Does anyone object if I modify pgaccess so that it always specifies the
full path to the library?
If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default installation
pgaccess won't find libpgtcl on
I've got a system in which a row is being created by one process,
a notify is sent, and another process finds and then deletes the
row. This whole interchange seems to be taking about a second, which
seems oddly slow. As far as I know, I have the fsync-on-anything
turned off (*).
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Does anyone object if I modify pgaccess so that it always specifies the
full path to the library?
If I had known that this was possible I would have done it myself already.
;-) This is a good idea in general because in a default
Tom Lane wrote:
client-devel and server-devel are the right division IMHO. SPI is a
subset of server-side development, but not all server-side code needs
SPI. Consider user-written functions and datatypes. These guys do not
Ok, I can do that. Obsoletes:devel here we come!
My thought was
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
BTW, does anyone know if setlocale() is an expensive function ?
The variant where you're just querying the current setting should not be
too expensive. I'd expect the variant where you are changing the
setting to be very
I had a need to read such things as the backend locale and the catalog
version number from the current database, and couldn't find any existing
program to do that.
The attached utility produces this output:
linda:~$ pg_controldata
Log file id: 0
Log file segment:
Constantin Teodorescu [EMAIL PROTECTED] writes:
Yes. The full path to libpgtcl might be specified directly in pgaccess.
I have committed pgaccess changes to do this.
But libpq library need to be found automatically because it isn't in a "load"
explicit command.
At least on HPUX 10, this
Peter Eisentraut [EMAIL PROTECTED] writes:
I've implemented the following changes in pg_ctl:
Sounds good to me.
* Add -l option to name log file. If the option is omitted, then the
postmaster log goes to stdout, so you can use 'pg_ctl ... log' and still
get pg_ctl's stderr on the
Peter Eisentraut wrote:
I've implemented the following changes in pg_ctl:
[snip]
This should make pg_ctl a lot more suitable for startup scripts and
overall. If this is okay then I'll also try to merge the contrib/linux
and contrib/init.d scripts and reflect these changes there.
Sounds good
Philip, the last element of the chain has caused a big problem for me
changing from 7.0.2 to 7.1beta4: dumping the database out and putting
back.
As you might not know, at my place getting the data from the database is
not a simple pg_dump, but the data come through complex filter programs
(awk
Nick Gorham wrote:
Then having sorted this out, I get a core dump, that I have traced to
CC_lookup_pg_version, the code did
CC_lookup_pg_version(ConnectionClass *self)
{
HSTMT hstmt;
StatementClass *stmt;
RETCODE result;
char *szVersion = "0.0";
static
Vince Vielhaber [EMAIL PROTECTED] writes:
In today's (2/7/2k1) snapshot from hub, I'm getting this:
gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8
-DPATCHLEVEL=0
On Wed, 7 Feb 2001, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
In today's (2/7/2k1) snapshot from hub, I'm getting this:
gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8
Vince Vielhaber [EMAIL PROTECTED] writes:
Now I get:
byacc -d preproc.y
byacc: f - maximum table size exceeded
gmake[4]: *** [preproc.c] Error 2
Better install bison if you want to work with CVS sources ...
the lack of bison probably explains why it's failing for you on
this system when
BTW, I pulled down the current snapshot, and there doesn't seem to be
anything wrong with preproc.c in it. So the lack of bison on your
machine wasn't the issue anyway; it should've compiled the preproc.c
from the snapshot without complaint.
It does sound like there may be some outright
* Tom Lane [EMAIL PROTECTED] [010207 17:24] wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
Now I get:
byacc -d preproc.y
byacc: f - maximum table size exceeded
gmake[4]: *** [preproc.c] Error 2
Better install bison if you want to work with CVS sources ...
the lack of bison
On Wed, 7 Feb 2001, Tom Lane wrote:
BTW, I pulled down the current snapshot, and there doesn't seem to be
anything wrong with preproc.c in it. So the lack of bison on your
machine wasn't the issue anyway; it should've compiled the preproc.c
from the snapshot without complaint.
It does
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a patch, or can
some one
Updated.
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a patch, or
On Wed, Feb 07, 2001 at 10:15:02PM -0500, Tom Lane wrote:
I have looked a little bit at what it'd take to make SELECT INTO inside
an EXECUTE work the same as it does in plain plpgsql ...
If we do nothing now, and then implement this feature in 7.2, we will
have a backwards compatibility
Applied. Thanks.
On Tue, 6 Feb 2001, Bruce Momjian wrote:
DAEMON=/home/postgres/bin/pg_ctl
Ooops That is my mistake... Should have been
/usr/local/pgsql/bin/pg_ctl. I have /usr/local/pgsql/ symlinked to /home
(where there is more, faster disk space). I can submit a
37 matches
Mail list logo
