Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
this one got caught by the testfarm as well - it looks like the
openbsd-specific makefile is missing a -fPIC for the Sparc platform(I
would assume that at least NetBSD/sparc is affected too but I don't have
access to such a system
Greg Sabino Mullane wrote:
ANALYZE;
SELECT n.nspname, relname, reltuples
FROM pg_class c, pg_namespace n
WHERE c.relnamespace=n.oid
AND relkind='r'
AND NOT n.nspname ~ '^pg_'
ORDER BY 1,2;
Maybe this gem should be passed onto the pgadmin folks. When you
click on a table name in the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian FREISLICH
Sent: 05 October 2004 09:57
To: Greg Sabino Mullane
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PL/PgSQL for counting all rows in all tables.
Greg Sabino Mullane wrote:
Reini,
On Mon, Oct 04, 2004 at 11:16:49PM +0200, Reini Urban wrote:
This time contrib is added to the cygwin package. It was not in 7.4.x.
Actually, contrib was included:
$ tar -tjf postgresql-7.4.5-1.tar.bz2 | fgrep contrib
usr/share/doc/postgresql-7.4.5/contrib/
As a side effect of fixing timing issues with the new trigger
timing, Tom and I noticed that some foreign key actions were broken
(especially with deferred constraints) and as part of looking at that we
believe that we had made the wrong decision as to when the actions were
meant to fire
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Why did you remove -DPIC ?
uhm partly because I sent the wrong patch and partly because I didn't
understood what that to do anyway(in the !Sparc case). The only place I
can find on my machine where defining PIC seems
As some of you know, in the past few days I have tightened up the use of
libpgport so it is less prone to breakage from code changes. However,
in the cleanup, I found an unusual problem with linking pg_dump on
Win32. If I build pg_dump linking in libpgport and libpq, I get a
failure due to a
On Oct 5, 2004, at 9:59 AM, Abhijit Menon-Sen wrote:
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained way.
Also attached is a test program à la testlibpq3.c that I used to test
the change. This should be all
Reini Urban schrieb:
Cygwin can do symlinks for directories via the magic .lnk file.
But Cygwin can also do junctions via hardlinks in ln.exe.
I thought link() calls the junction code.
I'll investigate why the libc link() failed, and if ln.exe does some
sifferent magic, similar to pgsymlink.
I
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Wheeler
Sent: Tuesday, October 05, 2004 10:32 AM
To: Abhijit Menon-Sen
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
On Oct 5, 2004, at 9:59
On Oct 5, 2004, at 10:47 AM, Dann Corbit wrote:
Create a 64 bit hash (e.g. UMAC) of the prepared statement (removing
hardwired parameters as needed so that SELECT Col1, col2 FROM
Some_Table where FOO = 'BAR' becomes SELECT COL1, COL2 FROM
SOME_TABLE WHERE FOO = ?, form consistent capitalization
Reini Urban wrote:
Reini Urban schrieb:
Cygwin can do symlinks for directories via the magic .lnk file.
But Cygwin can also do junctions via hardlinks in ln.exe.
I thought link() calls the junction code.
I'll investigate why the libc link() failed, and if ln.exe does some
sifferent
Cygwin can do symlinks for directories via the magic .lnk file.
But Cygwin can also do junctions via hardlinks in ln.exe.
I thought link() calls the junction code.
I'll investigate why the libc link() failed, and if ln.exe does some
sifferent magic, similar to pgsymlink.
I thought a little
Bruce Momjian schrieb:
Reini Urban schrieb:
Cygwin can do symlinks for directories via the magic .lnk file.
But Cygwin can also do junctions via hardlinks in ln.exe.
I thought link() calls the junction code.
I'll investigate why the libc link() failed, and if ln.exe does some
sifferent magic,
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained way.
Any thoughts? Does this look good enough for 8.0?
Seems OK as far as it goes, but a complete patch would
At 2004-10-05 17:48:27 -0400, [EMAIL PROTECTED] wrote:
Searching for all references to one of the existing entry points such
as PQexecPrepared will probably help you identify what you need to do.
OK. I've attached two additional patches below.
I don't really understand how the *.def files
At 2004-09-20 13:24:47 -0400, [EMAIL PROTECTED] wrote:
It depends on whether you think that PQprepare should bundle the
Describe Statement operation or not.
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained
17 matches
Mail list logo
