At 21:21 9/07/00 -0400, Tom Lane wrote:
>
>> Sounds perfect to me...
>
>Note that it would not meet your expectation that
This seems OK; the 'update...from' syntax does also seemingly implies that
the rows affected will only be those rows that match the predicate, so your
interpretation is probab
At 14:35 9/07/00 -0400, Tom Lane wrote:
>
>so the construct is definitely not SQL-compliant. Maybe we should just
>forbid it. However, if you are joining against another table (which
>itself is not an SQL feature) then it seems like there is some potential
>use in it. What do people think of my
Philip Warner <[EMAIL PROTECTED]> writes:
>> What do people think of my implicit-GROUP-BY-ctid idea?
>> That would basically say that the aggregate is computed over all the
>> tuples that join to a single target tuple.
> Sounds perfect to me...
Note that it would not meet your expectation that
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> If you use min(x) or max(x) frequently, isn't it best to make a
> trigger that intercepts x on insert and update, then check it and
> store it somewhere rather than scanning for it everytime?
I believe that's exactly what the original questioner is
On Fri, 07 Jul 2000, Tom Lane wrote:
> Chris Bitmead <[EMAIL PROTECTED]> writes:
> UPDATE foo
> SET bar = (SELECT min(f1) FROM othertab
> WHERE othertab.keycol = foo.keycol)
> WHERE condition-determining-which-foo-rows-to-update
> if you wanted to use an aggregat
Chris Bitmead <[EMAIL PROTECTED]> writes:
> Another observation is that if the WHERE clause is successful, it seems
> to update the first record in the target relation that it finds which is
> a pretty random result.
Wouldn't surprise me --- leastwise, you will get a random one of the
input ctid
Another observation is that if the WHERE clause is successful, it seems
to update the first record in the target relation that it finds which is
a pretty random result.
pghack=# create table e(ee text, eee integer);
CREATE
pghack=# create table f(ff text, fff integer);
CREATE
pghack=# insert int
