Pavel Stehule wrote:
> >OK, where are we on this patch?
>
> without changes. This task have to do anybody who better know PostgreSQL
> cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
I can update and
Pavel Stehule wrote:
> >OK, where are we on this patch?
>
> without changes. This task have to do anybody who better know PostgreSQL
> cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
> >---
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
Regards
Pavel
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> wr
OK, where are we on this patch?
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > >> This patch doesn't seem to cope with cases where the supplied tuple has
> > >> the wrong number of colu
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
>
>
> >
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > >> This patch doesn't seem to cope
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> This patch doesn't seem to cope with cases where the supplied tuple has
>> the wrong number of columns, and it doesn't look like it's being
careful
>> about dropped columns either. Also, that's a mighty bizarre-looking
>> choice of cache memory
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> This patch doesn't seem to cope with cases where the supplied tuple has
>> the wrong number of columns, and it doesn't look like it's being careful
>> about dropped columns either. Also, that's a mighty bizarre-looking
>> choice of cache memory contex
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch allows using any row expression in return statement and does
> transformation from untyped row to composite types if it's necessary.
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns, and i
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch allows using any row expression in return statement and does
> transformation from untyped row to composite types if it's necessary.
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns, and it
