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
The proxy has been there since the beginning, because in v1 it dealt with the JSON structure returned by libpg_query's parse_sql() function.
Now that there is a set of concrete ast classes, maybe it would make sense to move the hierarchy tracking data (parent_node and parent_attribute) into the concrete nodes.
Will think about this for v4.
The text was updated successfully, but these errors were encountered:
This is the first step to implement issue #80, making it easier to get
rid of the old Node wrappers, whose main functionality in v3 was to keep
track of the "parent_node"/"parent_member" information.
Those wrappers were needed in v1 to hide the underlying JSON structures
emitted by libpg_query, making it possible to see them as generic Python
instances.
Version 3 obsoleted that by introducing a set of concrete AST classes,
and the wrappers were kept mainly for their ability to track the
parentship of each node, required by some of the printer functions.
Now they are gone, and everything works directly on AST classes, and the
printers use the new "ancestors" slot attached to each instance.
This implements issue #80.
The proxy has been there since the beginning, because in v1 it dealt with the
JSON
structure returned by libpg_query'sparse_sql()
function.Now that there is a set of concrete
ast
classes, maybe it would make sense to move the hierarchy tracking data (parent_node
andparent_attribute
) into the concrete nodes.Will think about this for v4.
The text was updated successfully, but these errors were encountered: