Tom Lane wrote:
But it's not really tracking the variable; with Ian's proposed
implementation, after
create table foo(bar int4);
create function fooey(foo.bar%type) ...;
drop table foo;
create table foo(bar int8);
You're welcome ;-)
Marvellous, it works! How much time did it take for you to find what have
to be changed?
Thank you very much.
Regards, Zoltan
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Alessio Bragadini [EMAIL PROTECTED] writes:
Tom Lane wrote:
But it's not really tracking the variable; with Ian's proposed
implementation, after
create table foo(bar int4);
create function fooey(foo.bar%type) ...;
drop table foo;
create table foo(bar int8);
you would still have
Philip Warner [EMAIL PROTECTED] writes:
Is anybody planning to fix the problem with ALTER TABLE ADD CONSTRAINT...
in which the constraints are not applied to child tables?
AFAIK no one is looking at it presently (although Stephan Szabo has
probably thought about it). If you want to tackle it,
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
Ken Hirsch [EMAIL PROTECTED] writes:
I don't have a machine with XFS installed and it will be at least a week
before I could get around to a build. Any volunteers?
I think I
Date: Fri, 16 Mar 2001 22:58:42 +1100
From: Philip Warner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: I cannot force pg_dump to disable triggers
At 12:49 16/03/01 +0100, kovacsz wrote:
I downloaded the current snapshot and realized that you changed the
dumping behaviour about
Hello,
I am running PostgreSQL on a FreeBSD machine with 1 Gig of ram, and dual
P3-733mhz CPUs. This server also runs Apache and is a production/web server.
I frequently run into the errno:55 on my site, if I simply click refresh it
goes away. Anyone have any ideas what is causing this, or
At 17:23 9/05/01 +0200, Kovacs Zoltan wrote:
Well, I stopped trying it in March but I'm in a need of changing to 7.1 (I
should use Tom's patch). I did a 'make distclean' but no difference: there
are no lines switching the triggers on/off. I'm using PostgreSQL 7.1 on
i686-pc-linux-gnu, compiled by
We need to discuss whether we like the %TYPE feature proposed by Ian
OK, one idea is to throw a elog(NOTICE) when they use this feature,
stating that it will not track column changes. Another option is to
just forget about the feature entirely. Do we have people
who like this feature?
The connect group would be granted these System Privileges:
If we keep it like others (e.g. Informix) this System Privilege would be called
resource. I like this name better, because it more describes the detailed
priviledges.
CREATE AGGREGATE privilege
CREATE INDEX privilege
Tom's suggestion does not sound reasonable to me. If PostgreSQL is not
built with MULTIBYTE, then it means there would be no such idea
encoding in PostgreSQL becuase there is no program to handle
encodings. Thus it would be meaningless to assign an encoding to a
database if MULTIBYTE
On Mon, May 07, 2001 at 02:48:11PM -0400, Bruce Momjian wrote:
Can someone remind me what we are going to do with this?
This patch add to 7.0.2 code NOCREATETABLE and NOLOCKTABLE feature:
It's my old patch, it's usable and some people use it for 7.0.x. But
it's really temporary
At 09:36 9/05/01 -0400, Bruce Momjian wrote:
Is anybody planning to fix the problem with ALTER TABLE ADD CONSTRAINT...
in which the constraints are not applied to child tables?
I thought we had not figured out how to inherit those, or at least
certain constraints like UNIQUE. We do have on
I had a thought just now about how to deal with the TODO item about
coping with deferred trigger lists that are so long as to overrun
main memory. This might be a bit harebrained, but I offer it for
consideration:
What we need to do, at the end of a transaction in which deferred
triggers were
Bruce Momjian [EMAIL PROTECTED] writes:
Does this relate to allowing functions to be recreated with the same OID
as the original function? I think we need that badly for 7.2.
No, I don't think that's very related; that's a simple matter of
implementing an ALTER FUNCTION command. The other
Bruce Momjian [EMAIL PROTECTED] writes:
No, I don't think that's very related; that's a simple matter of
implementing an ALTER FUNCTION command. The other thing will require
figuring out how to do dependency tracking.
Got it. Let me ask, if they change the column type, would they use
Makes it more fun :) Kinda like a lottery ticket:
- reliable (cherry)
- fast (cherry)
- resource hog (lemon)
--
Rod Taylor
BarChord Entertainment Inc.
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
To: Martín Marqués [EMAIL PROTECTED]
Cc: Trond Eivind Glomsrød [EMAIL
On Wed, 9 May 2001, Peter Eisentraut wrote:
We did not bump the shared library versions before the 7.1 release.
Maybe we should do this before 7.1.2 goes out.
Ummm ... unless there are any changes that would require someone to
recompile their apps between v7.1.1 and v7.1.2, I don't think so
Bruce Momjian [EMAIL PROTECTED] writes:
We did not bump the shared library versions before the 7.1 release.
Maybe we should do this before 7.1.2 goes out.
I thought I did that long ago for 7.1, or I should have anyway. I don't
see the commits either. Seems we can't do it in a minor
On Wed, 9 May 2001, Bruce Momjian wrote:
We did not bump the shared library versions before the 7.1 release.
Maybe we should do this before 7.1.2 goes out.
I thought I did that long ago for 7.1, or I should have anyway. I don't
see the commits either. Seems we can't do it in a minor
Peter Eisentraut [EMAIL PROTECTED] writes:
The Hermit Hacker writes:
IMHO, it should only be changed if there are incompatibilities between
releases ... we modify the API, mainly ... anything more then that, and
we're making ppl recompile to pull in libraries that only unlying code has
On Wed, 9 May 2001, Peter Eisentraut wrote:
I'm talking about the minor number. The only thing that effects is
that executables would pick up the new version if they have the old
one in the path as well, no potential problems.
Okay, but, what does that buy you? One overwrites the old
22 matches
Mail list logo