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
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 p
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 subm
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
> >
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 doe
* 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 o
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 flakines
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 whe
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:
> 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
> -DINCLUDE_PATH=\"/usr/local/p
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";
>
At 23:39 7/02/01 +0100, Kovacs Zoltan wrote:
>So I am in a terrible need
>to have the same output in 7.1beta4 as in 7.0.2. I used pg_dump
>with -acnD and -acnd switches in 7.0.2.
>
>The old binary of pg_dump could not be used due to the changed database
>internals... :-(
>
>Is there any (maybe und
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
-DINCLUDE_PATH=\"/usr/local/pgsql/include\" -c -o preproc.o preproc.c
preproc.y
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 s
Adam Haberlach wrote:
>
> 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.
If you do it enough times without va
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 g
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 te
I've implemented the following changes in pg_ctl:
* Make -w the default for shut down, add -W option to specify no wait.
* 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 ter
At 22:27 06/02/01 -0600, JP Sugarbroad wrote:
>Well... still no CORBA? I thought someone would pick it up... then
>again, I haven't seen that many people using it. JDBC seems to be more
>popular...
going by the amount of emails I get it is ;-)
PS: There's several corba bits floating around, but
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
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:
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
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
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 d
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 (*).
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 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 w
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:
>
> And the reason for *that* is that Tcl doesn't pass the DYNAMIC_PATH flag
> to shl_load(). I find tha
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]"
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 con
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 Pytho
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 Rose
> 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 ca
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
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 so
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
Me too ! :-))
Same problem on Debian-unstable + Oliver Elphick's beta4 packages + UnixODBC
2.0.3
Database still can be accessed through ODBC in you don't need the tables list
: tried from the stats package R through RODBC : sqlTables() fails, sqlQuery()
works. So the problem is probably an inte
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 co
Well... still no CORBA? I thought someone would pick it up... then
again, I haven't seen that many people using it. JDBC seems to be more
popular...
P.S. Cc: me, I'm not on the list.
--
Taral <[EMAIL PROTECTED]>
Please use PGP/GPG to send me mail.
"Never ascribe to malice what can as easily be
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 POS
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
Title: RE: [SQL] PL/PGSQL function with parameters
Yes, that was why I wrote it in the way that I did. The table is effectively given a constant name, and the count is got from the table with a known name. But of a kludge, but in 45sec, that was all I could come up with ;-)
It would be VER
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,
Stephan Szabo wrote:
>
> On Mon, 5 Feb 2001, Christopher Kings-Lynne wrote:
>
> > Just a quick question, when a column of a table is defined to be a foreign
> > key, is it implicitly indexed, or does one still need to explicitly CREATE
> > INDEX?
>
> The foreign key columns are not currently impli
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 mea
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
> reco
46 matches
Mail list logo
