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 to
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 case
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-01,
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 all capitals ?
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 keywords in all
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
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 to use
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
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
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
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 horology seem
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
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
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
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 dumps PK in table
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 after
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 7.1
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
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).
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.2, and
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
21 matches
Mail list logo
