2013/1/25 Tom Lane :
> Craig Ringer writes:
>> I'd love to see this fix still make it into 9.3.
>
> Working on it right now, actually.
Thank you all for collaboration
Best regards
Pavel
>
> regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Craig Ringer writes:
> I'd love to see this fix still make it into 9.3.
Working on it right now, actually.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On 01/25/2013 01:32 AM, Pavel Stehule wrote:
> Hello
>
> so there is updated version
>
> + some lines of doc
> + new regress tests
>
> there are no reply to my previous mail - so I choose
>
> concat(variadic null) ---> NULL
> concat(variadic '{}') ---> empty string
>
I'd love to see this fix still
Hello
so there is updated version
+ some lines of doc
+ new regress tests
there are no reply to my previous mail - so I choose
concat(variadic null) ---> NULL
concat(variadic '{}') ---> empty string
this behave should not be precedent for any other variadic "any"
function, because concat() and
2013/1/23 Tom Lane :
> Pavel Stehule writes:
>> next related example
>
>> CREATE OR REPLACE FUNCTION public.myleast(VARIADIC integer[])
>> RETURNS integer
>> LANGUAGE sql
>> AS $function$
>> select min(v) from unnest($1) g(v)
>> $function$
>
> The reason you get a null from that is that (1) unne
Pavel Stehule writes:
> next related example
> CREATE OR REPLACE FUNCTION public.myleast(VARIADIC integer[])
> RETURNS integer
> LANGUAGE sql
> AS $function$
> select min(v) from unnest($1) g(v)
> $function$
The reason you get a null from that is that (1) unnest() produces zero
rows out for ei
On Wed, Jan 23, 2013 at 2:28 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> what should be result of concat(variadic NULL::int[])
>> I enabled this use case, but what should be result?
>
> I think there are two somewhat defensible theories:
>
> (1) punt, and return NULL overall. So in this case
2013/1/23 Pavel Stehule :
> 2013/1/23 Tom Lane :
>> Pavel Stehule writes:
>>> what should be result of concat(variadic NULL::int[])
>>> I enabled this use case, but what should be result?
>>
>> I think there are two somewhat defensible theories:
>>
>> (1) punt, and return NULL overall. So in this
2013/1/23 Tom Lane :
> Pavel Stehule writes:
>> what should be result of concat(variadic NULL::int[])
>> I enabled this use case, but what should be result?
>
> I think there are two somewhat defensible theories:
>
> (1) punt, and return NULL overall. So in this case the variadic
> function would
Pavel Stehule writes:
> what should be result of concat(variadic NULL::int[])
> I enabled this use case, but what should be result?
I think there are two somewhat defensible theories:
(1) punt, and return NULL overall. So in this case the variadic
function would act as if it were STRICT. That
Hello
I sent a updated patch, but still I am not sure in one topic
> Also, I'm not sure that it's appropriate to throw an error if the given
> argument is null or not an array. Previous versions did not throw an
> error in such cases. Perhaps just fall back to behaving as if it
> weren't marke
sorry
I have to change wrong comment
Regards
Pavel
2013/1/22 Pavel Stehule :
> Hello
>
>
>
> 2013/1/22 Tom Lane :
>> Pavel Stehule writes:
>>> so here is rewritten patch
>>
>> I've applied the infrastructure parts of this, but not the changes
>> to format() and concat().
>>
>> Why are the for
Hello
2013/1/22 Tom Lane :
> Pavel Stehule writes:
>> so here is rewritten patch
>
> I've applied the infrastructure parts of this, but not the changes
> to format() and concat().
>
> Why are the format and concat patches so randomly different?
> Not only is the internal implementation complete
2013/1/22 Tom Lane :
> Pavel Stehule writes:
>> so here is rewritten patch
>
> I've applied the infrastructure parts of this, but not the changes
> to format() and concat().
>
> Why are the format and concat patches so randomly different?
> Not only is the internal implementation completely differ
Pavel Stehule writes:
> so here is rewritten patch
I've applied the infrastructure parts of this, but not the changes
to format() and concat().
Why are the format and concat patches so randomly different?
Not only is the internal implementation completely different for no
obvious reason, but the
Hello
2013/1/19 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/18 Tom Lane :
>>> The approach is also inherently seriously inefficient. ...
>
>> What is important - for this use case - there is simple and perfect
>> possible optimization - in this case "non variadic manner call of
>> variadic "any"
2013/1/21 Robert Haas :
> On Sun, Jan 20, 2013 at 10:01 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
Pavel is claiming it's okay for that to fall over if the array has
more than 100 elements. I disagree, not only for the specific case
On Sun, Jan 20, 2013 at 10:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>>> Pavel is claiming it's okay for that to fall over if the array has
>>> more than 100 elements. I disagree, not only for the specific case of
>>> CONCAT(), but with the
Robert Haas writes:
> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>> Pavel is claiming it's okay for that to fall over if the array has
>> more than 100 elements. I disagree, not only for the specific case of
>> CONCAT(), but with the more general implication that such a limitation
>> is go
2013/1/20 Robert Haas :
> On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane wrote:
>> I suppose this complaint is based on the idea that we could have
>> declared format() as format(fmt text, VARIADIC values text[]) if
>> only the argument matching rules were sufficiently permissive.
>> I disagree with th
2013/1/20 Robert Haas :
> On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
That's utter nonsense. Why wouldn't people expect concat(), for
example, to work for large (or even just moderate-sized) arrays?
>>
>>
On Sun, Jan 20, 2013 at 3:21 PM, Tom Lane wrote:
> I suppose this complaint is based on the idea that we could have
> declared format() as format(fmt text, VARIADIC values text[]) if
> only the argument matching rules were sufficiently permissive.
> I disagree with that though. For that to be any
On Sun, Jan 20, 2013 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>>> That's utter nonsense. Why wouldn't people expect concat(), for
>>> example, to work for large (or even just moderate-sized) arrays?
>
>> /me blinks.
>
>> What does tha
Robert Haas writes:
> On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule
> wrote:
>> We introduced VARIADIC "any" function. Motivation for this kind of
>> function was bypassing postgresql's coerce rules - and own rules
>> implementation for requested functionality. Some builtins function
>> does i
Hello
2013/1/20 Tom Lane :
> Robert Haas writes:
>> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>>> That's utter nonsense. Why wouldn't people expect concat(), for
>>> example, to work for large (or even just moderate-sized) arrays?
>
>> /me blinks.
>
>> What does that have to do with anyt
On 01/20/2013 01:37 PM, Robert Haas wrote:
On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule wrote:
We introduced VARIADIC "any" function. Motivation for this kind of
function was bypassing postgresql's coerce rules - and own rules
implementation for requested functionality. Some builtins functi
Robert Haas writes:
> On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>> That's utter nonsense. Why wouldn't people expect concat(), for
>> example, to work for large (or even just moderate-sized) arrays?
> /me blinks.
> What does that have to do with anything? IIUC, the question isn't
> whe
On Sat, Jan 19, 2013 at 3:27 PM, Tom Lane wrote:
>> disagree - non variadic manner call should not be used for walk around
>> FUNC_MAX_ARGS limit. So there should not be passed big array.
>
> That's utter nonsense. Why wouldn't people expect concat(), for
> example, to work for large (or even jus
On Sat, Jan 19, 2013 at 11:58 AM, Pavel Stehule wrote:
> We introduced VARIADIC "any" function. Motivation for this kind of
> function was bypassing postgresql's coerce rules - and own rules
> implementation for requested functionality. Some builtins function
> does it internally - but it is not p
2013/1/19 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/18 Tom Lane :
>>> The approach is also inherently seriously inefficient. ...
>
>> What is important - for this use case - there is simple and perfect
>> possible optimization - in this case "non variadic manner call of
>> variadic "any" functi
Pavel Stehule writes:
> 2013/1/18 Tom Lane :
>> The approach is also inherently seriously inefficient. ...
> What is important - for this use case - there is simple and perfect
> possible optimization - in this case "non variadic manner call of
> variadic "any" function" all variadic parameters w
2013/1/19 Stephen Frost :
> Pavel,
>
> While I certainly appreciate your enthusiasm, I don't think this is
> going to make it into 9.3, which is what we're currently focused on.
>
> I'd suggest that you put together a wiki page or similar which
> outlines how this is going to work and be im
Pavel,
While I certainly appreciate your enthusiasm, I don't think this is
going to make it into 9.3, which is what we're currently focused on.
I'd suggest that you put together a wiki page or similar which
outlines how this is going to work and be implemented and it can be
discussed fo
Hello
2013/1/18 Tom Lane :
> Stephen Frost writes:
>> [ quick review of patch ]
>
> On reflection it seems to me that this is probably not a very good
> approach overall. Our general theory for functions taking ANY has
> been that the core system just computes the arguments and leaves it
> to th
Hello
I try to recapitulate our design of variadic functions (sorry for my
English - really I have plan to learn this language better - missing
time).
We have two kinds of VARG functions: VARIADIC "any" and VARIADIC
anyarray. These kinds are really different although it is transparent
for final u
Stephen Frost writes:
> [ quick review of patch ]
On reflection it seems to me that this is probably not a very good
approach overall. Our general theory for functions taking ANY has
been that the core system just computes the arguments and leaves it
to the function to make sense of them. Why s
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Now I fixed these issues and I hope so it will work on all platforms
As mentioned on the commitfest application, this needs documentation.
That is not the responsibility of the committer; if you need help, then
please ask for it.
I've al
On Sat, Dec 1, 2012 at 1:14 PM, Pavel Stehule wrote:
> Hello
>
> >
> > Hi Pavel.
> >
> > I am trying to review this patch and on my work computer everything
> compiles
> > and tests perfectly. However, on my laptop, the regression tests don't
> pass
> > with "cache lookup failed for type XYZ" wher
2012/12/5 Heikki Linnakangas :
> On 05.12.2012 10:38, Pavel Stehule wrote:
>>
>> 2012/12/5 Heikki Linnakangas:
>>
>>> I get the same error. I'll mark this as "waiting on author" in the
>>> commitfest.
>>
>>
>> it was with new patch?
>>
>>
>> http://archives.postgresql.org/message-id/cafj8prdyxfxzcl
On 05.12.2012 10:38, Pavel Stehule wrote:
2012/12/5 Heikki Linnakangas:
I get the same error. I'll mark this as "waiting on author" in the
commitfest.
it was with new patch?
http://archives.postgresql.org/message-id/cafj8prdyxfxzcl2freslu-dpqaokou-ekky12tbzdo559pw...@mail.gmail.com
Ah, no,
2012/12/5 Heikki Linnakangas :
> On 30.11.2012 12:18, Vik Reykja wrote:
>>
>> I am trying to review this patch and on my work computer everything
>> compiles and tests perfectly. However, on my laptop, the regression tests
>> don't pass with "cache lookup failed for type XYZ" where XYZ is some
>> n
On 30.11.2012 12:18, Vik Reykja wrote:
I am trying to review this patch and on my work computer everything
compiles and tests perfectly. However, on my laptop, the regression tests
don't pass with "cache lookup failed for type XYZ" where XYZ is some number
that does not appear to be any type oid.
Hello
>
> Hi Pavel.
>
> I am trying to review this patch and on my work computer everything compiles
> and tests perfectly. However, on my laptop, the regression tests don't pass
> with "cache lookup failed for type XYZ" where XYZ is some number that does
> not appear to be any type oid.
>
> I don
On Sun, Nov 4, 2012 at 12:49 PM, Pavel Stehule wrote:
> Hello
>
> here is patch, that enables using a variadic parameter modifier for
> variadic "any" function.
>
> Motivation for this patch is consistent behave of "format" function,
> but it fixes behave of all this class variadic functions.
>
>
Hello
here is patch, that enables using a variadic parameter modifier for
variadic "any" function.
Motivation for this patch is consistent behave of "format" function,
but it fixes behave of all this class variadic functions.
postgres=> -- check pass variadic argument
postgres=> select format('%
45 matches
Mail list logo
