Re: [HACKERS] TODO list comments

2005-08-26 Thread Bruce Momjian
Great updates! Let me comment on each one. I made a pass over the TODO list to see what was out of date. * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM Currently SIGTERM of a backend can lead to lock table corruption.

Re: [HACKERS] TODO list comments

2005-08-26 Thread Bruce Momjian
Alvaro Herrera wrote: On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote: Tom Lane asked: o Improve psql's handling of multi-line queries Uh, what's wrong with it? This item seems far too vague. I think perhaps this means adding multi-line support to

Re: [HACKERS] TODO list comments

2005-08-26 Thread Bruce Momjian
Hannu Krosing wrote: On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote: * %Allow TRUNCATE ... CASCADE/RESTRICT Huh? What would that do? Maybe this was meant truncating of tables with dependent foreign keys ? AFAIR this was solved by allowing truncating several tables in one command

Re: [HACKERS] TODO list comments

2005-08-26 Thread Bruce Momjian
Jim C. Nasby wrote: I *think* this is reffering to how pg_dump makes some assumptions about what things are system objects. http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php doesn't help a heck of a lot... Can we add an interface to the TODO list that contains search

Re: [HACKERS] TODO list comments

2005-08-26 Thread Bruce Momjian
Andrew Dunstan wrote: Tom Lane wrote: Or perhaps use a different separator: junk=# select * from xyz; id |name| address | del_addr ++---+-- 1 | Joe Bloggs

Re: [HACKERS] TODO list comments

2005-08-26 Thread Jim C. Nasby
On Fri, Aug 26, 2005 at 03:44:18PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: I *think* this is reffering to how pg_dump makes some assumptions about what things are system objects. http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php doesn't help a heck of a

Re: [HACKERS] TODO list comments

2005-08-25 Thread Michael Glaesemann
On Aug 25, 2005, at 10:58 AM, Tom Lane wrote: * %Remove CREATE CONSTRAINT TRIGGER This was used in older releases to dump referential integrity constraints. Do we really want to remove it, and thereby guarantee we can't load dumps from those old releases? Also, I believe CONSTRAINT

Re: [HACKERS] TODO list comments

2005-08-25 Thread Hannu Krosing
On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote: * %Allow TRUNCATE ... CASCADE/RESTRICT Huh? What would that do? Maybe this was meant truncating of tables with dependent foreign keys ? AFAIR this was solved by allowing truncating several tables in one command even if they have FK

Re: [HACKERS] TODO list comments

2005-08-25 Thread Robert Treat
On Wed, 2005-08-24 at 21:58, Tom Lane wrote: o Add pg_dumpall custom format dumps. This is probably best done by combining pg_dump and pg_dumpall into a single binary. This is probably obsoleted by events, too. Now that we can dump blobs in text mode, I see no reason

Re: [HACKERS] TODO list comments

2005-08-25 Thread Matt Miller
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote: * %Remove CREATE CONSTRAINT TRIGGER Do we really want to remove it, Also, I believe CONSTRAINT TRIGGERS are the only way to provide transaction level (rather than statement level) referential integrity. Don't deferrable

Re: [HACKERS] TODO list comments

2005-08-25 Thread Alvaro Herrera
On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote: Tom Lane asked: o Improve psql's handling of multi-line queries Uh, what's wrong with it? This item seems far too vague. I think perhaps this means adding multi-line support to the tab-completion? Only thing

Re: [HACKERS] TODO list comments

2005-08-25 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane asked: o Improve psql's handling of multi-line queries Uh, what's wrong with it? This item seems far too vague. I think perhaps this means adding multi-line support to the tab-completion? Only thing I can think of, cause other

Re: [HACKERS] TODO list comments

2005-08-25 Thread Tom Lane
Oliver Elphick olly@lfix.co.uk writes: It would be better to show the columns aligned (perhaps without showing separators for other columns so as not to give the impression that the other columns contain null or empty strings): junk=# select * from xyz; id |name|

Re: [HACKERS] TODO list comments

2005-08-25 Thread Andrew Dunstan
Tom Lane wrote: Or perhaps use a different separator: junk=# select * from xyz; id |name| address | del_addr ++---+-- 1 | Joe Bloggs | 1 Hindhead Villas,

Re: [HACKERS] TODO list comments

2005-08-25 Thread Jim C. Nasby
On Wed, Aug 24, 2005 at 09:58:04PM -0400, Tom Lane wrote: * %Allow RULE recompilation Eh? Perhaps you meant automatically regenerate cached plans when needed, in which case it's redundant with the Dependency Checking entries. Whatever it means, this doesn't seem a particularly simple

Re: [HACKERS] TODO list comments

2005-08-25 Thread Michael Glaesemann
On Aug 25, 2005, at 11:29 PM, Matt Miller wrote: On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote: * %Remove CREATE CONSTRAINT TRIGGER Do we really want to remove it, Also, I believe CONSTRAINT TRIGGERS are the only way to provide transaction level (rather than statement

[HACKERS] TODO list comments

2005-08-24 Thread Tom Lane
I made a pass over the TODO list to see what was out of date. * Allow administrators to safely terminate individual sessions either via an SQL function or SIGTERM Currently SIGTERM of a backend can lead to lock table corruption. This comment may be out of date. Suggest Lock

Re: [HACKERS] TODO list comments

2005-08-24 Thread Kris Jurka
On Wed, 24 Aug 2005, Tom Lane wrote: * Fetch heap pages matching index entries in sequential order Rather than randomly accessing heap pages based on index entries, mark heap pages needing access in a bitmap and do the lookups in sequential order. Another method would be to sort heap

Re: [HACKERS] TODO list comments

2005-08-24 Thread Tom Lane
Kris Jurka [EMAIL PROTECTED] writes: On Wed, 24 Aug 2005, Tom Lane wrote: This is done (see bitmap index scans). Will the optimizer ever choose this plan when dealing with only one index? Certainly. It's actually likely to prefer a bitmap scan whenever the query is estimated to fetch more