-
Notifications
You must be signed in to change notification settings - Fork 13
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
What are the goals of the nodes()
functions?
#31
Comments
Yes, There isn't a foolproof way to know if we've covered all nested node types, but feel free to open a PR replacing the |
absporl
added a commit
to absporl/pg_query.rs
that referenced
this issue
Jul 23, 2024
This allows walking over all nodes in the AST, instead of just a limited subset as in the current `nodes()` function. See pganalyze#31 The implementation uses static code generation in `build.rs`. The protobuf definitions are parsed, and a graph of all Message types is constructed. All NodeRef types are given an `unpack()` function, that recursively calls `unpack()` on all relevant fields (i.e., the fields that have a Node type, or that have a type that eventually has a Node type as a field). The result is guaranteed to visit all nodes. The code generation mechanism is maybe also useful to replace parts of the codebase that currently need to be manually hardcoded. Adds prost, prost-types and heck to the build dependencies, and updates the prost dependency version.
absporl
added a commit
to absporl/pg_query.rs
that referenced
this issue
Jul 24, 2024
This allows walking over all nodes in the AST, instead of just a limited subset as in the current `nodes()` function. See pganalyze#31 The implementation uses static code generation in `build.rs`. The protobuf definitions are parsed, and a graph of all Message types is constructed. All NodeRef types are given an `unpack()` function, that recursively calls `unpack()` on all relevant fields (i.e., the fields that have a Node type, or that have a type that eventually has a Node type as a field). The result is guaranteed to visit all nodes. The code generation mechanism is maybe also useful to replace parts of the codebase that currently need to be manually hardcoded. Adds prost, prost-types and heck to the build dependencies, and updates the prost dependency version.
absporl
added a commit
to absporl/pg_query.rs
that referenced
this issue
Jul 24, 2024
This allows walking over all nodes in the AST, instead of just a limited subset as in the current `nodes()` function. See pganalyze#31 The implementation uses static code generation in `build.rs`. The protobuf definitions are parsed, and a graph of all Message types is constructed. All NodeRef types are given an `unpack()` function, that recursively calls `unpack()` on all relevant fields (i.e., the fields that have a Node type, or that have a type that eventually has a Node type as a field). The result is guaranteed to visit all nodes. The code generation mechanism is maybe also useful to replace parts of the codebase that currently need to be manually hardcoded. Adds prost, prost-types and heck to the build dependencies, and updates the prost dependency version.
absporl
added a commit
to absporl/pg_query.rs
that referenced
this issue
Jul 24, 2024
This allows walking over all nodes in the AST, instead of just a limited subset as in the current `nodes()` function. See pganalyze#31 The implementation uses static code generation in `build.rs`. The protobuf definitions are parsed, and a graph of all Message types is constructed. All NodeRef types are given an `unpack()` function, that recursively calls `unpack()` on all relevant fields (i.e., the fields that have a Node type, or that have a type that eventually has a Node type as a field). The result is guaranteed to visit all nodes. The code generation mechanism is maybe also useful to replace parts of the codebase that currently need to be manually hardcoded. Adds prost, prost-types and heck to the build dependencies, and updates the prost dependency version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both
NodesEnum::nodes()
andprotobuf::ParseResult::nodes()
don't have documentation, although the latter hints// Note: this doesn't iterate over every possible node type, since we only care about a subset of nodes.
Is the goal just to provide a helper function to extract
ParseResult::{warnings, tables, aliases, cte_names, functions}
?I'm trying to do some more detailed parsing of a statement tree, and would like a "visitor" pattern. I need more information than
scan()
provides. Is it useful to extend thenodes
function?The text was updated successfully, but these errors were encountered: