Uhm. oops. I'll just crawl back under this rock for a bit longer before I
speak on this topic again. sorry.
--
greg
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Greg Stark wrote:
So in this case if argL or argR are functions or other expressions with
unknown types it tries to figure out how to interpret them to produce the type
it's looking for. In other words, what type those expressions are depends on
what the expression expects. What would you do with "
Greg Stark <[EMAIL PROTECTED]> writes:
> That would be nice and simple and clean, except that postgres's type system
> doesn't work that way. It works backwards from every other language. Instead
> of every variable and function return value having a rigid type and forcing
> the interpretation of t
Joe Conway <[EMAIL PROTECTED]> writes:
> I wrestled with the same issue last year.
>
> Offhand I don't know how hard it would be to do, but I wonder if when we see:
>
>argL IN (argR)
>
> we might be able to determine if argL and argR are of the same type or if argR
> is an array of argL, a
Tom Lane wrote:
[ wanders away trying to remember that quote about "foolish consistency" ]
http://www.bartleby.com/59/3/foolishconsi.html
"A foolish consistency is the hobgoblin of little minds"
A great person does not have to think consistently from one day to the
next. This remark comes from
Joe Conway <[EMAIL PROTECTED]> writes:
> But then we need to decide, what happens when we see:
>argL IN (argR1, argR2, ...)
> and argRn data type is an array of argL data type? Do we check all the
> argRn elements individually and return true if any of them equal argL?
> I'd guess so.
This s
Dennis Bjorklund wrote:
The only reason I brought it up was that to me ANY and IN are pretty much
the same kind of operator. Up until now I thought that IN really was the
same as =ANY, but it isn't. I don't like that but of course I have to
accept it. I would rather have had some elem function/oper
On Tue, 2 Mar 2004, Joe Conway wrote:
> regression=# select 1 where array[1] in (array[1]);
> ?column?
> --
> 1
> (1 row)
>
> regression=# select 1 where array[1] in (array[1,2]);
> ?column?
> --
> (0 rows)
The only reason I brought it up was that to me ANY and IN ar
Tom Lane wrote:
I don't have a strong opinion about "IN array", but am worried that
allowing it would create ambiguity about which interpretation is meant.
Is the left-hand side supposed to be compared against the whole array or
each array member?
That was exactly the problem. IN (array) does work
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Hmm, the draft seems to be broken since I can only find ANY defined for
> subqueries in other sections, and not for value lists. Strange but not
> uncommon. Now I don't know what the standard says about this. Maybe
> someone with the sql99 spec wants
The IN and ANY constructs works with different kinds of collections to the
right. This is the current situation:
SUB QUERY VALUE LIST ARRAY
IN X X
ANY X X
The SQL standard specifies that = ANY should be equivalent to IN
11 matches
Mail list logo
