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 c
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
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 en
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 s
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
[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 de
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 fr
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');
On Sat, Mar 31, 2001 at 07:44:30PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> >> This seems pretty random. It would be more reasonable if multiple
> >> (default) inheritance weren't allowed unless you explicitly specify a new
> >> default for the new column, but we don't
> 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 refer
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.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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
Tom Lane wrote:
> [Dept of swatting flies with sledgehammers]
> I'd say that the use of "index" in database work clearly falls under
> sense 5b, and so "indexes" is the usual plural according to the OED.
As a volume of the OED is about the weight of a small sledgehammer, that
fly is one dead pupp
> 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 refe
> [Dept of swatting flies with sledgehammers]
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > One of these days we should decide on a spelling of "indexes" vs
> > "indices".
>
> I'd vote for "indexes", first on the practical grounds that it's a more
> sensible spelling, and secondly on the
[Dept of swatting flies with sledgehammers]
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> One of these days we should decide on a spelling of "indexes" vs
> "indices".
I'd vote for "indexes", first on the practical grounds that it's a more
sensible spelling, and secondly on the grounds that the
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 er
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 th
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.
+--+--
> 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
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] http://yi.org/pete
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_shado
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 coul
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
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 :
when I 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
g
* Michael Meskes <[EMAIL PROTECTED]> [010402 04:41] 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.
You should be able to check
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 th
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
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linu
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 tabl
29 matches
Mail list logo
