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
A train of fixes #1396
A train of fixes #1396
Conversation
@@ -185,6 +185,7 @@ def _bool( | |||
def _empty( | |||
o: None, | |||
repl_ctx: context.ReplContext, | |||
render_ctx: RenderContext, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're still using the Python repl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not usually.
@@ -646,10 +644,12 @@ def param_is_inherited( | |||
p for p in new_params | |||
if not param_is_inherited(new_schema, new, p) | |||
] | |||
add = delta.add_prerequisite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'd call right here -- the code would be simpler (albeit a bit more repetitive).
When the result of link target intersection in `Foo.bar[IS Spam]` is empty, make sure that link property references with that prefix result in a reference error instead of a crash.
Type intersections (`[IS Type]`) have `AT_MOST_ONE` cardinality, so we can forgo the refactoring fence enforcement on such paths if the immediate prefix of the intersection is visible above in the scope tree. This enables constructs like: SELECT Issue { references: { [IS Publication].authors: { name } ORDER BY @list_order } } and SELECT Issue { references[IS Publication]: { title } ORDER BY @list_order }
If a link value is computaed by a `FOR` expression over a nested `INSERT` make sure that the iterator scope is visible so that link property expressions have the correct context.
Set-returning functions defined in terms of an SQL function with `OUT` params should not use coldeflists. This is already handled by the normal set-returning function handler, but not by the `enumerate()` specialization.
There appears to be no reason for `FUNCTION` to be a reserved keyword.
Parenthesized statements are not valid in all contexts in Postgres so take care not to parethesize the top level `SELECT` statements.
A bunch of assorted fixes that accumulated in my various branches.