> Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner
We ran these regression tests with both native cc and gcc -- worth
mentioning that both work.
Adriaan
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropr
Dear all,
I've migrated from RedHat6.2/PHP3.0/PostgreSQL6.5 to
Mandrake/PHP4.0/Postgres7.0.2 successfully as far as
pg_dump database_name is concerned.
I am still running BOTH versions on two computers.
PostgreSQL6.5 does not produce any error using math function "integer
(float_expression)"
(
On Tue, Apr 03, 2001 at 11:19:04PM +, Thomas Lockhart wrote:
> > I saw three separate reports of successful builds on Linux 2.4.2 on x86
> > (including mine), but it isn't listed here.
>
> It is listed in the comments in the real docs. At least one report was
> for an extensively patched 2.4.
> I saw three separate reports of successful builds on Linux 2.4.2 on x86
> (including mine), but it isn't listed here.
It is listed in the comments in the real docs. At least one report was
for an extensively patched 2.4.2, and I'm not sure of the true lineage
of the others.
I *could* remove th
On Mon, 2 Apr 2001, Karel Zak wrote:
> > A couple of weeks ago I received an email from Albert Langer inquiring
> > about the status of the python language module I had written for
> > postgresql. I told him I could have the port to postgresql 7.1 done
> > by the middle of this week (march 25-31
Ok, I believe the postgres.h and all the files in the include/utils
directory need to be copied over during the installation, it got most of
the others, but missed those ones and as I've spent a good chunk trying to
get PHP and a few other utils built, they kinda needed them.
7.1 release candida
On Tue, Apr 03, 2001 at 03:31:25PM +, Thomas Lockhart wrote:
>
> OK. So we are close to a final tally of supported machines.
> ...
> Here are the up-to-date platforms:
>
> AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold
> BeOS 5.0.4 x86 7.1 2000-12-18, Cyril Velter
> BSDI 4.01 x86
On Tue, Apr 03, 2001 at 03:34:51PM -0400, Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
>
> > We really need ALTER TABLE ADD CONSTRAINT for PK.
>
> That would be a cleaner way to do it, all right ... but for now, you can
> just reach in and set the indisprimary flag in pg_index aft
At 14:33 3/04/01 -0400, Tom Lane wrote:
>I notice that pg_dump now dumps primary-key indexes in the style
>
>CREATE TABLE ... (
> "dest_index" integer DEFAULT ...,
> Constraint "dest_addresses_pkey" Primary Key ("dest_index")
>);
>
>Isn't this pretty darn stupid?
Yep.
>Previously, we
Philip Warner <[EMAIL PROTECTED]> writes:
> At 14:33 3/04/01 -0400, Tom Lane wrote:
>> I notice that pg_dump now dumps primary-key indexes in the style
>>
>> CREATE TABLE ... (
>> "dest_index" integer DEFAULT ...,
>> Constraint "dest_addresses_pkey" Primary Key ("dest_index")
>> );
> My 7.0 dump
I notice that pg_dump now dumps primary-key indexes in the style
CREATE TABLE ... (
"dest_index" integer DEFAULT ...,
Constraint "dest_addresses_pkey" Primary Key ("dest_index")
);
...
COPY ... FROM stdin;
-- load data
\.
-- create other indexes for table
Isn't this pretty da
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Not sure how to test the "implicit time zone" feature of "TIME WITH TIME
> ZONE" without risking the same kinds of trouble. Maybe the test should
> be recast to using only comparisons with other date/time types which
> have been shown to behave themsel
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Hmm. Maybe the WAL redo is messing things up??
> It could mess up pg_class content, but it never deletes
> files (currently).
I'm not convinced that any files have really been deleted. Maybe it's
just that the pg_class entries are wrong, or even
> > How much time passed after sequence creation till crash?
> >>
> >> About 5-10 seconds. I opened a transaction, created a sequence,
> >> created a temporary table with one column having NEXTVAL(seq) as
> > ^
> >> default, inserted some data into the table, committed t
> Thoughts?
Besides "Thomas is an idiot"? :)
Not sure how to test the "implicit time zone" feature of "TIME WITH TIME
ZONE" without risking the same kinds of trouble. Maybe the test should
be recast to using only comparisons with other date/time types which
have been shown to behave themselves a
OK,
I compiled postgresql RC2. I have not error nor warnings so I hope it's all
right.
I also changed something in os.h --> port/qnx4.h
and in s_lock.c
I will post the changes until the end of the week.
I executed initdb and all works fine.
I executed postmaster and the proces run OK.
When I ru
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Some more input from Konstantin (his answer to my message bounced
> from bug-list -:)):
> How much time passed after sequence creation till crash?
>>
>> About 5-10 seconds. I opened a transaction, created a sequence,
>> created a temporary table wit
Hi all...
I just installed 7.1RC1 on an sun enterprise 250 runnning debian 2.2r2
linux and everything went ok..
I compiled with --enable-local and --with-java among other but it seems
that the ja created doesn't like international characters. I use the
postgresql.jar found in /usr/local/postgre
> Hm, that sounds like some sort of conflict with a temp table. Is it
> possible that you have been using a temp table name that matches the
> sequence name? Are there any pg_class entries whose names begin with
> pg_temp, and if so could we see details on those too?
Some more input from Konsta
>
> I just ran the "make check" (paralell regression tests) - instead of the
> "make installcheck" that I'd run previously...
>
> [nobody@web-cache regress]$ grep 'FAILED' regression.out
> test geometry ... FAILED
> test horology ... FAILED
>
> The relevant diff for horolog
On Tue, 3 Apr 2001, Thomas Lockhart wrote:
[Snip]
> Linux 2.0.x MIPS 7.1 2001-03-30, Dominic Eidson
I just ran the "make check" (paralell regression tests) - instead of the
"make installcheck" that I'd run previously...
[nobody@web-cache regress]$ grep 'FAILED' regression.out
test geometry
Hi,
we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
have
HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
code is included for long ints and typename calls *abort*. I put in a
few lines that check for HAVE_LONG_INT_64 and seem to generate the ri
> > mklinux has failed Tatsuo's testing afaicr. Demote to unsupported?
> Yes. But you'd better to change mklinux -> MkLinux DR1. There may be
> a chance that latest MkLinux or gcc successfully runs 7.1...
OK. So we are close to a final tally of supported machines. The
"unsupported machines" are
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> If we made the scanner aware of integers larger than int4, we would have
> to choose between int8 (not supported on all platforms, but mostly OK)
> and numeric, which is markedly slower to process and handle. I recall
> that Tom Lane had the proposal t
> The problem is that there is not a clean hierarchy of SQL types, but for
> many cases one could either convert the operands to int4 or float8 and
> then numeric(?) and then convert back. At least the conversion operators
> check for overflow, which is better than the current situation. And
> pre
Philip Warner <[EMAIL PROTECTED]> writes:
> I think it needs to dump ONLY the overridden settigns, since a change to
> the overriding behaviour of a child seems like a bad thing.
I was about to say it's not worth the trouble, but I see you already
did it ...
regards, tom
At 12:04 3/04/01 +0200, Zeugswetter Andreas SB wrote:
>
>> will get dumped as:
>>
>> CREATE TABLE "c5" (
>> "f1" integer NOT NULL,
>> "f3" integer
>> )
>> inherits ("p3_def1");
>
>As an aside answer without considerable importance:
>
>Why do people tend to write SQL ke
Thus spake Zeugswetter Andreas SB
> > will get dumped as:
> >
> > CREATE TABLE "c5" (
> > "f1" integer NOT NULL,
> > "f3" integer
> > )
> > inherits ("p3_def1");
>
> As an aside answer without considerable importance:
>
> Why do people tend to write SQL keywords in a
> Unreported or problem platforms:
>
> Linux 2.0.x MIPS 7.0 2000-04-13 (Tatsuo has lost machine)
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> NetBSD m68k7.0 2000-04-10 (Henry has lost machine)
> NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
> QNX 4.25 x86 7.0 2000-04-
> will get dumped as:
>
> CREATE TABLE "c5" (
> "f1" integer NOT NULL,
> "f3" integer
> )
> inherits ("p3_def1");
As an aside answer without considerable importance:
Why do people tend to write SQL keywords in all capitals ?
PostgreSQL converts everything to lower c
At 23:57 2/04/01 -0400, Tom Lane wrote:
>
>NOT NULL on a child field would only force it to be dumped if none
>of the parents say NOT NULL. Type name really is not an issue since
>it will have to be the same in all the tables anyway; I wouldn't bother
>expending any code there.
>
Done & applied
31 matches
Mail list logo
