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
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, 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
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, 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
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" <[
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
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
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:
> 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
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
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
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
> 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
[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?
>
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
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
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'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
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
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
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. |/ -
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
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
> > 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
> > 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
>> 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
27 matches
Mail list logo
