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