You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+86Lines changed: 86 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -231,6 +231,92 @@ If the parse fails, `PgParser` will return an `error` of type `ParseError` with
231
231
232
232
**Note:** This is relative to the entire SQL string, not just the statement being parsed or line numbers within a statement. If you are parsing a multi-statement query, the position will be relative to the entire query string, where newlines are counted as single characters.
233
233
234
+
### Utility functions
235
+
236
+
The following utility functions are available to help with parsing:
237
+
238
+
#### `unwrapNode()`
239
+
240
+
Extracts the node type and nested value while preserving type information.
**Background:** The AST structure produced by Postgres ([libpg_query](https://github.com/pganalyze/libpg_query)) can be complex due to nesting. For example, a `SELECT` statement is represented as:
253
+
254
+
```typescript
255
+
{
256
+
version: 170004,
257
+
stmts: [
258
+
{
259
+
stmt: {
260
+
SelectStmt: {
261
+
targetList: [ ... ],
262
+
fromClause: [ ... ],
263
+
whereClause: { ... },
264
+
...
265
+
}
266
+
}
267
+
}
268
+
]
269
+
}
270
+
```
271
+
272
+
In order to determine which statement type is being parsed, you'd have to use the `in` operator to check for the presence of a specific key:
0 commit comments