Re: [HACKERS] Priorities for 6.6

Tom Lane wrote:
> 
> I don't know what people have had in mind for 6.6, but I propose that
> there ought to be three primary objectives for our next release:
> 
> 1. Eliminate arbitrary restrictions on tuple size.

This is not primary for me -:) 
Though, it's required by PL/pgSQL and so... I agreed that
this problem must be resolved in some way. Related TODO items:

* Allow compression of large fields or a compressed field type
* Allow large text type to use large objects(Peter)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I like it very much, though I don't like that LO are stored
in separate files. This is known as "multi-representation" feature
in Illustra.

> 2. Eliminate arbitrary restrictions on query size (textual
>    length/complexity that is).

Yes, this is quite annoyning thing.

> 3. Cure within-statement memory leaks, so that processing large numbers
>    of tuples in one statement is reliable.

Quite significant!

> All of these are fairly major projects, and it might be that we get
> little or nothing else done if we take these on.  But these are the
> problems we've been hearing about over and over and over.  I think
> fixing these would do more to improve Postgres than almost any other
> work we might do.
> 
> Comments?  Does anyone have a different list of pet peeves?  Is there
> any chance of getting everyone to subscribe to a master plan like this?

No chance -:))

This is what I would like to see in 6.6:

1. Referential integrity.
2. Dirty reads (will be required by 1. if we'll decide to follow  the way proposed by Jan - using rules, - though there
isanother  way I'll talk about later; dirty reads are useful anyway).
 
3. Savepoints (they are my primary wish-to-implement thing).
4. elog(ERROR) must return error-codes, not just messages!  This is very important for non-interactive application...
inconjuction with 3. -:)
 

Vadim