plpgsql, return can contains any expression
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
Regards
Pavel Stehule
_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
Attachments:
return.difftext/x-patch; name=return.diffDownload+478-105
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.
---------------------------------------------------------------------------
Pavel Stehule wrote:
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.Regards
Pavel Stehule_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Hello
I am sending corrected version.
regards
Pavel Stehule
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.---------------------------------------------------------------------------
Pavel Stehule wrote:
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.Regards
Pavel Stehule_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
Attachments:
return.diffapplication/binary; name=return.diffDownload+756-105
Import Notes
Resolved by subject fallback
I am going to need this in 24 hours or it might not make it into 8.2.
---------------------------------------------------------------------------
bruce wrote:
While this patch has new regression tests, it doesn't have new expected
output for it. Please update the patch to supply that. Thanks.---------------------------------------------------------------------------
Pavel Stehule wrote:
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.Regards
Pavel Stehule_________________________________________________________________
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Import Notes
Reply to msg id not found: | Resolved by subject fallback
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 doesn't look like it's being careful
about dropped columns either. Also, that's a mighty bizarre-looking
choice of cache memory context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?
regards, tom lane
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 doesn't look like it's being careful
about dropped columns either. Also, that's a mighty bizarre-looking
choice of cache memory context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?
I am sorry, Tom. But I don't understand. I can check number of columns,
ofcourse and I'll do it. What cache for temporary arrays do you mean?
Best regards
Pavel Stehule
_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?
I am sorry, Tom. But I don't understand. I can check number of columns,
ofcourse and I'll do it. What cache for temporary arrays do you mean?
I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth the obscurantism
and risk of bugs (are you sure natts can never change?).
BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.
regards, tom lane
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 beingcareful
about dropped columns either. Also, that's a mighty bizarre-looking
choice of cache memory context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?I am sorry, Tom. But I don't understand. I can check number of columns,
ofcourse and I'll do it. What cache for temporary arrays do you mean?I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth the obscurantism
and risk of bugs (are you sure natts can never change?).
No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean. and
little bit slow. This cache save 10%.
BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.
I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.
Thank you
Pavel
_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Pavel Stehule wrote:
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 beingcareful
about dropped columns either. Also, that's a mighty bizarre-looking
choice of cache memory context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?I am sorry, Tom. But I don't understand. I can check number of columns,
ofcourse and I'll do it. What cache for temporary arrays do you mean?I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth the obscurantism
and risk of bugs (are you sure natts can never change?).No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean. and
little bit slow. This cache save 10%.BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.Thank you
Pavel_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
OK, where are we on this patch?
---------------------------------------------------------------------------
Pavel Stehule wrote:
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 beingcareful
about dropped columns either. Also, that's a mighty bizarre-looking
choice of cache memory context in coerce_to_tuple ... but then again,
why are you bothering with a cache at all for temporary arrays?I am sorry, Tom. But I don't understand. I can check number of columns,
ofcourse and I'll do it. What cache for temporary arrays do you mean?I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth the obscurantism
and risk of bugs (are you sure natts can never change?).No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean. and
little bit slow. This cache save 10%.BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.Thank you
Pavel_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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" <pavel.stehule@hotmail.com> 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 context in coerce_to_tuple ... but then
again,
why are you bothering with a cache at all for temporary arrays?
I am sorry, Tom. But I don't understand. I can check number of
columns,
ofcourse and I'll do it. What cache for temporary arrays do you
mean?
I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth theobscurantism
and risk of bugs (are you sure natts can never change?).
No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean.and
little bit slow. This cache save 10%.
BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.Thank you
Pavel_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
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?
---------------------------------------------------------------------------
Pavel Stehule wrote:
"Pavel Stehule" <pavel.stehule@hotmail.com> 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 context in coerce_to_tuple ... but then
again,
why are you bothering with a cache at all for temporary arrays?
I am sorry, Tom. But I don't understand. I can check number of
columns,
ofcourse and I'll do it. What cache for temporary arrays do you
mean?
I thought that making coerce_to_tuple depend on estate->err_func was
pretty bizarre, and that there was no need for any "cache" at all for
arrays that need only live as long as the function runs. All you are
saving here is a palloc/pfree cycle, which is not worth theobscurantism
and risk of bugs (are you sure natts can never change?).
No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean.and
little bit slow. This cache save 10%.
BTW, if you want this patch to make it into 8.2, it needs to be fixed
and resubmitted *very* soon.I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 send simple version.
Regards
Pavel Stehule
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/