> Probably the fix is not hard, but it is almost the same situation as the
> UNION case. The result of your code is not deterministic
>
> If there are more different ti_resource_id then some values can be randomly
> ignored - when hash agg is used.
>
> The safe fix should be
>
> _resource_id := (SELECT ti_resource_id
> FROM tabk.resource_timeline
> WHERE ti_a2_id = _ab2_id
> AND ti_type = 'task');
>
> and you get an exception if some values are ignored. Or if you want to
> ignore some values, then you can write
>
> _resource_id := (SELECT MIN(ti_resource_id) -- or MAX
> FROM tabk.resource_timeline
> WHERE ti_a2_id = _ab2_id
> AND ti_type = 'task');
>
> Using DISTINCT is not a good solution.
>
in my usecase it was perfectly fine, because there is a constraint ensuring that here can never be more than on
ti_resource_idat any given time for a given _ab2_id.
also, whenever there would be more data ( for example if the constraint trigger would have a bug ) you will get an
errorlike this:
create table a ( t int );
insert into a values (1),(2);
do $$
declare _t int;
begin
_t := distinct t from a;
end $$;
Query failed: ERROR: query "SELECT distinct t from a" returned more than one row
CONTEXT: PL/pgSQL function inline_code_block line 4 at assignment
no doubt, that this piece of code might not look optimal at first glance, but i like my code to fail fast. because with
themin() approach, you will not notice, that the constraint trigger is not doing its job, until you get other strange
sideeffectsdown the road.
richard