Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It looks to me like we could eliminate the conflict if we invented a new
>> polymorphic pseudotype called "anynonarray" or some such, which would
>> act like anyelement *except* it would not match an array.
> ...
> On the contrary, I w
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe I am missing something, but the only such construct I see in
>> SQL2003 is concatenation of arrays of equal rank. There is nothing
>> corresponding to array_prepend or array_append.
> Well, I've never claimed to be particularly goo
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In the long run maybe we should choose some other name for the
array_append and array_prepend operators to avoid the confusion with
concatenation. It seems to me that "concatenation" normally implies
"stringing together sim
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I do have a plan B if people don't want to rename the operators, though.
>> It looks to me like we could eliminate the conflict if we invented a new
>> polymorphic pseudotype called "anynonarray" or some such, which would
>> act like a
Tom Lane wrote:
> I do have a plan B if people don't want to rename the operators, though.
> It looks to me like we could eliminate the conflict if we invented a new
> polymorphic pseudotype called "anynonarray" or some such, which would
> act like anyelement *except* it would not match an array.
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In the long run maybe we should choose some other name for the
>> array_append and array_prepend operators to avoid the confusion with
>> concatenation. It seems to me that "concatenation" normally implies
>> "stringing together similar o
> For example in 8.2 this is mapped to array_prepend:
>
> regression=# select 'x'::text || array['aa','bb','cc'];
>?column?
> --
> {x,aa,bb,cc}
> (1 row)
>
> but with the experimental code you get textcat:
>
> catany=# select 'x'::text || array['aa','bb','cc'];
> ?column?
> ---
> For example in 8.2 this is mapped to array_prepend:
>
> regression=# select 'x'::text || array['aa','bb','cc'];
>?column?
> --
> {x,aa,bb,cc}
> (1 row)
>
> but with the experimental code you get textcat:
>
> catany=# select 'x'::text || array['aa','bb','cc'];
> ?column?
> -
Tom Lane wrote:
The expressions
'abc' || 34
34 || 'abc'
would no longer work, with the following error message:
ERROR: 22P02: array value must start with "{" or dimension information
Hm, that's annoying. Not that the expressions fail --- we want them to
--- but that the error message is so
I wrote:
> I've been experimenting with another solution, which is to not add any
> weird error cases but instead add operators that will capture the
> problem cases back away from the anyelement||anyarray operators.
> My current prototype is
> create function catany(text, anyelement) returns text
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> we should do is make oper() specifically test for the case of operator
>> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
>> and throw a custom error message hinting that the other operand
>
I wrote:
> It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution. What I am currently thinking
> we should do is make oper() specifically test for the case of operator
> 349 with UNKNOWN left input, or operator 374 with UNKNOWN right input,
> and throw a c
"Tom Lane" <[EMAIL PROTECTED]> writes:
> So after reflecting on all that, it doesn't seem like a good idea to
> hack the type-coercion code to discriminate against matching unknown
> to anyarray. It looks to me like we have a very narrow problem and
> we should tailor a very narrow solution. Wha
Awhile back, I wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I've looked into cutting back on the implicit casts to text, which
>> exposed the following little gem.
>> The expressions
>> 'abc' || 34
>> 34 || 'abc'
>> would no longer work, with the following error message:
>> ERROR: 22
Am Dienstag, 27. Februar 2007 19:50 schrieb Tom Lane:
> Seems basically we'd want to not cast unknown to anyarray unless there
> is some additional bit of context suggesting that that's the right thing.
> But what should that extra requirement be? Can we go as far as not
> doing this cast implicit
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I've looked into cutting back on the implicit casts to text, which
> exposed the following little gem.
> The expressions
> 'abc' || 34
> 34 || 'abc'
> would no longer work, with the following error message:
> ERROR: 22P02: array value must start wit
I've looked into cutting back on the implicit casts to text, which
exposed the following little gem.
The expressions
'abc' || 34
34 || 'abc'
would no longer work, with the following error message:
ERROR: 22P02: array value must start with "{" or dimension information
That's because the best
17 matches
Mail list logo
