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 in
Is anybody planning to fix the problem with ALTER TABLE ADD CONSTRAINT...
in which the constraints are not applied to child tables?
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ -
> 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);
>>
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
[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?
>
> 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 behavio
On Wed, 9 May 2001, Philip Warner wrote:
>
> Is anybody planning to fix the problem with ALTER TABLE ADD CONSTRAINT...
> in which the constraints are not applied to child tables?
>
I'm working on the check constraint case (didn't realize that
those inherited since unique, primary key and fore
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 how
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, compile
>> 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 featur
> > 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 privileg
> > 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 i
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 sol
On Tue, 8 May 2001, Bruce Momjian wrote:
> > The PAM support patch concerns me --- it looks like yet another chunk
> > of code that will tie up the postmaster in a single-threaded
> > conversation with a remote daemon that may or may not respond promptly.
> > I recommend holding off on this until
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
Philip Warner <[EMAIL PROTECTED]> writes:
> ie. The CHECK constraints inherit only at the time of table creation. I
> think this is a bug in ALTER TABLE for CHECK constraints.
More like an "unimplemented feature" ;-).
After thinking for a moment, I believe the only real gotcha that could
arise
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 fi
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 u
Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > When compared to the earlier ones (including XFS), you'll note that ReiserFS
> > performance is rather poor in some of the tests - it takes 37 vs. 13
> > seconds for 8192 inserts, when the inserts are different transactions.
>
> That is all the
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" <[
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 min
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
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 lib
27 matches
Mail list logo
