-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Extended computed fields #2578
Comments
I am actually tackling a similar issue, this would be ideal for us as well! |
Taking the idea from #915 (comment), a refinement to the above syntax would be: SEARCH /samples?select=*,$f.wrapped_pgroonga_highlight_html(content,$body.keywords)&id=eq.1
{
"keywords": ["fast", "PostgreSQL"]
} |
To avoid a more complex syntax for now, we could allow: GET /samples?select=*,wrapped_pgroonga_highlight_html&wrapped_pgroonga_highlight_html.keywords=["fast", "PostgreSQL"] or GET /samples?select=*,$f.wrapped_pgroonga_highlight_html&wrapped_pgroonga_highlight_html.keywords=["fast", "PostgreSQL"] |
Uh, this is interesting. I like the symmetry between passing arguments to RPCs and other functions: Whenever another query string parameter does not have an operator, it's an argument. This can be a top-level argument for the RPC, or a nested argument with function names. |
Yeah, I like that one too. Also with aliases it can be shorter: GET /samples?select=*,highlight:wrapped_pgroonga_highlight_html&highlight.keywords=["fast", "PostgreSQL"] This should be straightforward to support because it reuses existing parsers. |
select
I've just noticed that might conflict with the OpenAPI fix on #1970 (comment). So I think we should change the syntax to: GET /samples?select=*,highlight:wrapped_pgroonga_highlight_html&highlight.keywords=arg.["fast", "PostgreSQL"] (Note the I'm sure that will make the transition to operators to the left side easier #2066 |
Another use case for this is I'm also wondering if we could provide an "implicit computed field" for |
Problem
It's not possible to apply parameters to computed columns. If I'd want to use the pgroonga_highlight_html function like:
It's currently not possible to create a computed and apply the
['fast', 'PostgreSQL']
argument in:Proposal
Taking Wolfgang's syntax idea for aggregates(ref) and the SEARCH http method with underscore operators(ref), we could support:
With the extended computed column:
Drawbacks
Adding computed columns for each output expression inselect
has an impact on db state and could be considered a sort of "damage"(like mocks on unit tests, see ref). To avoid this we'd need to have a way to allowlist functions to call them directly onselect
.I think computed columns is the only safe way to expose transformation on select though. One can also define generic computed columns(taking an
anyelement
param) to avoid adding too much of these.The text was updated successfully, but these errors were encountered: