Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix(prqlc): improve requirement logic #5357

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.

Sign up for GitHub

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

Jump to bottom
Merged
max-sixty merged 7 commits into from
Jul 15, 2025
Merged

fix(prqlc): improve requirement logic #5357

max-sixty merged 7 commits into from
Jul 15, 2025

Conversation

@Fanaen
Copy link
Contributor

@Fanaen Fanaen commented Jul 9, 2025 •
edited
Loading

Fixes #5354

New result:

SELECT
  DISTINCT ON (
    EXTRACT(
      year
      from
        hire_date
    ),
    CONCAT(
      'Year ',
      EXTRACT(
        year
        from
          hire_date
      )
    )
  ) CONCAT(
    'Year ',
    EXTRACT(
      year
      from
        hire_date
    )
  ) AS year_label
FROM
  employees

About the refactoring

get_requirement is quite logic-heavy.

It made sense to separate column selection logic from complexities/SELECT status logic when there the case were simpler. The special cases with multiple complexities now outnumber general cases.

So I added Requirements: a newtype for Vec<Requirement>. It adds Complexity::Plain and select: false by default (the common case) and a few convenience methods to improve readbility.

It's a separate commit in case we want to split the PR.

@max-sixty
Copy link
Member

max-sixty commented Jul 10, 2025

thanks @Fanaen !

🚧 I'm not sure about testing strategy for this. Input is quite messy, not necessarily something we want in integration tests.

could we add the case as a simple inline test in prql/prqlc/prqlc/tests/integration/sql.rs? that makes it easy to understand the change when the code is open locally. if we can reduce the size of the example a bit then great, but not worth spending much time on making it totally minimal :)

@Fanaen Fanaen marked this pull request as ready for review July 11, 2025 16:57
@Fanaen
Copy link
Contributor Author

Fanaen commented Jul 15, 2025

Thanks @max-sixty! I added the inline test as suggested. The PR is ready for review!

@Fanaen
Copy link
Contributor Author

Fanaen commented Jul 15, 2025 •
edited
Loading

I've found that c1d7069, which I added in an attempt to get nicer SQL results, sometimes removes necessary columns for instance when referenced in a filter.

As it's not necessary for this fix, I've removed it.

@max-sixty
Copy link
Member

max-sixty commented Jul 15, 2025

great! thank you @Fanaen

(for transparency: I tried this out but haven't thought through each line of code, so if we need to iterate more we can do so, thank you for your recent contributions!)

@max-sixty max-sixty merged commit 6f63bd0 into PRQL:main Jul 15, 2025
36 checks passed
@vanillajonathan
Copy link
Collaborator

vanillajonathan commented Jul 15, 2025

Perhaps this ought to be mentioned in the CHANGELOG?

@max-sixty
Copy link
Member

max-sixty commented Jul 15, 2025

fine to add things to CHANGELOG but no strong requirement!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Computed columns and CTEs sometimes lead to missing column

3 participants

@Fanaen @max-sixty @vanillajonathan