[HACKERS] Fw: Problem with plpgsql functions and foreign key constraints.

2001-05-23 Thread Brian Hirt
I forgot to mention that this is happening on 7.0.3and 7.1.1 -- and I'm running on a RedHat 7.0 machine. - Original Message - From: "Brian Hirt" <[EMAIL PROTECTED]> To: "Postgres Hackers" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, June 24, 2001 1:12 AM Subject: Problem wit

RE: [HACKERS] ADD/DROP CONSTRAINT and inheritance

2001-05-23 Thread Stephan Szabo
> > Seems like a bad idea to > > me. But as long as the default is to propagate these changes, I'm not > > really eager to prohibit DBAs from doing the other. Who's to say what's > > a misuse of inheritance and what's not... > > At the moment we have: > > * ADD CONSTRAINT does not propagate >

Re: [HACKERS] More pgindent follies

2001-05-23 Thread Tom Lane
[EMAIL PROTECTED] (Nathan Myers) writes: > This is good news! > Maybe this process can be formalized. That is, each official release > migh contain a source file with various "modern" constructs which we > suspect might break old compilers. I have no objection to this, if the process *is* for

Re: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Tom Lane
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Unless we want to abandon MVCC (which I don't), I think an overwriting >> smgr is impractical. > Impractical ? Oracle does it. Oracle has MVCC? regards, tom lane ---(end of broadcast

Re: [HACKERS] ADD/DROP CONSTRAINT and inheritance

2001-05-23 Thread Tom Lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I'm not sure what you mean here, Tom - I meant that the ONLY keyword could > be optional. The current gram.y code allows either ALTER TABLE foo ONLY or ALTER TABLE foo* for all forms of ALTER ... with the default interpretation being the lat

[HACKERS] Rtree; cannot create index on polygons with lots of points

2001-05-23 Thread Dave Blasby
I'm trying to form an rtree index on a custom datatype, and I've come across a problem. The problem also affects the standard geometric datatypes. Here's a simple example: > create table test_geom (poly polygon); > insert into test_geom values ( ''); (...) So far, so good, but when you try

[HACKERS] Re: [COMMITTERS] pgsql/src/bin/scripts Makefile createlang.sh

2001-05-23 Thread Tom Lane
Peter Eisentraut - PostgreSQL <[EMAIL PROTECTED]> writes: > Make createlang use dynamic loader enhancements (automatic path and suffix). I observe that createlang still builds full paths for me. Evidently this is because I have PGLIB set in my environment. I propose that createlang ought

Re: [HACKERS] Fix for tablename in targetlist

2001-05-23 Thread Michael Samuel
On Sat, May 19, 2001 at 10:50:31AM -0400, Tom Lane wrote: > I had a thought this morning that raising an error may be the wrong > thing to do. We could instead choose to expand the name into > "pg_class.*", which would take only a little more code and would > arguably do something useful instead

Re: [HACKERS] C++ Headers

2001-05-23 Thread Nathan Myers
On Wed, May 23, 2001 at 11:35:31AM -0400, Bruce Momjian wrote: > > > > > We have added more const-ness to libpq++ for 7.2. > > > > > > > > Breaking link compatibility without bumping the major version number > > > > on the library seems to me serious no-no. > > > > > > > > To const-ify member fu

Re: [HACKERS] More pgindent follies

2001-05-23 Thread Nathan Myers
On Wed, May 23, 2001 at 11:58:51AM -0400, Bruce Momjian wrote: > > > I don't see the problem here. My assumption is that the comment is not > > > part of the define, right? > > > > Well, that's the question. ANSI C requires comments to be replaced by > > whitespace before preprocessor commands

Re: [HACKERS] More pgindent follies

2001-05-23 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I agree, but in a certain sense, we would have found those compilers > already. This is not new behavour as far as I know, and clearly this > would throw a compiler error. [ Digs around ... ] OK, you're right, it's not new behavior; we have instances

Re: [HACKERS] Re: BSD gettext

2001-05-23 Thread pgsql-hackers
On Wed, May 23, 2001 at 10:55:35AM +0300, Alessio Bragadini wrote: > Peter Eisentraut wrote: > > > This is a compilation of the BSD-licensed gettext tools from NetBSD plus > > some of my own code, put into a (hopefully) portable package, intended to > > be evaluated for possible use in PostgreSQL

Re: [HACKERS] Not released yet, but could someone take a quick peak ...

2001-05-23 Thread Tom Lane
The Hermit Hacker <[EMAIL PROTECTED]> writes: > which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there > newer along that tree that we need to generate? I think there are some doc fixes in the REL7_1 branch, so generating from the end of that branch would be nicest. Real quest

Re: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Tom Lane
Hiroshi Inoue <[EMAIL PROTECTED]> writes: >> I guess that is the question. Are we heading for an overwriting storage >> manager? > I've never heard that it was given up. So there seems to be > at least a possibility to introduce it in the future. Unless we want to abandon MVCC (which I don't),

Re: [HACKERS] select ... for update and inheritence

2001-05-23 Thread Tom Lane
Stephen Deasey <[EMAIL PROTECTED]> writes: > set_inherited_rel_pathlist in src/backend/path/allpaths.c says: > /* > * XXX for now, can't handle inherited expansion of FOR UPDATE; can we > * do better? > */ > Is this a terribly difficult thing to implement? It might be as easy as adding t

Re: [HACKERS] XMAX weirdness (was: Plans for solving the VACUUM problem)

2001-05-23 Thread Tom Lane
Hannu Krosing <[EMAIL PROTECTED]> writes: > but then no xmax should ever be visible in a regular query : Not so. For example, if a transaction tried to delete a tuple, but is either still open or rolled back, then other transactions would see its XID in the tuple's xmax. Also, SELECT FOR UPDATE

Re: [HACKERS] ADD/DROP CONSTRAINT and inheritance

2001-05-23 Thread Tom Lane
Stephan Szabo <[EMAIL PROTECTED]> writes: > On Wed, 23 May 2001, Christopher Kings-Lynne wrote: >> For the add/drop constraint clauses would it be an idea to change the syntax >> to: >> >> ALTER TABLE [ ONLY ] x ADD CONSTRAINT x; >> ALTER TABLE [ ONLY ] x DROP CONSTRAINT x; If the patch is coded

Re: [HACKERS] Not released yet, but could someone take a quick peak...

2001-05-23 Thread Vince Vielhaber
On Wed, 23 May 2001, The Hermit Hacker wrote: > > all mirrors use rsync to update their code, and all of those that are > listed at www.postgresql.org, both ftp and www, are no more then 2 days > old (Vince, it is two days we set it at, right?) ... Yup. > > > On Wed, 23 May 2001, bpalmer wrote:

Re: [HACKERS] Not released yet, but could someone take a quick peak ...

2001-05-23 Thread Tom Lane
The Hermit Hacker <[EMAIL PROTECTED]> writes: > ftp://ftp.postgresql.org/pub/source/v7.1.2 ... > Just want a second opinion before I announce more publicly ... Looks OK from here except for the problem Peter already noted: the tarred-up doc files were created from development tip, not 7.1 branch.

Re: [HACKERS] Not released yet, but could someone take a quick peak...

2001-05-23 Thread The Hermit Hacker
all mirrors use rsync to update their code, and all of those that are listed at www.postgresql.org, both ftp and www, are no more then 2 days old (Vince, it is two days we set it at, right?) ... On Wed, 23 May 2001, bpalmer wrote: > On Wed, 23 May 2001, Tom Lane wrote: > > > every time I've tr

Re: [HACKERS] Not released yet, but could someone take a quick peak...

2001-05-23 Thread The Hermit Hacker
which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there newer along that tree that we need to generate? On Tue, 22 May 2001, Peter Eisentraut wrote: > The Hermit Hacker writes: > > > ftp://ftp.postgresql.org/pub/source/v7.1.2 ... > > > > Just want a second opinion before I ann

Re: [HACKERS] SEP_CHAR

2001-05-23 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I see it used by psql and pg_dump and I will leave them alone, assuming > / is not hardeded elsewhere in that code. If you're gonna take it out, take it out completely. regards, tom lane ---(end of broad

Re: [HACKERS]

2001-05-23 Thread Tom Lane
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Has this been already fixed or reported? > test-# \dz > Did not find any relation named "z". > Segmentation fault (core dumped) Yes, this is fixed in 7.1.2. regards, tom lane ---(end of broadcast)---

Re: [HACKERS] ADD/DROP CONSTRAINT and inheritance

2001-05-23 Thread Stephan Szabo
On Wed, 23 May 2001, Christopher Kings-Lynne wrote: > For the add/drop constraint clauses would it be an idea to change the syntax > to: > > ALTER TABLE [ ONLY ] x ADD CONSTRAINT x; > ALTER TABLE [ ONLY ] x DROP CONSTRAINT x; > > So that people can specify whether the constraint should be inher

Re: [HACKERS] Not released yet, but could someone take a quick peak ...

2001-05-23 Thread Tom Lane
The Hermit Hacker <[EMAIL PROTECTED]> writes: >> I'd check. But the postgresql ftp site appears to be broken for the past >> few days. > > broken how? I just connected into it ... Maybe you did, but no one else can. ftp.postgresql.org has said 530-The maximum number of concurrent conne

Re: [HACKERS] SEP_CHAR

2001-05-23 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Bruce Momjian writes: >> I see some use of SEP_CHAR for '/' in the source. Do we want to use it >> consistenly, or not use it at all? I can make the change. > I vote for not at all, since there is not at all a use for it. If it's not actually need

[HACKERS] miswording in pg_dump

2001-05-23 Thread Vince Vielhaber
pg_dump's help provides this near the bottom: If no database name is not supplied, then the PGDATABASE environment variable value is used. Shouldn't that read: If no database name is supplied, then the PGDATABASE environment variable value is used. or: If the database name is not supplied, t

Re: [HACKERS] More pgindent follies

2001-05-23 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: >> 4. This breaking of a comment attached to a #define scares me. >> >> *** >> *** 1691,1705 >> >> #define FIXED_CHAR_SEL 0.04/* about 1/25 */ >> #define CHAR_RANGE_SEL 0.25 >> ! #define ANY_CHAR_SEL 0.9

AW: AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Zeugswetter Andreas SB
> - A simple typo in psql can currently cause a forced rollback of the entire > TX. UNDO should avoid this. Yes, I forgot to mention this very big advantage, but undo is not the only possible way to implement savepoints. Solutions using CommandCounter have been discussed. Although the pg_log m

Re: AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Philip Warner
At 11:25 23/05/01 +0200, Zeugswetter Andreas SB wrote: > >> >If community will not like UNDO then I'll probably try to implement >> >dead space collector which will read log files and so on. >> >> I'd vote for UNDO; in terms of usability & friendliness it's a big win. > >Could you please try it

[HACKERS] select ... for update and inheritence

2001-05-23 Thread Stephen Deasey
set_inherited_rel_pathlist in src/backend/path/allpaths.c says: /* * XXX for now, can't handle inherited expansion of FOR UPDATE; can we * do better? */ Is this a terribly difficult thing to implement? The RI triggers use FOR UPDATE which makes RI impossible with inheritence hierarchies

AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Zeugswetter Andreas SB
> >If community will not like UNDO then I'll probably try to implement > >dead space collector which will read log files and so on. > > I'd vote for UNDO; in terms of usability & friendliness it's a big win. Could you please try it a little more verbose ? I am very interested in the advantage

RE: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Philip Warner
At 14:33 22/05/01 -0700, Mikheev, Vadim wrote: > >If community will not like UNDO then I'll probably try to implement >dead space collector which will read log files and so on. I'd vote for UNDO; in terms of usability & friendliness it's a big win. Tom's plans for FSM etc are, at least, going to

AW: AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Zeugswetter Andreas SB
> > The downside would only be, that long running txn's cannot > > [easily] rollback to savepoint. > > We should implement savepoints for all or none transactions, no? We should not limit transaction size to online available disk space for WAL. Imho that is much more important. With guaranteed

AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Zeugswetter Andreas SB
> > People also have referred to an overwriting smgr > > easily. Please tell me how to introduce an overwriting smgr > > without UNDO. There is no way. Although undo for an overwriting smgr would involve a very different approach than with non-overwriting. See Vadim's post about what info suffic

AW: [HACKERS] Plans for solving the VACUUM problem

2001-05-23 Thread Zeugswetter Andreas SB
> If community will not like UNDO then I'll probably try to implement Imho UNDO would be great under the following circumstances: 1. The undo is only registered for some background work process and not done in the client's backend (or only if it is a small txn). 2. Th