-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to apply where condition when joining aws_ecr_image
#435
Comments
@kaidaguerre, Could you please look into this issue? |
Sorry for the delay @gabe-gfm , sure we'll look into this 👍 |
Perhaps this is related? |
Unfortunately, this was not resolved using the most aws plugin + postgres foreign data wrapper ( I did notice a particular log surface in my SQL client (not steampipe query):
From steampipe-postgres-fdw/fdw/fdw.c Line 328 in 41cf90e
|
I identified a better workaround for anyone else encountering this. You may specify
This example query gave me correctly filtered results. -- id_tag_repo is a mock for identifying interesting AWS container task definitions linked to ECR images
with id_tag_repo as
(
select 1 as id, to_jsonb('ZZZ'::text) as image_tag, 'my-repo-A' as image_repository
union
select 2 as id, '"latest"'::jsonb as image_tag, 'my-repo-B' as image_repository
union
select 3 as id, '"latest"'::jsonb as image_tag, 'my-repo-A' as image_repository
),
ecr_info as MATERIALIZED -- MATERIALIZED used to work around steampipe-fdw bug
(
select repository_name, image_tags
from aws_ecr_image
)
select
id_tag_repo.image_tag as target_tag
, id
, ecr.image_tags @> image_tag as is_tag_in_tags -- DEBUG: Matches where condition. Expect to see only true rows
, repository_name
, image_tags
from ecr_info ecr
join id_tag_repo
on ecr.repository_name = id_tag_repo.image_repository
where
ecr.image_tags @> image_tag |
@gabe-gfm good that you've found a workaround. I need to dig into why the JSON join condition is causing this issue |
Describe the bug
I'm seeing unexpected results using a
WHERE
clause on theaws_ecr_image
table. All rows from aJOIN
condition are being returned even though the query specifies most rows should be excluded by aWHERE
condition.This reproduction case involves joining a second table to provide a target label string for evaluating whether the target is in the JSONB list of
aws_ecr_image.image_tags
.Insightfully, I found the problem does not occur qhen querying local-table-copy of the
aws_ecr_image
table. This leads me to suspect it's a foreign-data-wrapper bug. But I'm not confident in which project the bug exists (steampipe-postgres-fdw
,steampipe-plugin-aws
, orsteampipe
?).Steampipe version
v0.21.4
Plugin version (
steampipe plugin list
)turbot/aws 0.132.0
To reproduce
aws_ecr_image
image_tag
inimage_tags
using the>@
JSONB inclusion test.Example query
is_tag_in_tags
column may show true, false, null, but the where condition should limit it to only true.Buggy Results:
![image](https://private-user-images.githubusercontent.com/156363929/312292959-abc60ca9-4562-47a7-90a6-e64bc0601b52.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxNjcxMjQsIm5iZiI6MTczOTE2NjgyNCwicGF0aCI6Ii8xNTYzNjM5MjkvMzEyMjkyOTU5LWFiYzYwY2E5LTQ1NjItNDdhNy05MGE2LWU2NGJjMDYwMWI1Mi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMFQwNTUzNDRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yZDIyMjBiNjczMjU5ZjJmMjUxN2M2YTE0NDBmYTY0YWM2ZTc2MjIzOGQ5YjlkYzkzYjE0NjVkNzlkNWU3ZDA4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.VV8_eve3zfSZI2I5u6ucbLxEX3MYXDqxUjN2kor4XMo)
Expected behavior
The expected behavior can be easily demonstrated by running the same query on a local copy of the a foreign-data-wrapper table.
from ecr_copy
rather thanfrom aws_ecr_image
is_tag_in_tags
column shows true.Expected results:
![image](https://private-user-images.githubusercontent.com/156363929/312293341-5af98ddc-0f79-4f89-ab77-8756703f4006.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxNjcxMjQsIm5iZiI6MTczOTE2NjgyNCwicGF0aCI6Ii8xNTYzNjM5MjkvMzEyMjkzMzQxLTVhZjk4ZGRjLTBmNzktNGY4OS1hYjc3LTg3NTY3MDNmNDAwNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjEwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIxMFQwNTUzNDRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kMGFjZDljZThlZjhlMWFkNjc1M2JjMzE3ZGE3OTM4OGY0ZDY3M2M1MDhjMTcwOWQ3YzYxMmFkNDM1NDViNjljJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.fArScAV9oe8uTGz8IElTrQbgzEA_p5TbEPfG_8f6aZ8)
Additional context
I found it difficult to discover how I might locally rebuild
steampipe-ftw
or the project's postgres container to investigate if this could be a known postgres bug.The text was updated successfully, but these errors were encountered: