agora inbox for [email protected]  
help / color / mirror / Atom feed
Re: [HACKERS] Re: TODO items
46+ messages / 18 participants
[nested] [flat]

* Re: [HACKERS] Re: TODO items
@ 1999-09-29 16:28  Peter Eisentraut <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Peter Eisentraut @ 1999-09-29 16:28 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers

Just my 0.02 kronor . . .

On Sep 27, Bruce Momjian noted:

> > * Update table SET table.value = 3 fails
> > 
> > AFAICS, the SQL92 syntax allows only a bare <column name> as the
> > target of a SET clause.  Not sure it's worth expending any effort
> > on this one...
> 
> Marked now as:
> 
> 	* Update table SET table.value = 3 fails(SQL standard says this is OK)

In my opinion this should definitely _not_ be allowed. Let's be glad the
UPDATE command is so conceptually simple (cf. SELECT). The next thing they
want is ALTER TABLE foo RENAME foo.colum [ TO bar.something ??? -- moving
columns between tables, why not :) ] and then CREATE TABLE foo (foo.a int,
...); and it won't stop :)


> > MISC
> > 
> > * Do autocommit so always in a transaction block(?)
> > 
> > Huh?  What is this supposed to mean?
> 
> Some people want the SQL session to start inside a transaction, and you
> have to explicity use COMMIT, at which point you are in a new
> transaction that lasts until the next commit.  Ingres SQL does this, and
> it is a pain, I think.

I have been wondering about this, too. Oracle does this as well. This is
also how they taught me SQL in university, so it is probably not out of
the blue. What do the standards say?

Then again, while I think that client programmers won't die if they type
an extra BEGIN here or there, this might be useful as a psql feature. Too
many times I've seen people type DELETE FROM <table>; by accident.

What do y'all think? (Besides the fact that this might be a pain to
implement.)


Peter

-- 
Peter Eisentraut - [email protected]
http://yi.org/peter-e




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: [HACKERS] Re: TODO items
@ 1999-09-29 17:21  Bruce Momjian <[email protected]>
  parent: Peter Eisentraut <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 1999-09-29 17:21 UTC (permalink / raw)
  To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers

> Just my 0.02 kronor . . .
> 
> On Sep 27, Bruce Momjian noted:
> 
> > > * Update table SET table.value = 3 fails
> > > 
> > > AFAICS, the SQL92 syntax allows only a bare <column name> as the
> > > target of a SET clause.  Not sure it's worth expending any effort
> > > on this one...
> > 
> > Marked now as:
> > 
> > 	* Update table SET table.value = 3 fails(SQL standard says this is OK)
> 
> In my opinion this should definitely _not_ be allowed. Let's be glad the
> UPDATE command is so conceptually simple (cf. SELECT). The next thing they
> want is ALTER TABLE foo RENAME foo.colum [ TO bar.something ??? -- moving
> columns between tables, why not :) ] and then CREATE TABLE foo (foo.a int,
> ...); and it won't stop :)

OK, let's leave it in so people know it is not implemented.

> > Some people want the SQL session to start inside a transaction, and you
> > have to explicity use COMMIT, at which point you are in a new
> > transaction that lasts until the next commit.  Ingres SQL does this, and
> > it is a pain, I think.
> 
> I have been wondering about this, too. Oracle does this as well. This is
> also how they taught me SQL in university, so it is probably not out of
> the blue. What do the standards say?
> 
> Then again, while I think that client programmers won't die if they type
> an extra BEGIN here or there, this might be useful as a psql feature. Too
> many times I've seen people type DELETE FROM <table>; by accident.

No one has really been passionate about it either way.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  [email protected]            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026





^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* TODO items
@ 2003-08-08 02:01  Bruce Momjian <[email protected]>
  0 siblings, 3 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 02:01 UTC (permalink / raw)
  To: pgsql-hackers

I am marking the completed TODO items.  Are these done?

	* Have standalone backend read postgresql.conf
	* Prevent whole-row references from leaking memory, e.g. SELECT
	  COUNT(tab.*)
	* Use index to restrict rows returned by multi-key index when used with
	  non-consecutive keys or OR clauses, so fewer heap accesses
	* Prevent index uniqueness checks when UPDATE does not modify the column
	* Return proper effected tuple count from complex commands [return]
	o Allow SHOW of non-modifiable variables, like pg_controldata
        o Allow array declarations and other data types in PL/PgSQL DECLARE
        o Add PL/PgSQL PROCEDURES that can return multiple values
        o Add table function support to pltcl, plperl, plpython
        o Allow PL/PgSQL to support array element assignment
	* Allow psql to do table completion for SELECT * FROM schema_part and
	  table completion for SELECT * FROM schema_name.
        o Support jdbc both 'make' and 'ant'
	* Make blind writes go through the file descriptor cache
	* Improve Subplan list handling
	* Precompile SQL functions to avoid overhead (Neil)
	* Add optional CRC checksum to heap and index pages
        o Add optional textual message to NOTIFY

The current TODO is attached with completed items marked.	

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

TODO list for PostgreSQL
========================
Last updated:		Thu Aug  7 22:00:19 EDT 2003

Current maintainer:	Bruce Momjian ([email protected])

The most recent version of this document can be viewed at
the PostgreSQL web site, http://www.PostgreSQL.org.

A dash (-) marks changes that will appear in the upcoming 7.4 release.

Bracketed items "[]" have more detailed.


Urgent
======

* Add replication of distributed databases [replication]
	o Automatic failover
	o Load balancing
	o Master/slave replication
	o Multi-master replication
	o Partition data across servers
	o Sample implementation in contrib/rserv
	o Queries across databases or servers (two-phase commit)
	o Allow replication over unreliable or non-persistent links
	o http://gborg.postgresql.org/project/pgreplication/projdisplay.php
* Point-in-time data recovery using backup and write-ahead log
* Create native Win32 port [win32]


Reporting
=========

* -Allow elog() to return error codes, module name, file name, line
  number, not just messages (Tom)
* -Add error codes (Tom)
* -Make error messages more consistent
* Show location of syntax error in query [yacc]
* -Add GUC log_statement_and_duration to print statement and >= min duration


Administration
==============

* Incremental backups
* Remove unreferenced table files and temp tables during database vacuum
  or postmaster startup (Bruce)
* Remove behavior of postmaster -o after making postmaster/postgres
  flags unique
* Allow easy display of usernames in a group
* Allow configuration files to be specified in a different directory
* -Add start time to pg_stat_activity
* Allow limits on per-db/user connections
* Have standalone backend read postgresql.conf
* Add group object ownership, so groups can rename/drop/grant on objects,
  so we can implement roles
* Add the concept of dataspaces/tablespaces [tablespaces]
* -Allow CIDR format to be used in pg_hba.conf
* Allow logging of only data definition(DDL), or DDL and modification statements
* Allow log lines to include session-level information, like database and user
* Allow server log information to be output as INSERT statements


Data Types
==========

* -Add IPv6 capability to INET/CIDR types
* Remove Money type, add money formatting for decimal type
* Change factorial to return a numeric
* -Change NUMERIC data type to use base 10,000 internally
* Change NUMERIC to enforce the maximum precision, and increase it
* Add function to return compressed length of TOAST data values (Tom)
* Allow INET subnet tests using non-constants
* Add transaction_timestamp(), statement_timestamp(), clock_timestamp() functionality
* -Add GUC variables to control floating number output digits (Pedro Ferreira)
* Have sequence dependency track use of DEFAULT sequences, seqname.nextval
* Disallow changing default expression of a SERIAL column
* Allow infinite dates just like infinite timestamps
* Allow pg_dump to dump sequences using NO_MAXVALUE and NO_MINVALUE
* Allow better handling of numeric constants, type conversion [typeconv]
* Allow backend to output result sets in XML
* Prevent whole-row references from leaking memory, e.g. SELECT COUNT(tab.*)
* -Allow current datestyle to restrict dates;  prevent month/day swapping
  from making invalid dates valid
* -Prevent month/day swapping of ISO dates to make invalid dates valid
* Have initdb set DateStyle based on locale?
* -Delay resolution of array expression type so assignment coercion 
  can be performed on empty array expressions (Joe)

* ARRAYS
	o Allow nulls in arrays
	o -Allow arrays to be ORDER'ed
	o Support construction of array result values in expressions

* BINARY DATA
	o Improve vacuum of large objects, like /contrib/vacuumlo
	o Add security checking for large objects
	o Make file in/out interface for TOAST columns, similar to large object
	  interface (force out-of-line storage and no compression)
	o Auto-delete large objects when referencing row is deleted


Multi-Language Support
======================

* Add NCHAR (as distinguished from ordinary varchar),
* Allow LOCALE on a per-column basis, default to ASCII
* Support multiple simultaneous character sets, per SQL92
* Improve Unicode combined character handling
* Optimize locale to have minimal performance impact when not used (Peter E)
* Add octet_length_server() and octet_length_client() (Thomas, Tatsuo)
* Make octet_length_client the same as octet_length() (?)
* Prevent mismatch of frontend/backend encodings from converting bytea
  data from being interpreted as encoded strings
* -Remove Cyrillic recode support

 
Views / Rules
=============

* Automatically create rules on views so they are updateable, per SQL92 [view]
* Add the functionality for WITH CHECK OPTION clause of CREATE VIEW
* Allow NOTIFY in rules involving conditionals
* Have views on temporary tables exist in the temporary namespace
* Move psql backslash information into views
* Allow RULE recompilation


Indexes
=======

* Allow CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops)
  fails index can't store constant parameters
* Order duplicate index entries by tid for faster heap lookups
* Allow inherited tables to inherit index, UNIQUE constraint, and primary
  key, foreign key  [inheritance]
* UNIQUE INDEX on base column not honored on inserts from inherited table
  INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
  [inheritance]
* Add UNIQUE capability to non-btree indexes
* Add btree index support for reltime, tinterval, regproc
* Add rtree index support for line, lseg, path, point
* -Certain indexes will not shrink, e.g. indexes on ever-increasing
  columns and indexes with many duplicate keys
* Use indexes for min() and max() or convert to SELECT col FROM tab ORDER
  BY col DESC LIMIT 1 if appropriate index exists and WHERE clause acceptible
* Allow LIKE indexing optimization for non-ASCII locales
* Use index to restrict rows returned by multi-key index when used with
  non-consecutive keys or OR clauses, so fewer heap accesses
* Be smarter about insertion of already-ordered data into btree index
* Prevent index uniqueness checks when UPDATE does not modify the column
* Use bitmaps to fetch heap pages in sequential order [performance]
* Use bitmaps to combine existing indexes [performance]
* Improve handling of index scans for NULL
* Allow SELECT * FROM tab WHERE int2col = 4 to use int2col index, int8,
  float4, numeric/decimal too [optimizer]
* Add FILLFACTOR to btree index creation
* Add concurrency to GIST
* Improve concurrency of hash indexes (Neil)
* Allow a single index to index multiple tables (for inheritance and subtables)


Commands
========

* Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
* -Allow LIMIT/OFFSET to use expressions (Tom)
* CREATE TABLE AS can not determine column lengths from expressions [atttypmod]
* Allow UPDATE to handle complex aggregates [update]
* Allow command blocks to ignore certain types of errors
* Allow backslash handling in quoted strings to be disabled for portability
* Return proper effected tuple count from complex commands [return]
* Allow UPDATE, DELETE to handle table aliases for self-joins [delete]
* Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* Allow REINDEX to rebuild all indexes, remove /contrib/reindex
* -Make a transaction-safe TRUNCATE (Rod)
* Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* Add schema option to createlang
* Allow savepoints / nested transactions [transactions] (Bruce)
* Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple columns
* -Allow UPDATE to use SET col = DEFAULT
* -Add config variable to prevent auto-adding missing FROM-clause tables
* Allow SET CONSTRAINTS to be qualified by schema/table
* -Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle
* Prevent COMMENT ON DATABASE from using a database name
* Add GUC variable to prevent waiting on locks


* ALTER
	o ALTER TABLE ADD COLUMN does not honor DEFAULT and non-CHECK CONSTRAINT
	o ALTER TABLE ADD COLUMN column DEFAULT should fill existing
	  rows with DEFAULT value
	o ALTER TABLE ADD COLUMN column SERIAL doesn't create sequence because
          of the item above
	o --Add ALTER TABLE tab SET WITHOUT OIDS (Rod)
	o -Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values
	o Have ALTER TABLE rename SERIAL sequences
	o Allow columns to be reordered using ALTER ... POSITION i col1 [,col2];
	  have SELECT * and INSERT honor such ordering
	o Allow ALTER TABLE to modify column lengths and change to binary
	  compatible types
	o Add ALTER DATABASE ... OWNER TO newowner

* CLUSTER
	o Automatically maintain clustering on a table
	o -Allow CLUSTER to cluster all tables (Alvaro Herrera)

* COPY
	o Allow dump/load of CSV format
	o Allow COPY to report error lines and continue;  optionally
	  allow error codes to be specified; requires savepoints or can
	  not be run in a multi-statement transaction
	o Allow COPY to understand \x as hex
	o Have COPY return number of rows loaded/unloaded

* CURSOR
	o Allow BINARY option to SELECT, just like DECLARE
	o -MOVE 0 should not move to end of cursor (Bruce)
	o Allow UPDATE/DELETE WHERE CURRENT OF cursor using per-cursor tid
	  stored in the backend (Gavin)
	o Prevent DROP of table being referenced by our own open cursor
	o -Allow cursors outside transactions

* INSERT
	o Allow INSERT/UPDATE of system-generated oid value for a row
	o Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
	o Allow INSERT/UPDATE ... RETURNING new.col or old.col; handle
	  RULE cases (Philip)

* SHOW/SET
	o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
	  ANALYZE, and CLUSTER
	o Add SET SCHEMA
	o -Allow EXPLAIN EXECUTE to see prepared plans
	o Allow SHOW of non-modifiable variables, like pg_controldata

* SERVER-SIDE LANGUAGES
	o Allow PL/PgSQL's RAISE function to take expressions
	o Change PL/PgSQL to use palloc() instead of malloc()
	o Allow Java server-side programming, http://pljava.sourceforge.net
	  [java]
	o Fix problems with complex temporary table creation/destruction
	  without using PL/PgSQL EXECUTE, needs cache prevention/invalidation
        o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
	o Improve PL/PgSQL exception handling
	o Allow parameters to be specified by name and type during definition
	o Allow function parameters to be passed by name,
	  get_employee_salary(emp_id => 12345, tax_year => 2001)
	o Add PL/PgSQL packages
	o Allow array declarations and other data types in PL/PgSQL DECLARE
	o Add PL/PgSQL PROCEDURES that can return multiple values
	o Add table function support to pltcl, plperl, plpython
	o -Make PL/PgSQL %TYPE schema-aware
	o Allow PL/PgSQL to support array element assignment
	o Add PL/PHP (Joe, Jan)
	o Allow PL/pgSQL to name columns by ordinal position, e.g. rec.(3)
	o Allow PL/pgSQL EXECUTE query_var INTO record_var;


Clients
=======

* -Allow psql to show transaction status if backend protocol changes made
* -Add schema, cast, and conversion backslash commands to psql (Christopher)
* -Allow pg_dump to dump a specific schema (Neil Conway)
* Allow psql to do table completion for SELECT * FROM schema_part and
  table completion for SELECT * FROM schema_name.
* Add XML capability to pg_dump and COPY, when backend XML capability
* -Allow SSL-enabled clients to turn off SSL transfers
* -Modify pg_get_triggerdef() to take a boolean to pretty-print,
  and use that as part of pg_dump along with psql



* JDBC
	o Comprehensive test suite. This may be available already.
	o JDBC-standard BLOB support
	o Error Codes (pending backend implementation)
	o Support both 'make' and 'ant'
	o Fix LargeObject API to handle OIDs as unsigned ints
	o Use cursors implicitly to avoid large results (see setCursorName())
	o Add LISTEN/NOTIFY support to the JDBC driver (Barry)

* ECPG
	o Docs
	o Implement set descriptor, using descriptor
	o Solve cardinality > 1 for input descriptors / variables
	o Improve error handling
	o Add a semantic check level, e.g. check if a table really exists
	o -Add SQLSTATE
	o fix handling of DB attributes that are arrays
	o Use backend prepare/execute facility for ecpg where possible
	o -Make casts work in variable initializations
	o -Implement SQLDA
	o Fix nested C comments
	o sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified
	o -Allow multi-threaded use of SQLCA
	o -Understand structure definitions outside a declare section
	o -Allow :var[:index] or :var[<integer>] as cvariable for an array var

* Python
	o Allow users to register their own types with pg_
	o Allow SELECT to return a dictionary of dictionaries
	o Allow COPY BINARY FROM


Referential Integrity
=====================

* Add MATCH PARTIAL referential integrity [foreign]
* Add deferred trigger queue file (Jan)
* Implement dirty reads or shared row locks and use them in RI triggers
* Enforce referential integrity for system tables
* Change foreign key constraint for array -> element to mean element
  in array
* Allow DEFERRABLE UNIQUE constraints
* Allow triggers to be disabled [trigger]
* With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
* -Support statement-level triggers (Neil)
* Support triggers on columns (Neil)
* Have AFTER triggers execute after the appropriate SQL statement in a 
  function, not at the end of the function


Dependency Checking
===================

* Flush cached query plans when their underlying catalog data changes
* Use dependency information to dump data in proper order


Exotic Features
===============

* Add SQL99 WITH clause to SELECT (Tom, Fernando)
* Add SQL99 WITH RECURSIVE to SELECT (Tom, Fernando)
* Allow queries across multiple databases [crossdb]
* Add pre-parsing phase that converts non-ANSI features to supported features
* Allow plug-in modules to emulate features from other databases
* SQL*Net listener that makes PostgreSQL appear as an Oracle database
  to clients
* Two-phase commit to implement distributed transactions


PERFORMANCE
===========


Fsync
=====

* Delay fsync() when other backends are about to commit too [fsync]
	o Determine optimal commit_delay value
* Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
	o Allow multiple blocks to be written to WAL with one write()


Cache
=====
* Shared catalog cache, reduce lseek()'s by caching table size in shared area
* Add free-behind capability for large sequential scans (Bruce)
* Consider use of open/fcntl(O_DIRECT) to minimize OS caching
* Make blind writes go through the file descriptor cache
* Cache last known per-tuple offsets to speed long tuple access
* Automatically place fixed-width, NOT NULL columns first in a table
* Consider using MVCC to cache count(*) queries with no WHERE clause


Vacuum
======

* Improve speed with indexes (perhaps recreate index instead) [vacuum]
* Reduce lock time by moving tuples with read lock, then write
  lock and truncate table [vacuum]
* Provide automatic running of vacuum in the background in backend
  rather than in /contrib [vacuum]
* Allow free space map to be auto-sized or warn when it is too small


Locking
=======

* Make locking of shared data structures more fine-grained
* Add code to detect an SMP machine and handle spinlocks accordingly
  from distributted.net, http://www1.distributed.net/source, 
  in client/common/cpucheck.cpp
* Research use of sched_yield() for spinlock acquisition failure


Startup Time
============

* Experiment with multi-threaded backend [thread]
* Add connection pooling [pool]
* Allow persistent backends [persistent]
* Create a transaction processor to aid in persistent connections and
  connection pooling
* Do listen() in postmaster and accept() in pre-forked backend
* Have pre-forked backend pre-connect to last requested database or pass
  file descriptor to backend pre-forked for matching database


Write-Ahead Log
===============

* Have after-change WAL write()'s write only modified data to kernel
* Reduce number of after-change WAL writes; they exist only to gaurd against
  partial page writes [wal]
* Turn off after-change writes if fsync is disabled (?)
* Add WAL index reliability improvement to non-btree indexes
* Find proper defaults for postgresql.conf WAL entries
* -Add checkpoint_min_warning postgresql.conf option to warn about checkpoints
  that are too frequent (Bruce)
* Allow xlog directory location to be specified during initdb, perhaps
  using symlinks
* Allow WAL information to recover corrupted pg_controldata
* Find a way to reduce rotational delay when repeatedly writing
  last WAL page


Optimizer / Executor
====================

* Improve Subplan list handling
* -Allow Subplans to use efficient joins(hash, merge) with upper variable
* -Add hash for evaluating GROUP BY aggregates (Tom)
* -Allow merge and hash joins on expressions not just simple variables (Tom)
* -Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS (Tom)
* Missing optimizer selectivities for date, r-tree, etc. [optimizer]
* Allow ORDER BY ... LIMIT to select top values without sort or index
  using a sequential scan for highest/lowest values (Oleg)
* -Inline simple SQL functions to avoid overhead (Tom)
* Precompile SQL functions to avoid overhead (Neil)
* Add utility to compute accurate random_page_cost value
* Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
* Use CHECK constraints to improve optimizer decisions
* Check GUC geqo_threshold to see if it is still accurate
* Allow sorting, temp files, temp tables to use multiple work directories
* Improve the planner to use CHECK constraints to prune the plan (for subtables)


Miscellaneous
=============

* Do async I/O for faster random read-ahead of data
* -Get faster regex() code from Henry Spencer <[email protected]>
* Use mmap() rather than SYSV shared memory or to write WAL files (?) [mmap]
* Improve caching of attribute offsets when NULLs exist in the row
* Add a script to ask system configuration questions and tune postgresql.conf
* Allow partitioning of table into multiple subtables


Source Code
===========

* Add use of 'const' for variables in source tree
* Rename some /contrib modules from pg* to pg_*
* Move some things from /contrib into main tree
* Remove warnings created by -Wcast-align
* Move platform-specific ps status display info from ps_status.c to ports
* -Modify regression tests to prevent failures do to minor numeric rounding
* -Add OpenBSD's getpeereid() call for local socket authentication
* Improve access-permissions check on data directory in Cygwin (Tom)
* Add documentation for perl, including mention of DBI/DBD perl location
* Create improved PostgreSQL introductory documentation for the PHP
  manuals (Rory)
* Add optional CRC checksum to heap and index pages
* Change representation of whole-tuple parameters to functions
* Clarify use of 'application' and 'command' tags in SGML docs
* Better document ability to build only certain interfaces (Marc)
* Remove or relicense modules that are not under the BSD license, if possible
* Remove memory/file descriptor freeing before ereport(ERROR)  (Bruce)
* Acquire lock on a relation before building a relcache entry for it
* Research interaction of setitimer() and sleep() used by statement_timeout
* Add checks for fclose() failure
* Change CVS $Id: TODO,v 1.1107 2003/08/08 02:00:20 momjian Exp $ to $PostgreSQL$
* Exit postmaster if postgresql.conf can not be opened
* Rename /scripts directory because they are all C programs now
* Allow the regression tests to start postmaster with -i so the tests
  can be run on systems that don't support unix-domain sockets
* Allow creation of a libpq-only tarball
* Promote debug_query_string into a server-side function current_query()
* Allow the identifier length to be increased via a configure option


* Wire Protocol Changes
	o -Show transaction status in psql
	o -Allow binding of query parameters, support for prepared queries
	o Add optional textual message to NOTIFY
	o -Remove hard-coded limits on user/db/password names
	o -Remove unused elements of startup packet (unused, tty, passlength)
	o -Fix COPY/fastpath protocol
	o Allow fastpast to pass values in portable format
	o -Error codes
	o Dynamic character set handling
	o Special passing of binary values in platform-neutral format (bytea?)
	o Add decoded type, length, precision
	o Compression?
	o -Report server version number, database encoding, client encoding
	o Update clients to use data types, typmod, schema.table.column names of
	  result sets using new query protocol


---------------------------------------------------------------------------


Developers who have claimed items are:
--------------------------------------
* Barry is Barry Lind <[email protected]>
* Billy is Billy G. Allie <[email protected]>
* Bruce is Bruce Momjian <[email protected]> of Software Research Assoc.
* Christopher is Christopher Kings-Lynne <[email protected]> of
    Family Health Network
* D'Arcy is D'Arcy J.M. Cain <[email protected]> of The Cain Gang Ltd.
* Dave is Dave Cramer <[email protected]>
* Edmund is Edmund Mergl <[email protected]>
* Fernando is Fernando Nasser <[email protected]> of Red Hat
* Gavin is Gavin Sherry <[email protected]> of Alcove Systems Engineering
* Greg is Greg Sabino Mullane <[email protected]>
* Hiroshi is Hiroshi Inoue <[email protected]>
* Karel is Karel Zak <[email protected]>
* Jan is Jan Wieck <[email protected]> of PeerDirect Corp.
* Liam is Liam Stewart <[email protected]> of Red Hat
* Marc is Marc Fournier <[email protected]> of PostgreSQL, Inc.
* Mark is Mark Hollomon <[email protected]>
* Michael is Michael Meskes <[email protected]> of Credativ
* Neil is Neil Conway <[email protected]>
* Oleg is Oleg Bartunov <[email protected]>
* Peter M is Peter T Mount <[email protected]> of Retep Software
* Peter E is Peter Eisentraut <[email protected]>
* Philip is Philip Warner <[email protected]> of Albatross Consulting Pty. Ltd.
* Rod is Rod Taylor <[email protected]>
* Ross is Ross J. Reedstrom <[email protected]>
* Stephan is Stephan Szabo <[email protected]>
* Tatsuo is Tatsuo Ishii <[email protected]> of Software Research Assoc.
* Thomas is Thomas Lockhart <[email protected]> of Jet Propulsion Labratory
* Tom is Tom Lane <[email protected]> of Red Hat
* Vadim is Vadim B. Mikheev <[email protected]> of Sector Data


Attachments:

  [text/plain] /pgdev/TODO (21.8K, ../../[email protected]/2-%2Fpgdev%2FTODO)
  download | inline:
TODO list for PostgreSQL
========================
Last updated:		Thu Aug  7 22:00:19 EDT 2003

Current maintainer:	Bruce Momjian ([email protected])

The most recent version of this document can be viewed at
the PostgreSQL web site, http://www.PostgreSQL.org.

A dash (-) marks changes that will appear in the upcoming 7.4 release.

Bracketed items "[]" have more detailed.


Urgent
======

* Add replication of distributed databases [replication]
	o Automatic failover
	o Load balancing
	o Master/slave replication
	o Multi-master replication
	o Partition data across servers
	o Sample implementation in contrib/rserv
	o Queries across databases or servers (two-phase commit)
	o Allow replication over unreliable or non-persistent links
	o http://gborg.postgresql.org/project/pgreplication/projdisplay.php
* Point-in-time data recovery using backup and write-ahead log
* Create native Win32 port [win32]


Reporting
=========

* -Allow elog() to return error codes, module name, file name, line
  number, not just messages (Tom)
* -Add error codes (Tom)
* -Make error messages more consistent
* Show location of syntax error in query [yacc]
* -Add GUC log_statement_and_duration to print statement and >= min duration


Administration
==============

* Incremental backups
* Remove unreferenced table files and temp tables during database vacuum
  or postmaster startup (Bruce)
* Remove behavior of postmaster -o after making postmaster/postgres
  flags unique
* Allow easy display of usernames in a group
* Allow configuration files to be specified in a different directory
* -Add start time to pg_stat_activity
* Allow limits on per-db/user connections
* Have standalone backend read postgresql.conf
* Add group object ownership, so groups can rename/drop/grant on objects,
  so we can implement roles
* Add the concept of dataspaces/tablespaces [tablespaces]
* -Allow CIDR format to be used in pg_hba.conf
* Allow logging of only data definition(DDL), or DDL and modification statements
* Allow log lines to include session-level information, like database and user
* Allow server log information to be output as INSERT statements


Data Types
==========

* -Add IPv6 capability to INET/CIDR types
* Remove Money type, add money formatting for decimal type
* Change factorial to return a numeric
* -Change NUMERIC data type to use base 10,000 internally
* Change NUMERIC to enforce the maximum precision, and increase it
* Add function to return compressed length of TOAST data values (Tom)
* Allow INET subnet tests using non-constants
* Add transaction_timestamp(), statement_timestamp(), clock_timestamp() functionality
* -Add GUC variables to control floating number output digits (Pedro Ferreira)
* Have sequence dependency track use of DEFAULT sequences, seqname.nextval
* Disallow changing default expression of a SERIAL column
* Allow infinite dates just like infinite timestamps
* Allow pg_dump to dump sequences using NO_MAXVALUE and NO_MINVALUE
* Allow better handling of numeric constants, type conversion [typeconv]
* Allow backend to output result sets in XML
* Prevent whole-row references from leaking memory, e.g. SELECT COUNT(tab.*)
* -Allow current datestyle to restrict dates;  prevent month/day swapping
  from making invalid dates valid
* -Prevent month/day swapping of ISO dates to make invalid dates valid
* Have initdb set DateStyle based on locale?
* -Delay resolution of array expression type so assignment coercion 
  can be performed on empty array expressions (Joe)

* ARRAYS
	o Allow nulls in arrays
	o -Allow arrays to be ORDER'ed
	o Support construction of array result values in expressions

* BINARY DATA
	o Improve vacuum of large objects, like /contrib/vacuumlo
	o Add security checking for large objects
	o Make file in/out interface for TOAST columns, similar to large object
	  interface (force out-of-line storage and no compression)
	o Auto-delete large objects when referencing row is deleted


Multi-Language Support
======================

* Add NCHAR (as distinguished from ordinary varchar),
* Allow LOCALE on a per-column basis, default to ASCII
* Support multiple simultaneous character sets, per SQL92
* Improve Unicode combined character handling
* Optimize locale to have minimal performance impact when not used (Peter E)
* Add octet_length_server() and octet_length_client() (Thomas, Tatsuo)
* Make octet_length_client the same as octet_length() (?)
* Prevent mismatch of frontend/backend encodings from converting bytea
  data from being interpreted as encoded strings
* -Remove Cyrillic recode support

 
Views / Rules
=============

* Automatically create rules on views so they are updateable, per SQL92 [view]
* Add the functionality for WITH CHECK OPTION clause of CREATE VIEW
* Allow NOTIFY in rules involving conditionals
* Have views on temporary tables exist in the temporary namespace
* Move psql backslash information into views
* Allow RULE recompilation


Indexes
=======

* Allow CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops)
  fails index can't store constant parameters
* Order duplicate index entries by tid for faster heap lookups
* Allow inherited tables to inherit index, UNIQUE constraint, and primary
  key, foreign key  [inheritance]
* UNIQUE INDEX on base column not honored on inserts from inherited table
  INSERT INTO inherit_table (unique_index_col) VALUES (dup) should fail
  [inheritance]
* Add UNIQUE capability to non-btree indexes
* Add btree index support for reltime, tinterval, regproc
* Add rtree index support for line, lseg, path, point
* -Certain indexes will not shrink, e.g. indexes on ever-increasing
  columns and indexes with many duplicate keys
* Use indexes for min() and max() or convert to SELECT col FROM tab ORDER
  BY col DESC LIMIT 1 if appropriate index exists and WHERE clause acceptible
* Allow LIKE indexing optimization for non-ASCII locales
* Use index to restrict rows returned by multi-key index when used with
  non-consecutive keys or OR clauses, so fewer heap accesses
* Be smarter about insertion of already-ordered data into btree index
* Prevent index uniqueness checks when UPDATE does not modify the column
* Use bitmaps to fetch heap pages in sequential order [performance]
* Use bitmaps to combine existing indexes [performance]
* Improve handling of index scans for NULL
* Allow SELECT * FROM tab WHERE int2col = 4 to use int2col index, int8,
  float4, numeric/decimal too [optimizer]
* Add FILLFACTOR to btree index creation
* Add concurrency to GIST
* Improve concurrency of hash indexes (Neil)
* Allow a single index to index multiple tables (for inheritance and subtables)


Commands
========

* Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
* -Allow LIMIT/OFFSET to use expressions (Tom)
* CREATE TABLE AS can not determine column lengths from expressions [atttypmod]
* Allow UPDATE to handle complex aggregates [update]
* Allow command blocks to ignore certain types of errors
* Allow backslash handling in quoted strings to be disabled for portability
* Return proper effected tuple count from complex commands [return]
* Allow UPDATE, DELETE to handle table aliases for self-joins [delete]
* Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT
* Allow REINDEX to rebuild all indexes, remove /contrib/reindex
* -Make a transaction-safe TRUNCATE (Rod)
* Add ROLLUP, CUBE, GROUPING SETS options to GROUP BY
* Add schema option to createlang
* Allow savepoints / nested transactions [transactions] (Bruce)
* Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple columns
* -Allow UPDATE to use SET col = DEFAULT
* -Add config variable to prevent auto-adding missing FROM-clause tables
* Allow SET CONSTRAINTS to be qualified by schema/table
* -Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle
* Prevent COMMENT ON DATABASE from using a database name
* Add GUC variable to prevent waiting on locks


* ALTER
	o ALTER TABLE ADD COLUMN does not honor DEFAULT and non-CHECK CONSTRAINT
	o ALTER TABLE ADD COLUMN column DEFAULT should fill existing
	  rows with DEFAULT value
	o ALTER TABLE ADD COLUMN column SERIAL doesn't create sequence because
          of the item above
	o --Add ALTER TABLE tab SET WITHOUT OIDS (Rod)
	o -Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values
	o Have ALTER TABLE rename SERIAL sequences
	o Allow columns to be reordered using ALTER ... POSITION i col1 [,col2];
	  have SELECT * and INSERT honor such ordering
	o Allow ALTER TABLE to modify column lengths and change to binary
	  compatible types
	o Add ALTER DATABASE ... OWNER TO newowner

* CLUSTER
	o Automatically maintain clustering on a table
	o -Allow CLUSTER to cluster all tables (Alvaro Herrera)

* COPY
	o Allow dump/load of CSV format
	o Allow COPY to report error lines and continue;  optionally
	  allow error codes to be specified; requires savepoints or can
	  not be run in a multi-statement transaction
	o Allow COPY to understand \x as hex
	o Have COPY return number of rows loaded/unloaded

* CURSOR
	o Allow BINARY option to SELECT, just like DECLARE
	o -MOVE 0 should not move to end of cursor (Bruce)
	o Allow UPDATE/DELETE WHERE CURRENT OF cursor using per-cursor tid
	  stored in the backend (Gavin)
	o Prevent DROP of table being referenced by our own open cursor
	o -Allow cursors outside transactions

* INSERT
	o Allow INSERT/UPDATE of system-generated oid value for a row
	o Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
	o Allow INSERT/UPDATE ... RETURNING new.col or old.col; handle
	  RULE cases (Philip)

* SHOW/SET
	o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
	  ANALYZE, and CLUSTER
	o Add SET SCHEMA
	o -Allow EXPLAIN EXECUTE to see prepared plans
	o Allow SHOW of non-modifiable variables, like pg_controldata

* SERVER-SIDE LANGUAGES
	o Allow PL/PgSQL's RAISE function to take expressions
	o Change PL/PgSQL to use palloc() instead of malloc()
	o Allow Java server-side programming, http://pljava.sourceforge.net
	  [java]
	o Fix problems with complex temporary table creation/destruction
	  without using PL/PgSQL EXECUTE, needs cache prevention/invalidation
        o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
	o Improve PL/PgSQL exception handling
	o Allow parameters to be specified by name and type during definition
	o Allow function parameters to be passed by name,
	  get_employee_salary(emp_id => 12345, tax_year => 2001)
	o Add PL/PgSQL packages
	o Allow array declarations and other data types in PL/PgSQL DECLARE
	o Add PL/PgSQL PROCEDURES that can return multiple values
	o Add table function support to pltcl, plperl, plpython
	o -Make PL/PgSQL %TYPE schema-aware
	o Allow PL/PgSQL to support array element assignment
	o Add PL/PHP (Joe, Jan)
	o Allow PL/pgSQL to name columns by ordinal position, e.g. rec.(3)
	o Allow PL/pgSQL EXECUTE query_var INTO record_var;


Clients
=======

* -Allow psql to show transaction status if backend protocol changes made
* -Add schema, cast, and conversion backslash commands to psql (Christopher)
* -Allow pg_dump to dump a specific schema (Neil Conway)
* Allow psql to do table completion for SELECT * FROM schema_part and
  table completion for SELECT * FROM schema_name.
* Add XML capability to pg_dump and COPY, when backend XML capability
* -Allow SSL-enabled clients to turn off SSL transfers
* -Modify pg_get_triggerdef() to take a boolean to pretty-print,
  and use that as part of pg_dump along with psql



* JDBC
	o Comprehensive test suite. This may be available already.
	o JDBC-standard BLOB support
	o Error Codes (pending backend implementation)
	o Support both 'make' and 'ant'
	o Fix LargeObject API to handle OIDs as unsigned ints
	o Use cursors implicitly to avoid large results (see setCursorName())
	o Add LISTEN/NOTIFY support to the JDBC driver (Barry)

* ECPG
	o Docs
	o Implement set descriptor, using descriptor
	o Solve cardinality > 1 for input descriptors / variables
	o Improve error handling
	o Add a semantic check level, e.g. check if a table really exists
	o -Add SQLSTATE
	o fix handling of DB attributes that are arrays
	o Use backend prepare/execute facility for ecpg where possible
	o -Make casts work in variable initializations
	o -Implement SQLDA
	o Fix nested C comments
	o sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified
	o -Allow multi-threaded use of SQLCA
	o -Understand structure definitions outside a declare section
	o -Allow :var[:index] or :var[<integer>] as cvariable for an array var

* Python
	o Allow users to register their own types with pg_
	o Allow SELECT to return a dictionary of dictionaries
	o Allow COPY BINARY FROM


Referential Integrity
=====================

* Add MATCH PARTIAL referential integrity [foreign]
* Add deferred trigger queue file (Jan)
* Implement dirty reads or shared row locks and use them in RI triggers
* Enforce referential integrity for system tables
* Change foreign key constraint for array -> element to mean element
  in array
* Allow DEFERRABLE UNIQUE constraints
* Allow triggers to be disabled [trigger]
* With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY
* -Support statement-level triggers (Neil)
* Support triggers on columns (Neil)
* Have AFTER triggers execute after the appropriate SQL statement in a 
  function, not at the end of the function


Dependency Checking
===================

* Flush cached query plans when their underlying catalog data changes
* Use dependency information to dump data in proper order


Exotic Features
===============

* Add SQL99 WITH clause to SELECT (Tom, Fernando)
* Add SQL99 WITH RECURSIVE to SELECT (Tom, Fernando)
* Allow queries across multiple databases [crossdb]
* Add pre-parsing phase that converts non-ANSI features to supported features
* Allow plug-in modules to emulate features from other databases
* SQL*Net listener that makes PostgreSQL appear as an Oracle database
  to clients
* Two-phase commit to implement distributed transactions


PERFORMANCE
===========


Fsync
=====

* Delay fsync() when other backends are about to commit too [fsync]
	o Determine optimal commit_delay value
* Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
	o Allow multiple blocks to be written to WAL with one write()


Cache
=====
* Shared catalog cache, reduce lseek()'s by caching table size in shared area
* Add free-behind capability for large sequential scans (Bruce)
* Consider use of open/fcntl(O_DIRECT) to minimize OS caching
* Make blind writes go through the file descriptor cache
* Cache last known per-tuple offsets to speed long tuple access
* Automatically place fixed-width, NOT NULL columns first in a table
* Consider using MVCC to cache count(*) queries with no WHERE clause


Vacuum
======

* Improve speed with indexes (perhaps recreate index instead) [vacuum]
* Reduce lock time by moving tuples with read lock, then write
  lock and truncate table [vacuum]
* Provide automatic running of vacuum in the background in backend
  rather than in /contrib [vacuum]
* Allow free space map to be auto-sized or warn when it is too small


Locking
=======

* Make locking of shared data structures more fine-grained
* Add code to detect an SMP machine and handle spinlocks accordingly
  from distributted.net, http://www1.distributed.net/source, 
  in client/common/cpucheck.cpp
* Research use of sched_yield() for spinlock acquisition failure


Startup Time
============

* Experiment with multi-threaded backend [thread]
* Add connection pooling [pool]
* Allow persistent backends [persistent]
* Create a transaction processor to aid in persistent connections and
  connection pooling
* Do listen() in postmaster and accept() in pre-forked backend
* Have pre-forked backend pre-connect to last requested database or pass
  file descriptor to backend pre-forked for matching database


Write-Ahead Log
===============

* Have after-change WAL write()'s write only modified data to kernel
* Reduce number of after-change WAL writes; they exist only to gaurd against
  partial page writes [wal]
* Turn off after-change writes if fsync is disabled (?)
* Add WAL index reliability improvement to non-btree indexes
* Find proper defaults for postgresql.conf WAL entries
* -Add checkpoint_min_warning postgresql.conf option to warn about checkpoints
  that are too frequent (Bruce)
* Allow xlog directory location to be specified during initdb, perhaps
  using symlinks
* Allow WAL information to recover corrupted pg_controldata
* Find a way to reduce rotational delay when repeatedly writing
  last WAL page


Optimizer / Executor
====================

* Improve Subplan list handling
* -Allow Subplans to use efficient joins(hash, merge) with upper variable
* -Add hash for evaluating GROUP BY aggregates (Tom)
* -Allow merge and hash joins on expressions not just simple variables (Tom)
* -Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS (Tom)
* Missing optimizer selectivities for date, r-tree, etc. [optimizer]
* Allow ORDER BY ... LIMIT to select top values without sort or index
  using a sequential scan for highest/lowest values (Oleg)
* -Inline simple SQL functions to avoid overhead (Tom)
* Precompile SQL functions to avoid overhead (Neil)
* Add utility to compute accurate random_page_cost value
* Improve ability to display optimizer analysis using OPTIMIZER_DEBUG
* Use CHECK constraints to improve optimizer decisions
* Check GUC geqo_threshold to see if it is still accurate
* Allow sorting, temp files, temp tables to use multiple work directories
* Improve the planner to use CHECK constraints to prune the plan (for subtables)


Miscellaneous
=============

* Do async I/O for faster random read-ahead of data
* -Get faster regex() code from Henry Spencer <[email protected]>
* Use mmap() rather than SYSV shared memory or to write WAL files (?) [mmap]
* Improve caching of attribute offsets when NULLs exist in the row
* Add a script to ask system configuration questions and tune postgresql.conf
* Allow partitioning of table into multiple subtables


Source Code
===========

* Add use of 'const' for variables in source tree
* Rename some /contrib modules from pg* to pg_*
* Move some things from /contrib into main tree
* Remove warnings created by -Wcast-align
* Move platform-specific ps status display info from ps_status.c to ports
* -Modify regression tests to prevent failures do to minor numeric rounding
* -Add OpenBSD's getpeereid() call for local socket authentication
* Improve access-permissions check on data directory in Cygwin (Tom)
* Add documentation for perl, including mention of DBI/DBD perl location
* Create improved PostgreSQL introductory documentation for the PHP
  manuals (Rory)
* Add optional CRC checksum to heap and index pages
* Change representation of whole-tuple parameters to functions
* Clarify use of 'application' and 'command' tags in SGML docs
* Better document ability to build only certain interfaces (Marc)
* Remove or relicense modules that are not under the BSD license, if possible
* Remove memory/file descriptor freeing before ereport(ERROR)  (Bruce)
* Acquire lock on a relation before building a relcache entry for it
* Research interaction of setitimer() and sleep() used by statement_timeout
* Add checks for fclose() failure
* Change CVS $Id: TODO,v 1.1107 2003/08/08 02:00:20 momjian Exp $ to $PostgreSQL$
* Exit postmaster if postgresql.conf can not be opened
* Rename /scripts directory because they are all C programs now
* Allow the regression tests to start postmaster with -i so the tests
  can be run on systems that don't support unix-domain sockets
* Allow creation of a libpq-only tarball
* Promote debug_query_string into a server-side function current_query()
* Allow the identifier length to be increased via a configure option


* Wire Protocol Changes
	o -Show transaction status in psql
	o -Allow binding of query parameters, support for prepared queries
	o Add optional textual message to NOTIFY
	o -Remove hard-coded limits on user/db/password names
	o -Remove unused elements of startup packet (unused, tty, passlength)
	o -Fix COPY/fastpath protocol
	o Allow fastpast to pass values in portable format
	o -Error codes
	o Dynamic character set handling
	o Special passing of binary values in platform-neutral format (bytea?)
	o Add decoded type, length, precision
	o Compression?
	o -Report server version number, database encoding, client encoding
	o Update clients to use data types, typmod, schema.table.column names of
	  result sets using new query protocol


---------------------------------------------------------------------------


Developers who have claimed items are:
--------------------------------------
* Barry is Barry Lind <[email protected]>
* Billy is Billy G. Allie <[email protected]>
* Bruce is Bruce Momjian <[email protected]> of Software Research Assoc.
* Christopher is Christopher Kings-Lynne <[email protected]> of
    Family Health Network
* D'Arcy is D'Arcy J.M. Cain <[email protected]> of The Cain Gang Ltd.
* Dave is Dave Cramer <[email protected]>
* Edmund is Edmund Mergl <[email protected]>
* Fernando is Fernando Nasser <[email protected]> of Red Hat
* Gavin is Gavin Sherry <[email protected]> of Alcove Systems Engineering
* Greg is Greg Sabino Mullane <[email protected]>
* Hiroshi is Hiroshi Inoue <[email protected]>
* Karel is Karel Zak <[email protected]>
* Jan is Jan Wieck <[email protected]> of PeerDirect Corp.
* Liam is Liam Stewart <[email protected]> of Red Hat
* Marc is Marc Fournier <[email protected]> of PostgreSQL, Inc.
* Mark is Mark Hollomon <[email protected]>
* Michael is Michael Meskes <[email protected]> of Credativ
* Neil is Neil Conway <[email protected]>
* Oleg is Oleg Bartunov <[email protected]>
* Peter M is Peter T Mount <[email protected]> of Retep Software
* Peter E is Peter Eisentraut <[email protected]>
* Philip is Philip Warner <[email protected]> of Albatross Consulting Pty. Ltd.
* Rod is Rod Taylor <[email protected]>
* Ross is Ross J. Reedstrom <[email protected]>
* Stephan is Stephan Szabo <[email protected]>
* Tatsuo is Tatsuo Ishii <[email protected]> of Software Research Assoc.
* Thomas is Thomas Lockhart <[email protected]> of Jet Propulsion Labratory
* Tom is Tom Lane <[email protected]> of Red Hat
* Vadim is Vadim B. Mikheev <[email protected]> of Sector Data

^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 03:36  Josh Berkus <[email protected]>
  parent: Bruce Momjian <[email protected]>
  2 siblings, 2 replies; 46+ messages in thread

From: Josh Berkus @ 2003-08-08 03:36 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; pgsql-hackers

Bruce,

>         o Allow array declarations and other data types in PL/PgSQL DECLARE
>         o Allow PL/PgSQL to support array element assignment

AFAIK, these two are not done, but they are redundant.  Either one requires 
the implementation of the other.

>         o Add PL/PgSQL PROCEDURES that can return multiple values

Hmmm ... I know how this got on the TODO, but it's a fragment of a larger 
suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much 
sense on its own without the other elements; maybe we should take it off 
until I can make a full proposal?

>         o Add table function support to pltcl, plperl, plpython

If this was done, I would dearly love to know about it ...

-- 
Josh Berkus
Aglio Database Solutions
San Francisco



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 04:00  Joe Conway <[email protected]>
  parent: Josh Berkus <[email protected]>
  1 sibling, 2 replies; 46+ messages in thread

From: Joe Conway @ 2003-08-08 04:00 UTC (permalink / raw)
  To: Josh Berkus <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers

Josh Berkus wrote:
>>        o Allow array declarations and other data types in PL/PgSQL DECLARE
>>        o Allow PL/PgSQL to support array element assignment
> 
> AFAIK, these two are not done, but they are redundant.  Either one requires 
> the implementation of the other.

They are done (at least the array declarations and array element 
assignment part):

create or replace function test() returns integer[] as '
declare
   v_ret integer[] := ''{}'';
begin
   v_ret[1] := 1;
   v_ret[2] := 2;
   return v_ret;
end;
' language plpgsql;
CREATE FUNCTION
regression=# select test();
  test
-------
  {1,2}
(1 row)


>>        o Add PL/PgSQL PROCEDURES that can return multiple values
> 
> Hmmm ... I know how this got on the TODO, but it's a fragment of a larger 
> suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much 
> sense on its own without the other elements; maybe we should take it off 
> until I can make a full proposal?

Is this somehow different from table functions (SRFs)?

>>        o Add table function support to pltcl, plperl, plpython
> 
> If this was done, I would dearly love to know about it ...
> 

Pretty much sure this has not been done. I'll be happy to work with 
someone if they want to pick this up, but I don't use them enough to 
feel comfortable doing it myself.

Joe




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 04:24  Joe Conway <[email protected]>
  parent: Bruce Momjian <[email protected]>
  2 siblings, 2 replies; 46+ messages in thread

From: Joe Conway @ 2003-08-08 04:24 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers

Bruce Momjian wrote:
> I am marking the completed TODO items.  Are these done?
> 

Can we mark this one complete?
* Allow easy display of usernames in a group
regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM 
pg_shadow s, pg_group g WHERE s.usesysid = any (g.grolist);
  grosysid | groname | usesysid | usename
----------+---------+----------+---------
       100 | g1      |      100 | user1
       101 | g2      |      100 | user1
       100 | g1      |      101 | user2
       101 | g2      |      101 | user2
       101 | g2      |      102 | user3
(5 rows)


This one isn't done:
* -Delay resolution of array expression type so assignment coercion
   can be performed on empty array expressions (Joe)

This one I don't understand:
o Support construction of array result values in expressions

I thought Peter did something with this one:
* Allow LIKE indexing optimization for non-ASCII locales

Joe




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 04:35  Josh Berkus <[email protected]>
  parent: Joe Conway <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Josh Berkus @ 2003-08-08 04:35 UTC (permalink / raw)
  To: Joe Conway <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers

Joe,

> They are done (at least the array declarations and array element
> assignment part):

Way cool!  How'd I miss that one?

Time to test ....

> >>        o Add PL/PgSQL PROCEDURES that can return multiple values
> >
> > Hmmm ... I know how this got on the TODO, but it's a fragment of a larger
> > suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much
> > sense on its own without the other elements; maybe we should take it off
> > until I can make a full proposal?
>
> Is this somehow different from table functions (SRFs)?

Yes.   Reference T-SQL's OUTPUT parameters.

Mind you, with the implementation of SRFs, it's not as necessary as it once 
was.

> Pretty much sure this has not been done. I'll be happy to work with
> someone if they want to pick this up, but I don't use them enough to
> feel comfortable doing it myself.

I'd be happy to test PL/Perl.  I won't be any help with the others ...

-- 
Josh Berkus
Aglio Database Solutions
San Francisco



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 13:56  Tom Lane <[email protected]>
  parent: Bruce Momjian <[email protected]>
  2 siblings, 2 replies; 46+ messages in thread

From: Tom Lane @ 2003-08-08 13:56 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers

Bruce Momjian <[email protected]> writes:
> I am marking the completed TODO items.  Are these done?

> 	* Have standalone backend read postgresql.conf

[looks] Nope.  No ProcessConfigFile() call in postgres.c.

> 	* Prevent whole-row references from leaking memory, e.g. SELECT
> 	  COUNT(tab.*)

Nope.

> 	* Use index to restrict rows returned by multi-key index when used with
> 	  non-consecutive keys or OR clauses, so fewer heap accesses

Not sure what this means.

> 	* Prevent index uniqueness checks when UPDATE does not modify the column

Not done.

> 	* Return proper effected tuple count from complex commands [return]

I looked at that TODO.detail file, and it all seems to be ancient
history.  Didn't we resolve those issues to peoples' satisfaction in 7.3?

> 	o Allow SHOW of non-modifiable variables, like pg_controldata

I put in read-only variables for the things that seemed most interesting
(LC_COLLATE for example), but the coverage isn't complete.

>         o Allow array declarations and other data types in PL/PgSQL DECLARE

AFAIK this is pretty much fixed.

>         o Add PL/PgSQL PROCEDURES that can return multiple values

Not done (unless this is referring to RETURN NEXT, but I think it's
talking about multiple output parameters).

>         o Add table function support to pltcl, plperl, plpython

Not done.

>         o Allow PL/PgSQL to support array element assignment

Done.

> 	* Make blind writes go through the file descriptor cache

Not done.

> 	* Improve Subplan list handling

Dunno what this is referring to.

> 	* Precompile SQL functions to avoid overhead (Neil)

Not done.

> 	* Add optional CRC checksum to heap and index pages

Not done.

>         o Add optional textual message to NOTIFY

Not done, but there is room in the FE/BE protocol now for something like
this.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 14:11  Tom Lane <[email protected]>
  parent: Joe Conway <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Tom Lane @ 2003-08-08 14:11 UTC (permalink / raw)
  To: Joe Conway <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers

Joe Conway <[email protected]> writes:
> This one I don't understand:
> o Support construction of array result values in expressions

Not sure why you don't understand it, when you did it ;-).  It's asking
for the ARRAY[] syntax.  Bruce, that one should be marked done.

> I thought Peter did something with this one:
> * Allow LIKE indexing optimization for non-ASCII locales

Yeah, he did.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 16:33  Bruce Momjian <[email protected]>
  parent: Josh Berkus <[email protected]>
  1 sibling, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 16:33 UTC (permalink / raw)
  To: Josh Berkus <[email protected]>; +Cc: pgsql-hackers

Josh Berkus wrote:
> Bruce,
> 
> >         o Allow array declarations and other data types in PL/PgSQL DECLARE
> >         o Allow PL/PgSQL to support array element assignment
> 
> AFAIK, these two are not done, but they are redundant.  Either one requires 
> the implementation of the other.

OK.


> >         o Add PL/PgSQL PROCEDURES that can return multiple values
> 
> Hmmm ... I know how this got on the TODO, but it's a fragment of a larger 
> suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much 
> sense on its own without the other elements; maybe we should take it off 
> until I can make a full proposal?

Removed.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 16:35  Bruce Momjian <[email protected]>
  parent: Joe Conway <[email protected]>
  1 sibling, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 16:35 UTC (permalink / raw)
  To: Joe Conway <[email protected]>; +Cc: Josh Berkus <[email protected]>; pgsql-hackers

Joe Conway wrote:
> Josh Berkus wrote:
> >>        o Allow array declarations and other data types in PL/PgSQL DECLARE
> >>        o Allow PL/PgSQL to support array element assignment
> > 
> > AFAIK, these two are not done, but they are redundant.  Either one requires 
> > the implementation of the other.
> 
> They are done (at least the array declarations and array element 
> assignment part):
> 
> create or replace function test() returns integer[] as '
> declare
>    v_ret integer[] := ''{}'';
> begin
>    v_ret[1] := 1;
>    v_ret[2] := 2;
>    return v_ret;
> end;
> ' language plpgsql;
> CREATE FUNCTION
> regression=# select test();
>   test
> -------
>   {1,2}
> (1 row)
> 


OK, marked as done.

> >>        o Add PL/PgSQL PROCEDURES that can return multiple values
> > 
> > Hmmm ... I know how this got on the TODO, but it's a fragment of a larger 
> > suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much 
> > sense on its own without the other elements; maybe we should take it off 
> > until I can make a full proposal?
> 
> Is this somehow different from table functions (SRFs)?

Yes, I am unsure what it is.  Removed pending later proposal.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 16:53  Bruce Momjian <[email protected]>
  parent: Joe Conway <[email protected]>
  1 sibling, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 16:53 UTC (permalink / raw)
  To: Joe Conway <[email protected]>; +Cc: pgsql-hackers

Joe Conway wrote:
> Bruce Momjian wrote:
> > I am marking the completed TODO items.  Are these done?
> > 
> 
> Can we mark this one complete?
> * Allow easy display of usernames in a group
> regression=# SELECT g.grosysid, g.groname, s.usesysid, s.usename FROM 
> pg_shadow s, pg_group g WHERE s.usesysid = any (g.grolist);
>   grosysid | groname | usesysid | usename
> ----------+---------+----------+---------
>        100 | g1      |      100 | user1
>        101 | g2      |      100 | user1
>        100 | g1      |      101 | user2
>        101 | g2      |      101 | user2
>        101 | g2      |      102 | user3
> (5 rows)

OK, let me mark it as done, and add to the psql section:

	* Allow psql \du to show groups, and add \dg for groups

> This one isn't done:
> * -Delay resolution of array expression type so assignment coercion
>    can be performed on empty array expressions (Joe)

OK.

> This one I don't understand:
> o Support construction of array result values in expressions

I don't either.  Anyone?

> I thought Peter did something with this one:
> * Allow LIKE indexing optimization for non-ASCII locales

He added a special LIKE operator type, rather than allowing our existing
indexes to use LIKE, so I would say it is partially done.

I updated it to:

	* -Allow LIKE indexing optimization for non-ASCII locales using
	  special index

and marked it as done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 16:55  Bruce Momjian <[email protected]>
  parent: Josh Berkus <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 16:55 UTC (permalink / raw)
  To: Josh Berkus <[email protected]>; +Cc: Joe Conway <[email protected]>; pgsql-hackers

Josh Berkus wrote:
> Joe,
> 
> > They are done (at least the array declarations and array element
> > assignment part):
> 
> Way cool!  How'd I miss that one?
> 
> Time to test ....
> 
> > >>        o Add PL/PgSQL PROCEDURES that can return multiple values
> > >
> > > Hmmm ... I know how this got on the TODO, but it's a fragment of a larger
> > > suggestion about PROCEDURES vs. FUNCTIONS.   I don't think it makes much
> > > sense on its own without the other elements; maybe we should take it off
> > > until I can make a full proposal?
> >
> > Is this somehow different from table functions (SRFs)?
> 
> Yes.   Reference T-SQL's OUTPUT parameters.
> 
> Mind you, with the implementation of SRFs, it's not as necessary as it once 
> was.

Do you have TODO to add for this?  I removed the original one because,
as worded, it was complete.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:01  Joe Conway <[email protected]>
  parent: Bruce Momjian <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Joe Conway @ 2003-08-08 17:01 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: Josh Berkus <[email protected]>; pgsql-hackers

Bruce Momjian wrote:
>>>>>       o Add PL/PgSQL PROCEDURES that can return multiple values
>>>>
> 
> Do you have TODO to add for this?  I removed the original one because,
> as worded, it was complete.
> 

Actually, now that I look at it again, it is referring to procedures, 
not functions. Maybe just make it:

o Add capability to create and call PROCEDURES

Joe




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:09  Bruce Momjian <[email protected]>
  parent: Tom Lane <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 17:09 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > I am marking the completed TODO items.  Are these done?
> 
> > 	* Have standalone backend read postgresql.conf
> 
> [looks] Nope.  No ProcessConfigFile() call in postgres.c.

OK.

> 
> > 	* Prevent whole-row references from leaking memory, e.g. SELECT
> > 	  COUNT(tab.*)
> 
> Nope.

OK, I wasn't sure because you had done per-tuple memory contexts.

> > 	* Use index to restrict rows returned by multi-key index when used with
> > 	  non-consecutive keys or OR clauses, so fewer heap accesses
> 
> Not sure what this means.

This is a Vadim idea.  The idea was that if you had a multi-key index on
col1,col2,col3, and you wanted to do a lookup on col1,col3, you could
still use the index, and just run through all the matching col1 values
looking for a matching col3 in the index, rather than going to the heap
and looking for a col3 match?  Is this item worth keeping?

> 
> > 	* Prevent index uniqueness checks when UPDATE does not modify the column
> 
> Not done.

OK.

> > 	* Return proper effected tuple count from complex commands [return]
> 
> I looked at that TODO.detail file, and it all seems to be ancient
> history.  Didn't we resolve those issues to peoples' satisfaction in 7.3?

I think so. I think MOVE was our last one.

> > 	o Allow SHOW of non-modifiable variables, like pg_controldata
> 
> I put in read-only variables for the things that seemed most interesting
> (LC_COLLATE for example), but the coverage isn't complete.


I modified the item to say "some" and marked it as done:

        o -Allow SHOW of some non-modifiable variables, like
	  pg_controldata

Anyone want it kept?

> >         o Allow array declarations and other data types in PL/PgSQL DECLARE
> 
> AFAIK this is pretty much fixed.

OK.  Already reported by Joe.

> 
> >         o Add PL/PgSQL PROCEDURES that can return multiple values
> 
> Not done (unless this is referring to RETURN NEXT, but I think it's
> talking about multiple output parameters).

I am asking Josh for a new item with clearer wording.  Once we finish
some items, the wording often needs adjusting.

> >         o Add table function support to pltcl, plperl, plpython
> 
> Not done.

OK.

> >         o Allow PL/PgSQL to support array element assignment
> 
> Done.

OK.

> > 	* Make blind writes go through the file descriptor cache
> 
> Not done.

OK.


> 
> > 	* Improve Subplan list handling
> 
> Dunno what this is referring to.

I assume it is related to the subquery stuff you did.  I have marked it
as done.

> > 	* Precompile SQL functions to avoid overhead (Neil)
> 
> Not done.

OK.


> > 	* Add optional CRC checksum to heap and index pages
> 
> Not done.

OK.

> >         o Add optional textual message to NOTIFY
> 
> Not done, but there is room in the FE/BE protocol now for something like
> this.

OK.

Thanks.  TODO updated.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:12  Bruce Momjian <[email protected]>
  parent: Tom Lane <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 17:12 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Joe Conway <[email protected]>; pgsql-hackers

Tom Lane wrote:
> Joe Conway <[email protected]> writes:
> > This one I don't understand:
> > o Support construction of array result values in expressions
> 
> Not sure why you don't understand it, when you did it ;-).  It's asking
> for the ARRAY[] syntax.  Bruce, that one should be marked done.

Updated as done.

> > I thought Peter did something with this one:
> > * Allow LIKE indexing optimization for non-ASCII locales
> 
> Yeah, he did.

Yes, wording updated and marked as done.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:13  Bruce Momjian <[email protected]>
  parent: Joe Conway <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Bruce Momjian @ 2003-08-08 17:13 UTC (permalink / raw)
  To: Joe Conway <[email protected]>; +Cc: Josh Berkus <[email protected]>; pgsql-hackers


OK, TODO updated.

---------------------------------------------------------------------------

Joe Conway wrote:
> Bruce Momjian wrote:
> >>>>>       o Add PL/PgSQL PROCEDURES that can return multiple values
> >>>>
> > 
> > Do you have TODO to add for this?  I removed the original one because,
> > as worded, it was complete.
> > 
> 
> Actually, now that I look at it again, it is referring to procedures, 
> not functions. Maybe just make it:
> 
> o Add capability to create and call PROCEDURES
> 
> Joe
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:22  Josh Berkus <[email protected]>
  parent: Bruce Momjian <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Josh Berkus @ 2003-08-08 17:22 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; Joe Conway <[email protected]>; +Cc: pgsql-hackers

Bruce,

> > Actually, now that I look at it again, it is referring to procedures, 
> > not functions. Maybe just make it:
> > 
> > o Add capability to create and call PROCEDURES

OK.   I need to put a full proposal behind this once 7.4 is in the can.  
However, this is largely academic until we get someone who really wants to 
take ownership of PL/pgSQL and has the coding skills (I have the former but 
not the latter).  

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:26  Tom Lane <[email protected]>
  parent: Bruce Momjian <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Tom Lane @ 2003-08-08 17:26 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: pgsql-hackers

Bruce Momjian <[email protected]> writes:
>>> * Use index to restrict rows returned by multi-key index when used with
>>> non-consecutive keys or OR clauses, so fewer heap accesses
>> 
>> Not sure what this means.

> This is a Vadim idea.  The idea was that if you had a multi-key index on
> col1,col2,col3, and you wanted to do a lookup on col1,col3, you could
> still use the index, and just run through all the matching col1 values
> looking for a matching col3 in the index, rather than going to the heap
> and looking for a col3 match?  Is this item worth keeping?

Hmm.  Maybe.  Might as well leave it there awhile longer.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-08 17:38  Joe Conway <[email protected]>
  parent: Josh Berkus <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Joe Conway @ 2003-08-08 17:38 UTC (permalink / raw)
  To: [email protected]; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers

Josh Berkus wrote:
>>>Actually, now that I look at it again, it is referring to procedures, 
>>>not functions. Maybe just make it:
>>>
>>>o Add capability to create and call PROCEDURES
> 
> OK.   I need to put a full proposal behind this once 7.4 is in the can.  
> However, this is largely academic until we get someone who really wants to 
> take ownership of PL/pgSQL and has the coding skills (I have the former but 
> not the latter).  
> 

This isn't isolated to just PL/pgSQL, just like the ability to create 
and call functions isn't. Support for PROCEDUREs in the backend is a 
prerequisite to being able to use PL/pgSQL to create procedures. It is 
necessary but not sufficient.

Similarly, if we want to support IN/OUT or named parameters, it isn't a 
PL/pgSQL issue per se, it is a general one.

Joe




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-12 22:25  Hannu Krosing <[email protected]>
  parent: Tom Lane <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Hannu Krosing @ 2003-08-12 22:25 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-hackers

Tom Lane kirjutas R, 08.08.2003 kell 16:56:
> Bruce Momjian <[email protected]> writes:
> >         o Add optional textual message to NOTIFY
> 
> Not done, but there is room in the FE/BE protocol now for something like
> this.

Were there any other changes to NOTIFY - there was talk about making
NOTIFY use some other structure instead of ordinary PG tables in
backend.

------
Hannu




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2003-08-13 00:53  Bruce Momjian <[email protected]>
  parent: Hannu Krosing <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2003-08-13 00:53 UTC (permalink / raw)
  To: Hannu Krosing <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers


No, I don't think any of that was done, particularly because there was
no discussion of the implemention.

---------------------------------------------------------------------------

Hannu Krosing wrote:
> Tom Lane kirjutas R, 08.08.2003 kell 16:56:
> > Bruce Momjian <[email protected]> writes:
> > >         o Add optional textual message to NOTIFY
> > 
> > Not done, but there is room in the FE/BE protocol now for something like
> > this.
> 
> Were there any other changes to NOTIFY - there was talk about making
> NOTIFY use some other structure instead of ordinary PG tables in
> backend.
> 
> ------
> Hannu
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* TODO Items
@ 2004-08-03 05:06  Greg Stark <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Greg Stark @ 2004-08-03 05:06 UTC (permalink / raw)
  To: pgsql-hackers


Bruce Momjian <[email protected]> writes:

> TODO item?

On that note several prior conversations I had here ended with WIBNI
conclusions that really ought to be TODO items, in my humble opinion. Two come
to mind off the top of my head resulting in:

. "SELECT * FROM x JOIN y USING (b) WHERE a=?" could use an index on y(a,b)
  since for a constant value of "a" the index traversal would be effectively
  equivalent just be "b". This could result in an efficient merge join
  avoiding an unnecessary sort.

. The semantics for row-value expressions is wrong. (a,b) < (x,y) should be
  true if a<x or if a=x and b<y. Currently it expands to a<x and b<y. 

. Fix row-value expression handling to not depend on the operator names and
  instead use btree access method strategy values instead, allowing row-value
  expressions on other operators with <,=,> behaviour (ie btree indexable
  behaviour).

. Allow multi-column indexes to be used to optimize row-value expressions. Ie,
  allow a btree index on a,b to be used to execute an expression like (a,b) <
  (x,y).

-- 
greg




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO Items
@ 2004-08-04 02:15  Bruce Momjian <[email protected]>
  parent: Greg Stark <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Bruce Momjian @ 2004-08-04 02:15 UTC (permalink / raw)
  To: Greg Stark <[email protected]>; +Cc: pgsql-hackers

Greg Stark wrote:
> 
> Bruce Momjian <[email protected]> writes:
> 
> > TODO item?
> 
> On that note several prior conversations I had here ended with WIBNI
> conclusions that really ought to be TODO items, in my humble opinion. Two come
> to mind off the top of my head resulting in:
> 
> . "SELECT * FROM x JOIN y USING (b) WHERE a=?" could use an index on y(a,b)
>   since for a constant value of "a" the index traversal would be effectively
>   equivalent just be "b". This could result in an efficient merge join
>   avoiding an unnecessary sort.
> 
> . The semantics for row-value expressions is wrong. (a,b) < (x,y) should be
>   true if a<x or if a=x and b<y. Currently it expands to a<x and b<y. 
> 
> . Fix row-value expression handling to not depend on the operator names and
>   instead use btree access method strategy values instead, allowing row-value
>   expressions on other operators with <,=,> behaviour (ie btree indexable
>   behaviour).
> 
> . Allow multi-column indexes to be used to optimize row-value expressions. Ie,
>   allow a btree index on a,b to be used to execute an expression like (a,b) <
>   (x,y).

I have not heard of any of those so I have not been actively excluding
them from the TODO list.  However, I need someone with optimizer
experience to make a recommendation.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO Items
@ 2004-08-04 03:25  Greg Stark <[email protected]>
  parent: Bruce Momjian <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Greg Stark @ 2004-08-04 03:25 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: Greg Stark <[email protected]>; pgsql-hackers


Bruce Momjian <[email protected]> writes:

> > . Allow multi-column indexes to be used to optimize row-value expressions. Ie,
> >   allow a btree index on a,b to be used to execute an expression like (a,b) <
> >   (x,y).
> 
> I have not heard of any of those so I have not been actively excluding
> them from the TODO list.  However, I need someone with optimizer
> experience to make a recommendation.

Well the row-value expression stuff comes out of a discussion just this week.
You could check messages on pgsql-performance with the subject "[PERFORM] best
way to fetch next/prev record based on index". In particular Tom's messages
from Wednesday the 28th might be relevant.

The optimization in the first one came up in a conversation that was quite a
bit older. I don't have that thread saved. It seems like an obvious
optimization if it can be done efficiently.

-- 
greg




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* TODO items..
@ 2006-04-22 07:15  Dhanaraj M <[email protected]>
  0 siblings, 2 replies; 46+ messages in thread

From: Dhanaraj M @ 2006-04-22 07:15 UTC (permalink / raw)
  To: pgsql-hackers

I saw the following in the TODO list. I am currently trying to work on them.
I could not understand clearly what needs to be done. Can anybody give me
the details for the following so that I can work on?

clients-psql
=========
1. Have psql show current values for a sequence
2. Fix psql's display of schema information (Neil)

Please explain me the current feature that is supported and  expected 
out of it.

Thanks
Dhanaraj



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 15:24  Alvaro Herrera <[email protected]>
  parent: Dhanaraj M <[email protected]>
  1 sibling, 2 replies; 46+ messages in thread

From: Alvaro Herrera @ 2006-04-22 15:24 UTC (permalink / raw)
  To: Dhanaraj M <[email protected]>; +Cc: pgsql-hackers

Dhanaraj M wrote:
> I saw the following in the TODO list. I am currently trying to work on them.
> I could not understand clearly what needs to be done. Can anybody give me
> the details for the following so that I can work on?
> 
> clients-psql
> =========
> 1. Have psql show current values for a sequence

This one means when you do a \dt of a sequence, add a column to display
the current value.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 15:37  Gevik Babakhani <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Gevik Babakhani @ 2006-04-22 15:37 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; +Cc: Dhanaraj M <[email protected]>; pgsql-hackers


> This one means when you do a \dt of a sequence, add a column to display
> the current value.
> 

Perhaps this one will be tricky because you will never be sure to get
the last sequence number when you query for it. The number could change
the moment the query is finished.




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 15:57  Martijn van Oosterhout <[email protected]>
  parent: Gevik Babakhani <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Martijn van Oosterhout @ 2006-04-22 15:57 UTC (permalink / raw)
  To: Gevik Babakhani <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Dhanaraj M <[email protected]>; pgsql-hackers

On Sat, Apr 22, 2006 at 05:37:28PM +0200, Gevik Babakhani wrote:
> 
> > This one means when you do a \dt of a sequence, add a column to display
> > the current value.
> > 
> 
> Perhaps this one will be tricky because you will never be sure to get
> the last sequence number when you query for it. The number could change
> the moment the query is finished.

So could the structure of a table or the definition of a function.
That's just a fact of life. Doesn't change the fact that it'd be
useful. You need nextval() to actually get a useful value for
queries...

Have a nice day,
-- 
Martijn van Oosterhout   <[email protected]>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.


Attachments:

  [application/pgp-signature] signature.asc (189B, ../../[email protected]/2-signature.asc)
  download

^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 16:08  Bruce Momjian <[email protected]>
  parent: Dhanaraj M <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Bruce Momjian @ 2006-04-22 16:08 UTC (permalink / raw)
  To: Dhanaraj M <[email protected]>; +Cc: pgsql-hackers

Dhanaraj M wrote:
> I saw the following in the TODO list. I am currently trying to work on them.
> I could not understand clearly what needs to be done. Can anybody give me
> the details for the following so that I can work on?
> 
> clients-psql
> =========
> 1. Have psql show current values for a sequence

Already answered.

> 2. Fix psql's display of schema information (Neil)
> 
> Please explain me the current feature that is supported and  expected 
> out of it.

Yes, this item was unclear.  I used text suggested by the author:

	http://archives.postgresql.org/pgsql-hackers/2004-12/msg00094.php

but that was not clear.  TODO is now:

        o Fix psql's \dn for various schema combinations (Neil)

          http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php

with a URL that has the details.  Thanks for pointing out the problem.

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 17:34  Tom Lane <[email protected]>
  parent: Bruce Momjian <[email protected]>
  0 siblings, 2 replies; 46+ messages in thread

From: Tom Lane @ 2006-04-22 17:34 UTC (permalink / raw)
  To: Bruce Momjian <[email protected]>; +Cc: Dhanaraj M <[email protected]>; pgsql-hackers

Bruce Momjian <[email protected]> writes:
> but that was not clear.  TODO is now:
>         o Fix psql's \dn for various schema combinations (Neil)
>           http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php
> with a URL that has the details.  Thanks for pointing out the problem.

You might want to also include a link to the thread start,
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00989.php

because the above message doesn't link there (I think our mail archiver
has trouble with following threads across month boundaries).

Also, the TODO item could be worded

	* Make psql's \d commands more consistent

because that's really what Neil is on about ...

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-22 18:17  Bruce Momjian <[email protected]>
  parent: Tom Lane <[email protected]>
  1 sibling, 0 replies; 46+ messages in thread

From: Bruce Momjian @ 2006-04-22 18:17 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Dhanaraj M <[email protected]>; pgsql-hackers


OK, done.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > but that was not clear.  TODO is now:
> >         o Fix psql's \dn for various schema combinations (Neil)
> >           http://archives.postgresql.org/pgsql-hackers/2004-11/msg00014.php
> > with a URL that has the details.  Thanks for pointing out the problem.
> 
> You might want to also include a link to the thread start,
> http://archives.postgresql.org/pgsql-hackers/2004-10/msg00989.php
> 
> because the above message doesn't link there (I think our mail archiver
> has trouble with following threads across month boundaries).
> 
> Also, the TODO item could be worded
> 
> 	* Make psql's \d commands more consistent
> 
> because that's really what Neil is on about ...
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
> 

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-23 15:06  Robert Treat <[email protected]>
  parent: Tom Lane <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Robert Treat @ 2006-04-23 15:06 UTC (permalink / raw)
  To: pgsql-hackers; +Cc: Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Dhanaraj M <[email protected]>

On Saturday 22 April 2006 13:34, Tom Lane wrote:
> Also, the TODO item could be worded
>
> 	* Make psql's \d commands more consistent
>
> because that's really what Neil is on about ...
>

like making \df only show user functions and \dfS show system functions, like 
all the other objects?  :-)

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-23 15:07  Robert Treat <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Robert Treat @ 2006-04-23 15:07 UTC (permalink / raw)
  To: pgsql-hackers; +Cc: Alvaro Herrera <[email protected]>; Dhanaraj M <[email protected]>

On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
> Dhanaraj M wrote:
> > I saw the following in the TODO list. I am currently trying to work on
> > them. I could not understand clearly what needs to be done. Can anybody
> > give me the details for the following so that I can work on?
> >
> > clients-psql
> > =========
> > 1. Have psql show current values for a sequence
>
> This one means when you do a \dt of a sequence, add a column to display
> the current value.

Um, I think you meant \ds right ? 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-23 15:42  Alvaro Herrera <[email protected]>
  parent: Robert Treat <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Alvaro Herrera @ 2006-04-23 15:42 UTC (permalink / raw)
  To: Robert Treat <[email protected]>; +Cc: pgsql-hackers; Dhanaraj M <[email protected]>

Robert Treat wrote:
> On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
> > Dhanaraj M wrote:
> > > I saw the following in the TODO list. I am currently trying to work on
> > > them. I could not understand clearly what needs to be done. Can anybody
> > > give me the details for the following so that I can work on?
> > >
> > > clients-psql
> > > =========
> > > 1. Have psql show current values for a sequence
> >
> > This one means when you do a \dt of a sequence, add a column to display
> > the current value.
> 
> Um, I think you meant \ds right ? 

Whatever.  I don't display sequences a lot myself ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-23 15:55  Stephen Frost <[email protected]>
  parent: Robert Treat <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Stephen Frost @ 2006-04-23 15:55 UTC (permalink / raw)
  To: Robert Treat <[email protected]>; +Cc: pgsql-hackers; Tom Lane <[email protected]>; Bruce Momjian <[email protected]>; Dhanaraj M <[email protected]>

* Robert Treat ([email protected]) wrote:
> On Saturday 22 April 2006 13:34, Tom Lane wrote:
> > Also, the TODO item could be worded
> >
> > 	* Make psql's \d commands more consistent
> >
> > because that's really what Neil is on about ...
> >
> 
> like making \df only show user functions and \dfS show system functions, like 
> all the other objects?  :-)

How about also having it show the owner (instead of having to use \df+
which gets huge...) and the permissions...  Or perhaps have a seperate
\dfp or something to get that information.  It's annoying to have to
either query the catalog directly or look through \df+ for why I can't
drop a given function.

	Thanks,

		Stephen


Attachments:

  [application/pgp-signature] signature.asc (189B, ../../[email protected]/2-signature.asc)
  download

^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items..
@ 2006-04-23 20:08  Robert Treat <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Robert Treat @ 2006-04-23 20:08 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers; Dhanaraj M <[email protected]>

On Sunday 23 April 2006 11:42, Alvaro Herrera wrote:
> Robert Treat wrote:
> > On Saturday 22 April 2006 11:24, Alvaro Herrera wrote:
> > > Dhanaraj M wrote:
> > > > I saw the following in the TODO list. I am currently trying to work
> > > > on them. I could not understand clearly what needs to be done. Can
> > > > anybody give me the details for the following so that I can work on?
> > > >
> > > > clients-psql
> > > > =========
> > > > 1. Have psql show current values for a sequence
> > >
> > > This one means when you do a \dt of a sequence, add a column to display
> > > the current value.
> >
> > Um, I think you meant \ds right ?
>
> Whatever.  I don't display sequences a lot myself ...

:-)  I double checked because I wasn't sure myself, but figured it was best to 
clarify rather than risk confusing the noobs. :-)

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* TODO items
@ 2009-07-02 21:28  Jaime Casanova <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Jaime Casanova @ 2009-07-02 21:28 UTC (permalink / raw)
  To: pgsql-hackers

Hi,

I guess todo items marked as [D] (Done) should be removed now... right?

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:29  Alvaro Herrera <[email protected]>
  parent: Jaime Casanova <[email protected]>
  0 siblings, 2 replies; 46+ messages in thread

From: Alvaro Herrera @ 2009-07-02 21:29 UTC (permalink / raw)
  To: Jaime Casanova <[email protected]>; +Cc: pgsql-hackers

Jaime Casanova wrote:
> Hi,
> 
> I guess todo items marked as [D] (Done) should be removed now... right?

Would there be some value in creating a new page TodoDone84 and moving
those items to it?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:35  Joshua D. Drake <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Joshua D. Drake @ 2009-07-02 21:35 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; +Cc: Jaime Casanova <[email protected]>; pgsql-hackers

On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
> Jaime Casanova wrote:
> > Hi,
> > 
> > I guess todo items marked as [D] (Done) should be removed now... right?
> 
> Would there be some value in creating a new page TodoDone84 and moving
> those items to it?

For historical record I could see benefit.

Joshua D. Drake


> 
> -- 
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
> 
-- 
PostgreSQL - XMPP: [email protected]
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997




^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:43  Andrew Dunstan <[email protected]>
  parent: Joshua D. Drake <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Andrew Dunstan @ 2009-07-02 21:43 UTC (permalink / raw)
  To: [email protected]; +Cc: Alvaro Herrera <[email protected]>; Jaime Casanova <[email protected]>; pgsql-hackers



Joshua D. Drake wrote:
> On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
>   
>> Jaime Casanova wrote:
>>     
>>> Hi,
>>>
>>> I guess todo items marked as [D] (Done) should be removed now... right?
>>>       
>> Would there be some value in creating a new page TodoDone84 and moving
>> those items to it?
>>     
>
> For historical record I could see benefit.
>
>   

Doesn't the wiki keep a page history? I don't see much point in keeping 
the old items in a current page.

cheers

andrew



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:50  Tom Lane <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  1 sibling, 1 reply; 46+ messages in thread

From: Tom Lane @ 2009-07-02 21:50 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; +Cc: Jaime Casanova <[email protected]>; pgsql-hackers

Alvaro Herrera <[email protected]> writes:
> Jaime Casanova wrote:
>> I guess todo items marked as [D] (Done) should be removed now... right?

> Would there be some value in creating a new page TodoDone84 and moving
> those items to it?

In the past we've figured that old TODO versions could be retrieved
from CVS history.  While that's still possible in the wiki environment,
it might be worth saving the old entries in a more easily accessible
fashion.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:52  Alvaro Herrera <[email protected]>
  parent: Andrew Dunstan <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Alvaro Herrera @ 2009-07-02 21:52 UTC (permalink / raw)
  To: Andrew Dunstan <[email protected]>; +Cc: [email protected]; Jaime Casanova <[email protected]>; pgsql-hackers

Andrew Dunstan wrote:
>
>
> Joshua D. Drake wrote:
>> On Thu, 2009-07-02 at 17:29 -0400, Alvaro Herrera wrote:
>>   
>>> Jaime Casanova wrote:
>>>     
>>>> I guess todo items marked as [D] (Done) should be removed now... right?
>>>>       
>>> Would there be some value in creating a new page TodoDone84 and moving
>>> those items to it?
>>
>> For historical record I could see benefit.
>
> Doesn't the wiki keep a page history?

Yes, but it is not as convenient.


> I don't see much point in keeping  the old items in a current page.

It is useful to point out to people: look at all the things we did in 8.4!

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 21:54  Jaime Casanova <[email protected]>
  parent: Tom Lane <[email protected]>
  0 siblings, 1 reply; 46+ messages in thread

From: Jaime Casanova @ 2009-07-02 21:54 UTC (permalink / raw)
  To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; pgsql-hackers

On Thu, Jul 2, 2009 at 4:50 PM, Tom Lane<[email protected]> wrote:
> Alvaro Herrera <[email protected]> writes:
>> Jaime Casanova wrote:
>>> I guess todo items marked as [D] (Done) should be removed now... right?
>
>> Would there be some value in creating a new page TodoDone84 and moving
>> those items to it?
>
> In the past we've figured that old TODO versions could be retrieved
> from CVS history.  While that's still possible in the wiki environment,
> it might be worth saving the old entries in a more easily accessible
> fashion.
>

We want to use the same format/sections like in the TODO?


-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* Re: TODO items
@ 2009-07-02 22:04  Tom Lane <[email protected]>
  parent: Jaime Casanova <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Tom Lane @ 2009-07-02 22:04 UTC (permalink / raw)
  To: Jaime Casanova <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; pgsql-hackers

Jaime Casanova <[email protected]> writes:
> We want to use the same format/sections like in the TODO?

Sure, why not?  Just copy the page and strip out the not-done items.
No reason to think hard here.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 46+ messages in thread

* [PATCH v1 2/4] autovac: resolve relopts before vacuuming
@ 2025-06-23 19:42  Nathan Bossart <[email protected]>
  0 siblings, 0 replies; 46+ messages in thread

From: Nathan Bossart @ 2025-06-23 19:42 UTC (permalink / raw)

---
 src/backend/commands/vacuum.c       |  7 ++--
 src/backend/postmaster/autovacuum.c | 52 +++++++++++++++++++++--------
 2 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c
index 33a33bf6b1c..0015b9ef4b0 100644
--- a/src/backend/commands/vacuum.c
+++ b/src/backend/commands/vacuum.c
@@ -421,7 +421,7 @@ ExecVacuum(ParseState *pstate, VacuumStmt *vacstmt, bool isTopLevel)
 	/*
 	 * Later, in vacuum_rel(), we check if a reloption override was specified.
 	 */
-	params.max_eager_freeze_failure_rate = vacuum_max_eager_freeze_failure_rate;
+	params.max_eager_freeze_failure_rate = -1.0;
 
 	/*
 	 * Create special memory context for cross-transaction storage.
@@ -2195,10 +2195,13 @@ vacuum_rel(Oid relid, RangeVar *relation, VacuumParams *params,
 	 * Check if the vacuum_max_eager_freeze_failure_rate table storage
 	 * parameter was specified. This overrides the GUC value.
 	 */
-	if (rel->rd_options != NULL &&
+	if (params->max_eager_freeze_failure_rate < 0 &&
+		rel->rd_options != NULL &&
 		((StdRdOptions *) rel->rd_options)->vacuum_max_eager_freeze_failure_rate >= 0)
 		params->max_eager_freeze_failure_rate =
 			((StdRdOptions *) rel->rd_options)->vacuum_max_eager_freeze_failure_rate;
+	else
+		params->max_eager_freeze_failure_rate = vacuum_max_eager_freeze_failure_rate;
 
 	/*
 	 * Set truncate option based on truncate reloption or GUC if it wasn't
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index f86c9fed853..3bedca971ff 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -2758,6 +2758,9 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map,
 		int			multixact_freeze_table_age;
 		int			log_min_duration;
 		AutoVacOpts *avopts = (relopts ? &relopts->autovacuum : NULL);
+		VacOptValue index_cleanup;
+		VacOptValue truncate;
+		double		max_eager_freeze_failure_rate;
 
 		/*
 		 * Calculate the vacuum cost parameters and the freeze ages.  If there
@@ -2790,6 +2793,39 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map,
 			? avopts->multixact_freeze_table_age
 			: default_multixact_freeze_table_age;
 
+		if (relopts)
+		{
+			switch (relopts->vacuum_index_cleanup)
+			{
+				case STDRD_OPTION_VACUUM_INDEX_CLEANUP_AUTO:
+					index_cleanup = VACOPTVALUE_AUTO;
+					break;
+				case STDRD_OPTION_VACUUM_INDEX_CLEANUP_ON:
+					index_cleanup = VACOPTVALUE_ENABLED;
+					break;
+				case STDRD_OPTION_VACUUM_INDEX_CLEANUP_OFF:
+					index_cleanup = VACOPTVALUE_DISABLED;
+					break;
+			}
+		}
+		else
+			index_cleanup = VACOPTVALUE_UNSPECIFIED;
+
+		if (relopts && relopts->vacuum_truncate_set)
+		{
+			if (relopts->vacuum_truncate)
+				truncate = VACOPTVALUE_ENABLED;
+			else
+				truncate = VACOPTVALUE_DISABLED;
+		}
+		else
+			truncate = VACOPTVALUE_UNSPECIFIED;
+
+		if (relopts && relopts->vacuum_max_eager_freeze_failure_rate >= 0)
+			max_eager_freeze_failure_rate = relopts->vacuum_max_eager_freeze_failure_rate;
+		else
+			max_eager_freeze_failure_rate = -1.0;
+
 		tab = palloc(sizeof(autovac_table));
 		tab->at_relid = relid;
 		tab->at_sharedrel = classForm->relisshared;
@@ -2806,13 +2842,8 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map,
 			(doanalyze ? VACOPT_ANALYZE : 0) |
 			(!wraparound ? VACOPT_SKIP_LOCKED : 0);
 
-		/*
-		 * index_cleanup and truncate are unspecified at first in autovacuum.
-		 * They will be filled in with usable values using their reloptions
-		 * (or reloption defaults) later.
-		 */
-		tab->at_params.index_cleanup = VACOPTVALUE_UNSPECIFIED;
-		tab->at_params.truncate = VACOPTVALUE_UNSPECIFIED;
+		tab->at_params.index_cleanup = index_cleanup;
+		tab->at_params.truncate = truncate;
 		/* As of now, we don't support parallel vacuum for autovacuum */
 		tab->at_params.nworkers = -1;
 		tab->at_params.freeze_min_age = freeze_min_age;
@@ -2822,12 +2853,7 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map,
 		tab->at_params.is_wraparound = wraparound;
 		tab->at_params.log_min_duration = log_min_duration;
 		tab->at_params.toast_parent = InvalidOid;
-
-		/*
-		 * Later, in vacuum_rel(), we check reloptions for any
-		 * vacuum_max_eager_freeze_failure_rate override.
-		 */
-		tab->at_params.max_eager_freeze_failure_rate = vacuum_max_eager_freeze_failure_rate;
+		tab->at_params.max_eager_freeze_failure_rate = max_eager_freeze_failure_rate;
 		tab->at_storage_param_vac_cost_limit = avopts ?
 			avopts->vacuum_cost_limit : 0;
 		tab->at_storage_param_vac_cost_delay = avopts ?
-- 
2.39.5 (Apple Git-154)


--QWBYbd5Ar5k8NvSv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v1-0003-autovac-combine-reloptions-correctly.patch



^ permalink  raw  reply  [nested|flat] 46+ messages in thread


end of thread, other threads:[~2025-06-23 19:42 UTC | newest]

Thread overview: 46+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-09-29 16:28 Re: [HACKERS] Re: TODO items Peter Eisentraut <[email protected]>
1999-09-29 17:21 ` Bruce Momjian <[email protected]>
2003-08-08 02:01 TODO items Bruce Momjian <[email protected]>
2003-08-08 03:36 ` Josh Berkus <[email protected]>
2003-08-08 04:00   ` Joe Conway <[email protected]>
2003-08-08 04:35     ` Josh Berkus <[email protected]>
2003-08-08 16:55       ` Bruce Momjian <[email protected]>
2003-08-08 17:01         ` Joe Conway <[email protected]>
2003-08-08 17:13           ` Bruce Momjian <[email protected]>
2003-08-08 17:22             ` Josh Berkus <[email protected]>
2003-08-08 17:38               ` Joe Conway <[email protected]>
2003-08-08 16:35     ` Bruce Momjian <[email protected]>
2003-08-08 16:33   ` Bruce Momjian <[email protected]>
2003-08-08 04:24 ` Joe Conway <[email protected]>
2003-08-08 14:11   ` Tom Lane <[email protected]>
2003-08-08 17:12     ` Bruce Momjian <[email protected]>
2003-08-08 16:53   ` Bruce Momjian <[email protected]>
2003-08-08 13:56 ` Tom Lane <[email protected]>
2003-08-08 17:09   ` Bruce Momjian <[email protected]>
2003-08-08 17:26     ` Tom Lane <[email protected]>
2003-08-12 22:25   ` Hannu Krosing <[email protected]>
2003-08-13 00:53     ` Bruce Momjian <[email protected]>
2004-08-03 05:06 TODO Items Greg Stark <[email protected]>
2004-08-04 02:15 ` Re: TODO Items Bruce Momjian <[email protected]>
2004-08-04 03:25   ` Re: TODO Items Greg Stark <[email protected]>
2006-04-22 07:15 TODO items.. Dhanaraj M <[email protected]>
2006-04-22 15:24 ` Re: TODO items.. Alvaro Herrera <[email protected]>
2006-04-22 15:37   ` Re: TODO items.. Gevik Babakhani <[email protected]>
2006-04-22 15:57     ` Re: TODO items.. Martijn van Oosterhout <[email protected]>
2006-04-23 15:07   ` Re: TODO items.. Robert Treat <[email protected]>
2006-04-23 15:42     ` Re: TODO items.. Alvaro Herrera <[email protected]>
2006-04-23 20:08       ` Re: TODO items.. Robert Treat <[email protected]>
2006-04-22 16:08 ` Re: TODO items.. Bruce Momjian <[email protected]>
2006-04-22 17:34   ` Re: TODO items.. Tom Lane <[email protected]>
2006-04-22 18:17     ` Re: TODO items.. Bruce Momjian <[email protected]>
2006-04-23 15:06     ` Re: TODO items.. Robert Treat <[email protected]>
2006-04-23 15:55       ` Re: TODO items.. Stephen Frost <[email protected]>
2009-07-02 21:28 TODO items Jaime Casanova <[email protected]>
2009-07-02 21:29 ` Alvaro Herrera <[email protected]>
2009-07-02 21:35   ` Joshua D. Drake <[email protected]>
2009-07-02 21:43     ` Andrew Dunstan <[email protected]>
2009-07-02 21:52       ` Alvaro Herrera <[email protected]>
2009-07-02 21:50   ` Tom Lane <[email protected]>
2009-07-02 21:54     ` Jaime Casanova <[email protected]>
2009-07-02 22:04       ` Tom Lane <[email protected]>
2025-06-23 19:42 [PATCH v1 2/4] autovac: resolve relopts before vacuuming Nathan Bossart <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox