>>> On Tue, Dec 19, 2006 at 9:58 AM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm having trouble seeing how it is a useful construct in the
context
>> of a scalar subquery. A non- standard extension should be useful in
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm having trouble seeing how it is a useful construct in the context
> of a scalar subquery. A non-standard extension should be useful in some
> way.
There is 0 chance that we'd disallow it at the top level after allowing
it all these years. And pr
>>> On Tue, Dec 19, 2006 at 9:23 AM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> It's easy to see how it resolves the column references; but the
syntax
>> is still not compliant with the SQL standard. The FROM clause is
>>
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> It's easy to see how it resolves the column references; but the syntax
> is still not compliant with the SQL standard. The FROM clause is
> required. We could call it a PostgreSQL extension, but I'm curious if
> anyone actually finds it useful.
You'
>>> On Mon, Dec 18, 2006 at 11:48 PM, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The reason there's no error thrown is that the reference to mov_id
in
> the sub- SELECT is a perfectly legal outer reference to the mov_id
column
> available from the upper SELECT. If th
You are right as usual My apologies yet again. I have wrongly
assumed that the lower statement would run first since it is enclosed in
parenthesis.
On Tue, 2006-12-19 at 00:48 -0500, Tom Lane wrote:
> mike <[EMAIL PROTECTED]> writes:
> > Pgsql does not throw an error (at least prior to 8.2)
mike <[EMAIL PROTECTED]> writes:
> Pgsql does not throw an error (at least prior to 8.2) if the column
> referenced by the select statement for the IN clause does not exist.
My, there's a lot of misinformation in this thread.
The reason there's no error thrown is that the reference to mov_id in
t
Also check that the mov_id column exists in the table/view that you are
running the SELECT DISTINCT against.
Pgsql does not throw an error (at least prior to 8.2) if the column
referenced by the select statement for the IN clause does not exist. It
will run only SELECT * FROM movies.names in this
"Thomas H." <[EMAIL PROTECTED]> writes:
> SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
> mov_name like '%, %' LIMIT 2)
> the subselect is missing a FROM . in that case, pgsql seemed to also
> ignore the LIMIT 2
It didn't "ignore" anything. Each execution of the sub-
>> SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id
>> WHERE
>> mov_name like '%, %' LIMIT 2)
IF the subquery would only have returned 2 ids, then there would be at
most
like +/-10 records affected. each mov_id can hold one or more (usuals up
to
5) names. but here, the subqu
On 12/18/06, Thomas H. <[EMAIL PROTECTED]> wrote:
>> oups. just thumbled over this as well when i forgot a FROM in a WHERE ...
>> IN
>> () and damaged quite some data. the bad query went like this:
>>
>> SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
>> mov_name like
oups. just thumbled over this as well when i forgot a FROM in a WHERE ...
IN
() and damaged quite some data. the bad query went like this:
SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
mov_name like '%, %' LIMIT 2)
the subselect is missing a FROM . in that case, p
On 12/18/06, Thomas H. <[EMAIL PROTECTED]> wrote:
>> > Is it a bug? If no, maybe to produce warning in such cases?
oups. just thumbled over this as well when i forgot a FROM in a WHERE ... IN
() and damaged quite some data. the bad query went like this:
SELECT * FROM movies.names WHERE mov_
> Is it a bug? If no, maybe to produce warning in such cases?
oups. just thumbled over this as well when i forgot a FROM in a WHERE ... IN
() and damaged quite some data. the bad query went like this:
SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE
mov_name like
On 12/19/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> Following query is considered as correct, no "missing from" error has
> been reported (so, entire table will be updated and "on update"
> triggers will be fired for every row):
>
> update item set obj_id = obj_id
> where obj_id in (sele
ok, sorry, I've realized that it's yet another example of "outer
reference", Tom will say "read any SQL book" again :-)
http://archives.postgresql.org/pgsql-bugs/2006-12/msg00115.php
On 12/19/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
Following query is considered as correct, no "missin
Following query is considered as correct, no "missing from" error has
been reported (so, entire table will be updated and "on update"
triggers will be fired for every row):
update item set obj_id = obj_id
where obj_id in (select obj_id where item_point is null order by
obj_modified limit 10)
Is
17 matches
Mail list logo
