Re: 7.4 Wishlist - Mailing list pgsql-hackers

Christopher Kings-Lynne kirjutas R, 29.11.2002 kell 23:51:
> Hi guys,
> 
> Just out of interest, if someone was going to pay you to hack on Postgres
> for 6 months, what would you like to code for 7.4?
> 
> My ones are:
> 
> * Compliant ADD COLUMN
> * Integrated full text indexes
> * pg_dump dependency ordering
> 
> What would you guys do?  Even if it isn't feasible right now...

As I don't have a permanent job starting next year (my main employer
went bust), I'm planning to do more on postgreSQL anyway (at least until
I run out of money ;)

I have done some (or sometimes a lot of) brain-twitching on items in the
following list, but very little actual useful coding on most.

My personal todo list is:

"Application server support"
----------------------------
* better XML integration   - XML(*) aggregate function returning XML representation of subquery 
 - XML input/output to/from tables
 - XML searchable/indexable in fields)

* Overhaul of OO features (moving closer to SQL99)
 - type/table inheritance, 
   table inheritance would be done using SQL99's UNDER and would be   single inheritance, stored in single logical
table,possibly   subdivided in physical tables reusing our current huge table 1GB   split mechanisms
 
   type inheritance would be done using SQL99's LIKE and would be   multiple inheritance and would reuse as much as
possiblethe   current code for ADD/DROP/RENAME column
 
   - check constraints would apply to both type and table inheritance
   - pk/fk constraints would apply only to table inheritance
 - types as base of tables,
 - study feasibility of reference types,
 - dynamic invocation of table function on queries over hierarchies


* WITH (as part of query/view)

* WITH RECURSIVE for recursive queries

* better NOTIFY (with optional argument, using shared memory instead of tables)


General stuff
-------------

* making array types btree-indexable in a general way

* study feasibility of using SQL99's ARRAY syntax for arrays

Data warehousing
----------------
* bitmap indexes,
 - using bitmap "indexes" internally for star joins
 - real bitmap indexes
 - clustered multiple bitmap indexes especially   clustering on group of bitmap indexes

* clustering in general - specifying pages to be filled only to a certain percentage in clustered tables so that
updatedtuples can be placed near original ones if needed and parallel vacuum can then reclaim the space and keep table
clusteredwith less shuffling.
 

* OLAP features  - WINDOW clause, PARTITION BY  - GROUPING SETS, ROLLUP, CUBE, () 


WAL-based master-slave replication
----------------------------------

* if someone is not doing it (which I hope is not true ;)


UNICODE / Localization
----------------------

* UTEXT, UCHAR, UVARCHAR types using IBM's ICU, stored in UTF-16 or SCSU

* fast LIKE, ILIKE, REGEX code for UTF-16, possibly lifted from python2

* field-level localization, again using ICU


FE/BE protocol
--------------

all can be worked on independently

* try to find a better wire protocol from existing ones (X-window system seems simple enough, perhaps DB2's DRDA) or
fixthe existing one for high performance (mainly make sure that as big chunks as possible have preceeding length), make
iteasy to send out-of-band/optional data (Notifications, info on actual query performance (so one can visualize it for
user), ...)
 

* standardize a fire-level binary protocol for field types (currently whatever is stored is sent)

* work on making python use this protocol and port some postgres datatypes (initially timestamp/date/time and varbit)to
python
 


Really Dark Arts
------------------

* making backend internals available to a scripting language (for me it means python ;) for making more parts
(especiallyplanner/optimizer) more easily hackable
 

* using the stuff from previous point ;)


And that's all ;)

----------------
Hannu Krosing