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 is another
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...
in conjuction with 3. -:)

Vadim