Joe,
I've been told by Tom Lane that the problem is related to having Perl
working, so I'm assuming theres a change that needs to go into the win32
makefile that builds this file using perl.
I'm going to have a go at finding the relevant commands and create a patch.
I've also attached the
Christopher Kings-Lynne writes:
Seems there's a few errors in the SQL99 compatibility list. For one, it
says we support WITH CHECK OPTION on views which I'm pretty sure we don't.
I've gone through the list and made some corrections. It makes for a nice
to-do list now (with the possible
Hello hackers,
In the pg_stat_activity view, the usesysid is shown as having type Oid.
However pg_shadow says it's an integer. Is there a reason? Looks like
a bug.
This patch seems to corrects this issue, but I don't know if there's
something else involved.
Index: src/include/catalog/pg_proc.h
On Thu, Nov 14, 2002 at 08:55:22PM +, Patrick Welche wrote:
Believe it or not, I'm trying to compile today's cvs pgsql on a
Debian 2.2.19 system. Compilation dies while compiling pg_dump with
../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit'
In the mail archives
Alvaro Herrera [EMAIL PROTECTED] writes:
In the pg_stat_activity view, the usesysid is shown as having type Oid.
However pg_shadow says it's an integer. Is there a reason?
There's been disagreement for a long time over whether userids should be
OIDs or ints. If you want to introduce
Alvaro Herrera [EMAIL PROTECTED] writes:
+ Deletions are handled by getting a super-exclusive lock on the target
page, so that no other backend has a pin on the page when the deletion
starts. This means no scan is pointing at the page. This is OK for
deleting leaf items, probably
snpe [EMAIL PROTECTED] writes:
When I call DECLARE CURSOR out of transaction command success,
but cursor is not created
Reference manual say that this get error :
ERROR: DECLARE CURSOR may only be used in begin/end transaction blocks
Oops. I removed that test on 21-Oct as part of this
For 7.4 I would like to add a function for importing float8 values
into cube. But because the cube data type is variable length I am
not sure what a good approach would be.
Currently this can be poorly done using text as an intermediate type.
As far as I can tell functions can't take sets as
On Sun, Nov 17, 2002 at 01:16:29PM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In the pg_stat_activity view, the usesysid is shown as having type Oid.
However pg_shadow says it's an integer. Is there a reason?
There's been disagreement for a long time over whether
Bruno Wolff III [EMAIL PROTECTED] writes:
For 7.4 I would like to add a function for importing float8 values
into cube. But because the cube data type is variable length I am
not sure what a good approach would be.
I'm not clear on what you want to accomplish. How are you expecting
the source
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In the pg_stat_activity view, the usesysid is shown as having type Oid.
However pg_shadow says it's an integer. Is there a reason?
There's been disagreement for a long time over whether userids should be
OIDs or ints. If you want
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
And what about REINDEX? That seems to have a different syntax from the
other two.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd recommend not making any piecemeal changes, especially not when
there's not yet a consensus which way to converge.
Well, seems we should make it consistent at least.
I think the original argument stemmed from the idea that we ought
Bruce Momjian [EMAIL PROTECTED] writes:
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
I agree, lose the ALL.
And what about
On Sun, Nov 17, 2002 at 04:42:01PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually, I'm planning to do the freelist thing, then the btree
compaction and then replace the current REINDEX code with the compaction
code, probably including some means to do
I totally agree with what you have said. Peter, can you clarify your
reasoning for OID for user/group id?
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'd recommend not making any
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
I agree, lose the
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
---
Tom Lane wrote:
snpe [EMAIL PROTECTED] writes:
When I call DECLARE CURSOR out of
Bruce Momjian [EMAIL PROTECTED] writes:
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
Since Marc hasn't yet announced RC1, I think we could get away with just
a quick fix and re-roll of RC1 ...
Bruce Momjian [EMAIL PROTECTED] writes:
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
Here is the patch I am testing (in current sources; I don't think it
needs any adjustments for REL7_3, but haven't tried to
On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
And what about REINDEX? That seems to have a different syntax from the
other two. Seems there should be some consistency.
We don't have a REINDEX ALL, and I'm not
Alvaro Herrera [EMAIL PROTECTED] writes:
What I don't understand is what are the parameters in the
ReindexDatabase function for. For example, the boolean all is always
false in tcop/utility.c (and there are no other places that the function
is called). Also, the database name is checked to
In looking at the CLUSTER ALL patch I have applied, I am now wondering
why the ALL keyword is used. When we do VACUUM, we don't use ALL.
VACUUM vacuums all tables. Shouldn't' CLUSTER alone do the same thing.
And what about REINDEX? That seems to have a different syntax from the
other
Alvaro Herrera wrote:
On Sun, Nov 17, 2002 at 06:43:38PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
And what about REINDEX? That seems to have a different
syntax from the other two. Seems there should be some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Let's just fix it and roll an RC2 with the fix. If not, we can just fix
it in 7.3.1 but I see little problem in rolling an RC2.
Since Marc hasn't yet announced RC1, I think we could get away with just
a quick fix and re-roll of RC1
Was there supposed to be a patch attached to this email?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Evgen Potemkin
Sent: Friday, 15 November 2002 5:38 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] Proposal of hierarchical queries, a la
Ports list updated:
http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
---
Christopher Kings-Lynne wrote:
This is a successful report for OpenBSD 3.2 on sparc and i386
-Original
Ports list updated:
Sure? Still says 7.2 for openbsd and has old submission date...
http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
It updates every 15 minutes. You have to give it time. :-)
---
Christopher Kings-Lynne wrote:
Ports list updated:
Sure? Still says 7.2 for openbsd and has old submission date...
30 matches
Mail list logo
