paupino / pg_parse Goto Github PK

There may be a way to reduce dependencies further as well as reduce layers of complexity, by extrapolating the pg source directly. This could perhaps leverage the ruby script that libpg_query already uses.

Summary:

For example queries with lists of values like INSERT INTO contacts.person(name, ssn) VALUES ($1, $2), parse() fails with an error of:

unknown variant `List`, expected one of <every variant of Node>

How to fix it:

As far as I can tell, this is a consequence of treating every List as an Option<Vec<Node>>, which works most of the time, but not in this specific case of parsing lists of params in ResTarget nodes.

I've included a hacky fix on my fork of pg_query.rs that special-cases List and creates a List struct with an items field, similar to how List is handled in the go library, and creates a separate List variant of Node. This solves the issue for the test case above.

If this ☝️ approach is acceptable, let me know and I'll put together a PR. A downside to this approach is the split treatment of List across the codebase: in most cases, it becomes an Option<Vec<Node>> (see the other existing parsing tests), but not in the case of e.g. VALUES lists. This doesn't bother me too much for my particular use-case, but would be surprising from someone used to the go implementation's approach of using List everywhere instead of Node[]. A different implementation might be to use a separate List type like the one I've hacked into the build script, but implement IntoIterator and ExactSizedIterator and friends to make working with List exactly like working with Vec<Node> for backwards-compatibility.

Thanks for creating this crate, and let me know how you'd like to proceed!

Implement version-sync to ensure versions in docs match published crate versions.

In theory this would probably need to be implemented directly in Rust through traits. It's worthwhile exploring the idea to see how difficult it'd be.