On Thu, Dec 6, 2012 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/12/5 Tom Lane t...@sss.pgh.pa.us:
Asif Rehman asifr.reh...@gmail.com writes:
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
I looked at this
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 6, 2012 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
but we can limit a implicit coercion in tupconvert via new parameter -
because we would to forward plpgsql behave just from this direction.
Then when this parameter - maybe
On Thu, Dec 6, 2012 at 1:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm against putting I/O coercion semantics into tupconvert, period. Ever.
If plpgsql wants that behavior rather than something more consistent
with the rest of the system, it needs to implement it for itself.
I'm sure that can
Robert Haas robertmh...@gmail.com writes:
Are you going to commit a stripped-down version of the patch?
I set it back to waiting on author --- don't know if he wants to
produce a stripped-down version with no type coercions, or try to use
cast-based coercions.
regards,
Hi,
I have attached the stripped-down version. I will leave the type coercions
support for a separate patch.
Regards,
--Asif
On Fri, Dec 7, 2012 at 1:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Are you going to commit a stripped-down version of the
Asif Rehman asifr.reh...@gmail.com writes:
I have attached the stripped-down version. I will leave the type coercions
support for a separate patch.
OK, I'll take a look at this one.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Asif Rehman asifr.reh...@gmail.com writes:
I have attached the stripped-down version. I will leave the type coercions
support for a separate patch.
Applied with assorted corrections.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Thanks.
Regards,
--Asif
On Fri, Dec 7, 2012 at 9:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Asif Rehman asifr.reh...@gmail.com writes:
I have attached the stripped-down version. I will leave the type
coercions
support for a separate patch.
Applied with assorted corrections.
2012/12/4 Asif Rehman asifr.reh...@gmail.com:
Hi,
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
postgres=# select sum(a) from generate_series(1,3000) g(i), lateral foo(i)
as (a numeric, b numeric);
sum
--
Asif Rehman asifr.reh...@gmail.com writes:
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
I looked at this patch briefly. It seems to me to be completely
schizophrenic about the coercion rules. This bit:
-
2012/12/5 Tom Lane t...@sss.pgh.pa.us:
Asif Rehman asifr.reh...@gmail.com writes:
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
I looked at this patch briefly. It seems to me to be completely
schizophrenic about the
Hello
I fully agree with Asif's arguments
previous tupconvert implementation was really strict - so using
enhanced tupconver has very minimal impact for old user - and I
checked same speed for plpgsql function - patched and unpatched pg.
tested
CREATE OR REPLACE FUNCTION public.foo(i integer)
Hi,
Here is the updated patch. I overlooked the loop, checking to free the
conversions map. Here are the results now.
postgres=# select sum(a) from generate_series(1,3000) g(i), lateral foo(i)
as (a numeric, b numeric);
sum
--
303000.0
(1 row)
postgres=# select sum(a) from
Hi,
Thanks for the review. Please see the updated patch.
Hmm. We're running an I/O cast during do_tup_convert() now, and look
up the required functions for each tuple. I think if we're going to
support this operation at that level, we need to look up the necessary
functions at
Asif Rehman escribió:
Hi,
I have tried to solve this issue. Please see the attached patch.
With this patch, any expression is allowed in the return statement. For any
invalid expression an error is generated without doing any special handling.
When a row expression is used in the return
Hi,
I have tried to solve this issue. Please see the attached patch.
With this patch, any expression is allowed in the return statement. For any
invalid expression an error is generated without doing any special handling.
When a row expression is used in the return statement then the resultant
Hi,
PL/pgsql seems to have a strange restriction regarding RETURN.
Normally, you can write RETURN expression. But if the function
returns a row type, then you can only write RETURN variable or
RETURN NULL.
rhaas=# create type xyz as (a int, b int);
CREATE TYPE
rhaas=# select row(1,2)::xyz;
Robert Haas robertmh...@gmail.com writes:
ERROR: RETURN must specify a record or row variable in function returning row
Off the top of my head, I can't think of any reason for this
restriction, nor can I find any code comments or anything in the
commit log which explains the reason for it.
2012/10/8 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
ERROR: RETURN must specify a record or row variable in function returning
row
Off the top of my head, I can't think of any reason for this
restriction, nor can I find any code comments or anything in the
Pavel Stehule pavel.steh...@gmail.com writes:
2012/10/8 Tom Lane t...@sss.pgh.pa.us:
Laziness, probably. Feel free to have at it.
I wrote patch some years ago. It was rejected from performance reasons
- because every row had to be casted to resulted type.
I don't recall that patch in any
20 matches
Mail list logo
