Re: [HACKERS] Re: Changing the default value of an inherited column
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 CVS. Only dumps changed info, so:
create table p3_def1(f1 int default 1, f2 int);
create table c5(f1 int not null, f3 int) inherits(p3_def1);
will get dumped as:
CREATE TABLE "c5" (
"f1" integer NOT NULL,
"f3" integer
)
inherits ("p3_def1");
ie. without the DEFAULT.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
Http://www.rhyme.com.au |/ \|
|----
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] capitalized sql (was: Re: Changing the default value of an inherited column)
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 (which I like).
So why not output lowercase ? Above example even mixes
case, why ?
Andreas
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Third call for platform testing
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, Dr. Andreas Kardos Ultrix MIPS7.1 2001-??-??, Alexander Klimov 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... Any NetBSD partisans who can do testing or solicit testing from the NetBSD crowd? Same for OpenBSD? QNX is known to have problems with 7.1. Any hope of fixing for 7.1.1? Is there anyone able to work on it? If not, I'll move to the unsupported list. And here are the up-to-date platforms; thanks for the reports: AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner FreeBSD 4.3 x867.1 2001-03-19, Vince Vielhaber HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman NetBSD 1.5 alpha 7.1 2001-03-22, Giles Lean NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD 1.5S x867.1 2001-03-21, Patrick Welche OpenBSD 2.8 x867.1 2001-03-22, Brandon Palmer SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier Solaris x867.1 2001-03-27, Mathijs Brands SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only) WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] capitalized sql (was: Re: Changing the default valu eof an inherited column)
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 ?
PostgreSQL converts everything to lower case (which I like).
So why not output lowercase ? Above example even mixes
case, why ?
I do it for maintenance purposes. All of my code uses caps for keywords
so that I can find them without getting them confused with language
constructs and variables.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] capitalized sql (was: Re: Changing the default value of an inherited column)
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 capitals ?
It's just one of those things that people do; some people find it easier to
read (I actually prefer proper case keywords for SQL, unquoted upper case
for names etc):
Create Table C5 (
F1 Integer Not Null,
F3 Integer
)
Inherits (P3_DEF1);
As to why it's in pg_dump, I think it reflects the many varied
contributors as opposed to careful design. There is some proper-case stuff
in there now (from me), which I will try to remember to remove. The upper
case stuff is there since 6.x at least, and I'm not sure why INHERITS is in
lower case. Type names are now formatted (mostly) using formatType (from
Peter E), so they will at least be consistent (and lower case).
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) __---_
Tel: (+61) 0500 83 82 81 | _ \
Fax: (+61) 0500 83 82 82 | ___ |
Http://www.rhyme.com.au |/ \|
|----
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Re: Bug in user-defined types?
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 precision wise it cannot be much worse: after all, large integer constants already end up as floats. Is the SQL standard pedantic about this? Yes. The implicit "big integer" - float8 done in the scanner is an expedient hack to keep from rejecting the large number entirely, but is likely not in the spirit of the SQL standard. The Right Way would have us set the large integer string to int8 and/or numeric, but the scanner does not know about those types at the moment, mostly for historical reasons. 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 a more loosely categorized "some kind of numeric type" in the scanner, postponing the hard assignment of type to later in the parser. That might get around the performance issues, since numeric would only be used if the context required it. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Bug in user-defined types?
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 a more loosely categorized "some kind of numeric type" in the scanner, postponing the hard assignment of type to later in the parser. That might get around the performance issues, since numeric would only be used if the context required it. Yes, I was thinking of treating numerical literals more like we already treat unknown-type string literals: keep the value in string format until we deduce from context which type it should be, then convert. Internally this already happens for literals that don't fit in int4, but we still prejudge the type sooner than I think we should. IIRC, the main reason this isn't done yet was that we hadn't come to a conclusion about the appropriate type promotion hierarchy for numeric values. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Final call for platform testing
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 listed at the end, and those include QNX and Ultrix, which both may end up supported in the very near future. I've left NetBSD/m68k and NetBSD/Sparc on the supported list since we have no reason to think that they *won't* work for 7.1, but they may get bumped to unsupported if we do not have maintainers with access to working machines. That will be especially problematic for the m68k-based machines, since they are no longer in (large scale) production. I may not have correct info for SCO OpenServer. Can someone verify that 7.1 works on this platform? With the UDK compiler set, it *should* be identical wrt support to UnixWare with the same compiler set, right? If we don't get testing done, I'll revert the description to that for 7.0, but leave it as a supported platform. Since Windows (not NT) is supported on the client side only, should I move it to "unsupported"? I think I will, but leave the comments that clients have been tested. If the scorecard does not change, we are on 29 distinct platforms, the largest number we have *ever* been qualified on. And simultaneously for all on the day of release, which is simply not done in the closed source world. Thanks to everyone for the great support on porting and testing! - Thomas 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 2001-03-19, Bruce Momjian Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner FreeBSD 4.3 x867.1 2001-03-19, Vince Vielhaber HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.0.x MIPS 7.1 2001-03-30, Dominic Eidson Linux 2.2.18 PPC74xx 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman NetBSD 1.5 Alpha 7.1 2001-03-22, Giles Lean NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD m68k7.0 2000-04-10 (Henry has lost machine) NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo NetBSD VAX 7.1 2001-03-30, Tom I. Helbekkmo NetBSD 1.5 x86 7.1 2001-03-23, Giles Lean OpenBSD 2.8 Sparc 7.1 2001-03-23, Brandon Palmer OpenBSD 2.8 x867.1 2001-03-22, Brandon Palmer SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman Solaris 2.7-8 Sparc7.1 2001-03-22, Marc Fournier Solaris x867.1 2001-03-27, Mathijs Brands SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler And the "unsupported platforms": DGUX m88k MkLinux DR1 PPC750 7.0 2000-04-13, Tatsuo Ishii NextStep x86 QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos System V R4 m88k System V R4 MIPS Ultrix MIPS7.1 2001-03-26, Alexander Klimov Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] ecpg long int problem on alpha + fix
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 right
code. I've got a new version of typename.c attached. It would be good if
Michael could review and get this into 7.1.
Cheers,
Adriaan
#include "config.h"
#include stdlib.h
#include "ecpgtype.h"
#include "ecpglib.h"
#include "extern.h"
#include "sql3types.h"
#include "pg_type.h"
/*
* This function is used to generate the correct type names.
*/
const char *
ECPGtype_name(enum ECPGttype typ)
{
switch (typ)
{
case ECPGt_char:
return "char";
case ECPGt_unsigned_char:
return "unsigned char";
case ECPGt_short:
return "short";
case ECPGt_unsigned_short:
return "unsigned short";
case ECPGt_int:
return "int";
case ECPGt_unsigned_int:
return "unsigned int";
case ECPGt_long:
return "long";
case ECPGt_unsigned_long:
return "unsigned long";
#if defined(HAVE_LONG_LONG_INT_64)
case ECPGt_long_long:
return "long long";
case ECPGt_unsigned_long_long:
return "unsigned long long";
#elif defined(HAVE_LONG_INT_64)
case ECPGt_long_long:
return "long int";
case ECPGt_unsigned_long_long:
return "unsigned long int";
#endif /* HAVE_LONG_LONG_INT_64 */
case ECPGt_float:
return "float";
case ECPGt_double:
return "double";
case ECPGt_bool:
return "bool";
case ECPGt_varchar:
return "varchar";
case ECPGt_char_variable:
return "char";
default:
abort();
}
return NULL;
}
unsigned int
ECPGDynamicType(Oid type)
{
switch (type)
{
case BOOLOID:return SQL3_BOOLEAN; /* bool */
case INT2OID:
return SQL3_SMALLINT; /* int2 */
case INT4OID:
return SQL3_INTEGER;/* int4 */
case TEXTOID:
return SQL3_CHARACTER; /* text */
case FLOAT4OID:
return SQL3_REAL; /* float4 */
case FLOAT8OID:
return SQL3_DOUBLE_PRECISION; /* float8 */
case BPCHAROID:
return SQL3_CHARACTER; /* bpchar */
case VARCHAROID:
return SQL3_CHARACTER_VARYING; /* varchar */
case DATEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* date */
case TIMEOID:
return SQL3_DATE_TIME_TIMESTAMP; /* time */
case TIMESTAMPOID:
return SQL3_DATE_TIME_TIMESTAMP; /* datetime */
case NUMERICOID:
return SQL3_NUMERIC;/* numeric */
default:
return -type;
}
}
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Final call for platform testing
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 ... FAILED test horology ... FAILED The relevant diff for horology seem to be: [nobody@web-cache regress]$ diff -c ./expected/horology.out ./results/horology.out *** ./expected/horology.out Sun Dec 3 08:51:11 2000 --- ./results/horology.out Tue Apr 3 11:38:27 2001 *** *** 122,128 SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08"; 03:31:00-08 - ! 03:31:00-08 (1 row) SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08"; --- 122,128 SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08"; 03:31:00-08 - ! 03:31:00-07 (1 row) SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08"; *** *** 140,146 SELECT time with time zone '03:30' + interval '1 month 04:01' AS "07:31:00-08"; 07:31:00-08 - ! 07:31:00-08 (1 row) SELECT interval '04:30' - time with time zone '01:02' AS "+03:28"; --- 140,146 SELECT time with time zone '03:30' + interval '1 month 04:01' AS "07:31:00-08"; 07:31:00-08 - ! 07:31:00-07 (1 row) SELECT interval '04:30' - time with time zone '01:02' AS "+03:28"; Seems there's a couple of off-by-one errors on this platform (according to Marc, the same was the case for the geometry stuff...) -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Final call for platform testing
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 to be: I can't speak to the geo test failures, but the horology failures have to do with the change from daylight saving change. Since we lost an hour they will be off. Is this something to be looked at? The failure of the test is to be expected, but it will cause some to worry when their regression tests fail. Thoughts? - Brandon b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] RE: [BUGS] Loosing files after backend crash
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 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 with one column having NEXTVAL(seq) as ^ default, inserted some data into the table, committed the transaction. After that I ran my function, which crashed the backend after 3-4 seconds of work. Vadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] International characters and the jdbcdriver
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/postgresql/share/java/. When running using this one i get ? instead of for example , or . Changing to jdbc7.0-1.2.jar from an rpminstall (mandrake 7.2) made everything work just fine. Did I do something wrong or miss something? Thanks in advance! Fredrik ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ?
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 run psql template0 I have an error. I am not expert walking throu postgresql sources. could You tell me if there some change from beta 6 to RC1 or RC2 that can give this problem in QNX so I can try to check all? Attached is the server.log file with the SIGSEGV. Thanks - Original Message - From: "Peter Eisentraut" [EMAIL PROTECTED] To: "Maurizio" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, April 02, 2001 6:38 PM Subject: Re: [HACKERS] QNX : POSSIBLE BUG IN CONFIGURE ? Maurizio writes: the problem is : when I execute configure it recognize the executable suffix as .map and this is not right. And the test program fails. This is a known (to me) bug in Autoconf. Maybe there's a way to prevent the .map files to be generated? Fixing this isn't too hard, but I don't feel urgent about it when there are more problems with the QNX port still down the line. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Server.log ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump performance lossage for primary keys
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 definitions as well, AFAICT (but it may have been
patched) - can you check yours?
Ah, you are right. My mistake --- the lossage is of longer standing
than I thought.
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 creating
the index. I'm visualizing
CREATE TABLE table
( field int NOT NULL, ...);
load data
CREATE UNIQUE INDEX table_pkey ON table(field);
UPDATE pg_index SET indisprimary = true WHERE indexrelid =
(SELECT oid FROM pg_class WHERE relname = 'table_pkey');
On the other hand, that would fall over if executed by a non-superuser.
Drat. Okay, I guess we just have to leave this as a TODO item for now.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] pg_dump performance lossage for primary keys
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 creating the index. I'm visualizing snip On the other hand, that would fall over if executed by a non-superuser. Drat. Okay, I guess we just have to leave this as a TODO item for now. This is one of those 'dual roles of pg_dump' problems: Philip has been slowly migrating it from being a 'quickest possible backup dump' tool to a 'recover my db in as human friendly (and SQL standards compliant) a format as possible' tool. Which, not coincidently, has dramatically reduced the version fragility of the dump output. Adding implementation specific performance hacks back in is probably a necessary evil, but should probably be protected by a '--fastdump' switch or some such. Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Final call for platform testing
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 2001-03-19, Bruce Momjian Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner FreeBSD 4.3 x867.1 2001-03-19, Vince Vielhaber HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.0.x MIPS 7.1 2001-03-30, Dominic Eidson Linux 2.2.18 PPC74xx 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman NetBSD 1.5 Alpha 7.1 2001-03-22, Giles Lean NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD m68k7.0 2000-04-10 (Henry has lost machine) NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo NetBSD VAX 7.1 2001-03-30, Tom I. Helbekkmo NetBSD 1.5 x86 7.1 2001-03-23, Giles Lean OpenBSD 2.8 Sparc 7.1 2001-03-23, Brandon Palmer OpenBSD 2.8 x867.1 2001-03-22, Brandon Palmer SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman Solaris 2.7-8 Sparc7.1 2001-03-22, Marc Fournier Solaris x867.1 2001-03-27, Mathijs Brands SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler And the "unsupported platforms": DGUX m88k MkLinux DR1 PPC750 7.0 2000-04-13, Tatsuo Ishii NextStep x86 QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos System V R4 m88k System V R4 MIPS Ultrix MIPS7.1 2001-03-26, Alexander Klimov Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only) I saw three separate reports of successful builds on Linux 2.4.2 on x86 (including mine), but it isn't listed here. -- Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Missing include files.
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 candidate 2 has this issue. Chris Bowlby, - Web Developer @ Hub.org. [EMAIL PROTECTED] www.hub.org 1-902-542-3657 - ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: plpython for postgres 7.1
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). Well, it's the end of this week, but I've finished it. Besides the conversion to the new style function manager, I've implemented a complete SPI interface. (The 7.0 module couldn't execute saved plans.) If you are interested in experimenting with the module it is available at "http://users.ids.net/~bosma" download the link "tarball for postgresql 7.1" comments, bug reports and suggestions are appreciated. This is *great news* -- we use Python in our office for many things, and with Python embedded into the DB server, it makes our Zope-PostgreSQL connection ever tighter. I'm afraid I can't give much feedback about the code (I'm just not that familiar w/the PG internals), but, externally it seems to work great. I'm excited about the SD[] and GD[] dicts -- they're a nice addition for us. For those of you considering installing this, it was a very easy install (Linux-Madrake 7.2 (Linux 2.2.x) / Python 1.5.2). Run one diff against the PG sources, recompile, edit a Makefile for one- or two- library locations, and that's it. Worth playing with. I hope we will see it in 7.2 ... Indeed. For the deep gurus: what's the downside of adding PLs to our PG server? (Of course, adding alpha- or beta- quality PLs has clear problems, I mean when this becomes production quality). Does each new PL bloat the PG server? Does each new PL slow it down? Thanks! -- Joel Burton [EMAIL PROTECTED] Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Final call for platform testing
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 I'm not sure of the true lineage of the others. You could ask. Just to ignore reports that you have asked for is not polite. My report was based on a virgin, unpatched 2.4.2 kernel, and (as noted) the Debian-packaged glibc-2.2.2. If you are trying to trim your list, would be reasonable to drop Linux-2.0.x, because that version is not being maintained any more. I *could* remove the version info from the x86 listing, and mention both 2.2.x and 2.4.x in the comments. Linux-2.2 and Linux-2.4 are different codebases. It is worth noting, besides, the glibc-version tested along with each Linux kernel version. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Final call for platform testing
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 appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
