Hi,
In response to comments made here, I have been rewriting the unsigned
types as externally loadable. Using the same routines that worked fine
when linked statically into the backend gives me core-dumps only.
Creating only a single uint2 type with I/O routines, I get
test=# create
On Sat, Mar 31, 2001 at 11:45:13PM -0500, Andrew Bosma wrote:
Hello all
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
Hi all
As I posted few days ago I started checking
postgresql 7.1RC1 in QNX 4.25. The last I checked was 7.1b3.
the problem is :
whenI execute configure it recognize the
executable suffix as .map and this is not right. And the test program
fails.
If I try the same in 7.1b3 all works
will still get into v7.1 *nod*
On Mon, 2 Apr 2001, Michael Meskes wrote:
Will current CVS commits make it into 7.1? Or do I have to use a different
branch. I just committed a minor patch to keep the parsers in sync and also
committed a bug fix last week. Both should be in 7.1.
Michael
--
Adriaan Joubert [EMAIL PROTECTED] writes:
In response to comments made here, I have been rewriting the unsigned
types as externally loadable. Using the same routines that worked fine
when linked statically into the backend gives me core-dumps only.
Seems unlikely that that code could
Patch applied, with wording modifications by Tom Lane.
Hi
Regarding my previous post, I just successfully created a unique index on
pg_shadow. DON'T DO THIS!!!
---
CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename)
---
I couldn't create at pg_shadow_index as the
Bruce Momjian writes:
+ elog(ERROR, "You can not create indexes on system tables: %s'",
+heapRelationName);
One of these days we should decide on a spelling of "indexes" vs
"indices".
--
Peter Eisentraut [EMAIL PROTECTED]
Bruce Momjian writes:
+ elog(ERROR, "You can not create indexes on system tables: %s'",
+heapRelationName);
One of these days we should decide on a spelling of "indexes" vs
"indices".
Yes. Added to TODO:
* Decide on spelling of
Binaries for PostgreSQL 7.1 RC1 are now available in
ftp://ftp.postgresql.org/pub/binary/v7.1/IRIX_6.5.7/
All regression tests pass except that geometry is different
by very small amounts ( 10^14) and join gives the same rows in
a different order.
While thinking over Jeremy Radlow's recent problem report in
pgsql-general, it occurs to me that it's probably wrong to implement
referential integrity actions like ON CASCADE DELETE in AFTER triggers.
Seems to me that this breaks the fundamental rule of referential
integrity: if B references A
Tom Lane writes:
Well, we *do* have a syntax for specifying a new default (the same one
that worked pre-7.0 and does now again). I guess what you are proposing
is the rule "If conflicting default values are inherited from multiple
parents that each define the same column name, then an error
I have updated HISTORY/release.sgml to contain the most recent changes
for 7.1.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.
While thinking over Jeremy Radlow's recent problem report in
pgsql-general, it occurs to me that it's probably wrong to implement
referential integrity actions like ON CASCADE DELETE in AFTER triggers.
Seems to me that this breaks the fundamental rule of referential
integrity: if B
On Sun, Apr 01, 2001 at 03:15:56PM -0400, Tom Lane wrote:
Christopher Masto [EMAIL PROTECTED] writes:
Another thing that seems kind of interesting would be to have:
CREATE TABLE base (table_id CHAR(8) NOT NULL [, etc.]);
CREATE TABLE foo (table_id CHAR(8) NOT NULL DEFAULT 'foo');
CREATE
On Mon, Apr 02, 2001 at 01:27:06PM -0400, Tom Lane wrote:
Philip: the rule that pg_dump needs to apply w.r.t. defaults for
inherited fields is that if an inherited field has a default and
either (a) no parent table supplies a default, or (b) any parent
table supplies a default different from
[EMAIL PROTECTED] (Nathan Myers) writes:
On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
That is:
create table p1 (f1 int default 1);
create table p2 (f1 int default 2);
create table c1 (f2 float) inherits(p1, p2); # XXX
would draw an error about conflicting defaults for
At 13:27 2/04/01 -0400, Tom Lane wrote:
Philip: the rule that pg_dump needs to apply w.r.t. defaults for
inherited fields is that if an inherited field has a default and
either (a) no parent table supplies a default, or (b) any parent
table supplies a default different from the child's, then
Philip Warner [EMAIL PROTECTED] writes:
At 13:27 2/04/01 -0400, Tom Lane wrote:
Philip: the rule that pg_dump needs to apply w.r.t. defaults for
inherited fields is that if an inherited field has a default and
either (a) no parent table supplies a default, or (b) any parent
table supplies a
Do we have any supported platforms where dereferencing a null pointer
doesn't trigger coredump?
I'm wondering about this after noticing the likely side effects of
fd.c's failure to check for null result from malloc(): it'll try to
strcpy() filenames to location zero. If it succeeds, you could
Tom Lane wrote:
Seems unlikely that that code could have worked either way, since you
forgot to mark type uint2 as PASSEDBYVALUE...
Aargh! Thanks! Yes, when implementing it in the backend, that was just a
field to fill in, so I did it there. All seems well now.
One ends up with a vast
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.
I've made tha
21 matches
Mail list logo
