According to the cargo book, any output from build scripts should be placed in the OUT_DIR directory. The current build script on main modifies assets in-place without respecting OUT_DIR, which might interfere with re-run logic from tools like cargo watch.

This PR brings back the OUT_DIR, but tries to minimize the number of files brought over on each rebuild. In practice (on my machine), this has eliminated some of the flakiness around cargo watch when working with the main branch, and has reduced fresh build times from ~30s to ~10s.

I'm noticing some weirdness in the split_with_scanner example. Malformed tokens seem to be getting dropped:

assert_eq!(
    pg_query::split_with_scanner("select 1; asdf; select 3;").unwrap(),
    vec!["select 1", "asdf", "select 3"],
); // fails: actually produces ["select 1", "select 3"]

Is this expected?

Resolves #5.

All of which are published in pg_query.h.

I've got a viable draft of these functions over at skalt/pg_query_wrapper, and I'd be happy to adapt and PR them to this repo.

This fixes accidental memory corruption leading to segfaults. When truncating a CTE we need to remove its nested target list truncation from the list of possibilities, otherwise we'll end up referencing an object that no longer exists. This PR uses std::mem::replace to return the previous SelectStmt so it can be removed from truncations before the next iteration.

Two other bugfixes:

• don't attempt truncating target lists when they're empty (accidentally adds a ... which just makes the query longer)
• if node truncations aren't sufficient, apply simple truncation as a fallback on the node-truncated string instead of on the source string

Review question: are there other truncation types where we could run into memory corruption? I tried subqueries in both SELECT and FROM and couldn't trigger another segfault.

The version number had already been updated to 0.7.0 in Cargo.toml, but it hasn't been used on crates.io yet: https://crates.io/crates/pg_query.

After merging this I will run cargo publish, and push a tag to this repo.

• fingerprint is affected by https://github.com/pganalyze/libpg_query/pull/141
• when an error occurs, normalize is returning early before pg_query_free_normalize_result was called

Truncate: Simplify VALUES(...) lists

Truncate: Correctly handle UPDATE and ON CONFLICT target lists

These target list fields support MultiAssignRef nodes, which are not
supported in regular SELECT target lists - thus requiring special handling.

The parallel test as currently written opens 10,000 threads that each call out to libpg_query at the same time. This error happens rarely, and so far only on CI.

https://github.com/pganalyze/pg_query.rs/runs/7419661487

LeakSanitizer:DEADLYSIGNAL
==4846==ERROR: LeakSanitizer: SEGV on unknown address 0x7f7999ae3ff8 (pc 0x5607592a63f4 bp 0x7f7595e56e60 sp 0x7f7595e565f0 T16383)
==4846==The signal is caused by a READ memory access.

This is likely more a problem with rust-analyzer than this library, but I want to raise awareness because this harms ergonomics and I'd like to understand if there's a work around you all have figured out.

e.g. Even though type is Result<Vec<Node::SelectStmt, Error>> and this code compiles correctly, rust-analyzer provides Result<Vec<{unknown}, Error>>

Anything that can be done to make this easier to work with?