implement alter default privileges#2782
Open
jennifersp wants to merge 3 commits into
Open
Conversation
Contributor
|
Contributor
|
Ito Test Report ❌20 test cases ran. 4 failed, 4 additional findings, 12 passed. Across 20 test cases, 12 passed and 8 failed: default-privilege and object-inheritance flows largely behaved correctly (including grant/revoke variants, omitted FOR ROLE behavior, table/routine/sequence coverage, routine write-fault cleanup, and ATTACH/DETACH partition formatting). The key findings were several production defects led by high-severity auth durability/restore problems (non-atomic default-ACL mutation on persist failure, auth.db v2 restart panics, corruption-driven startup crashes, and v1-to-v2 upgrade restart failure), plus catalog stability issues (owner-filter lookups blocked by empty pg_roles and pg_default_acl OID type mismatch panics) and parser/diagnostic gaps (broken PRIMARY KEY USING INDEX parse/format path and generic ALTER INDEX unsupported errors). ❌ Failed (4)
|
| Category | Summary | Screenshot |
|---|---|---|
| Catalog | Verified pg_default_acl returns rows for configured TABLE and FUNCTION defaults. |  |
| Catalog | Verified large ACL arrays remain queryable with 20 ACL entries and valid aclitem formatting. |  |
| Object | Old table stayed denied; new table inherited default SELECT grant. |  |
| Object | EXECUTE stayed denied on old routines and allowed on newly created routines. |  |
| Object | SERIAL table path applied default privileges to both table SELECT and sequence usage. |  |
| Object | Forced auth persistence failure returned an explicit error and no callable routine remained. |  |
| Parser | Parser round-trip formatted ATTACH PARTITION with child_tbl (not parent_tbl). |  |
| Parser | Both DETACH statements formatted with child_tbl and preserved CONCURRENTLY/FINALIZE modifiers. |  |
| Privilege | Default table grant applied; grantee could read the newly created table. |  |
| Privilege | Default privileges without FOR ROLE resolved to the active owner session and propagated to new tables. |  |
| Privilege | REVOKE GRANT OPTION FOR preserved SELECT while full REVOKE removed SELECT for later tables. |  |
| Privilege | REVOKE ... CASCADE was rejected and existing default ACL behavior remained unchanged. |  |
ℹ️ Additional Findings (4)
These findings are unrelated to the current changes but were observed during testing.
| Category | Summary | Screenshot |
|---|---|---|
| Catalog | 🟠 Owner-targeted catalog verification could not retrieve matching rows to validate grant-option aclitem formatting. |  |
| Parser | 🟠 ALTER TABLE ... PRIMARY KEY USING INDEX fails to parse and formatter emits malformed USING INDEX output without separator spacing. |  |
| Parser | ℹ️ ALTER INDEX ATTACH PARTITION diagnostics return a generic unsupported error that omits the referenced object names. |  |
| Serialization | N/A |
🟠 Owner filtered ACL catalog lookup fails
- What failed: Owner-scoped validation could not find matching rows needed to confirm role-name and '*' grant-option formatting in defaclacl, even after successful ALTER DEFAULT PRIVILEGES execution.
- Impact: Catalog-based tooling and diagnostics that rely on role-filtered default ACL inspection can report missing data even when defaults were configured. This weakens operator visibility into effective privilege state.
- Steps to reproduce:
- Create owner and grantee roles.
- Run ALTER DEFAULT PRIVILEGES FOR ROLE GRANT SELECT ON TABLES TO WITH GRANT OPTION.
- Query pg_catalog.pg_default_acl using owner-scoped lookup patterns.
- Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
- Code analysis: I reviewed the catalog handlers used by owner-scoped checks. pg_default_acl data is emitted, but owner-name based filters depend on role catalog resolution. pg_roles currently returns an empty iterator, which makes owner lookup/join paths non-functional.
- Why this is likely a bug: Returning an always-empty pg_roles catalog breaks legitimate owner-scoped catalog queries, so missing rows are caused by production code behavior rather than test setup.
Relevant code:
server/tables/pgcatalog/pg_roles.go (lines 45-48)
// RowIter implements the interface tables.Handler.
func (p PgRolesHandler) RowIter(ctx *sql.Context, partition sql.Partition) (sql.RowIter, error) {
// TODO: Implement pg_roles row iter
return emptyRowIter()
}🟠 PRIMARY KEY USING INDEX parser and formatter defects
- What failed: Expected the statement to parse and preserve app.orders_idx cleanly, but grammar accepts PRIMARY without KEY in this production and formatter emits USING INDEXapp.orders_idx without required spacing.
- Impact: Schema migration workflows that rely on PRIMARY KEY USING INDEX can fail or emit malformed SQL text. Teams may need manual SQL rewrites to proceed.
- Steps to reproduce:
- Parse ALTER TABLE app.orders ADD CONSTRAINT orders_pkey PRIMARY KEY USING INDEX app.orders_idx.
- Format the generated AST back into SQL.
- Observe parse failure around USING and formatter output that concatenates USING INDEX with the index name.
- Stub / mock context: The run used a local parser harness and rendered deterministic SQL outputs in local browser data pages; no API route interception or bypass flag was used for this test. Temporary local startup patches were applied outside the parser object-name paths under test.
- Code analysis: I reviewed parser grammar and tree formatting code in postgres/parser/parser/sql.y and postgres/parser/sem/tree/alter_table.go; the rule for this syntax omits KEY in the accepted production and the formatter concatenates the index name immediately after USING INDEX.
- Why this is likely a bug: The production code directly encodes an incomplete grammar token sequence and malformed formatting output for a valid SQL form, so this is a concrete parser/formatter defect rather than test setup noise.
Relevant code:
postgres/parser/parser/sql.y (lines 2131-2134)
| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
{
$$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
}postgres/parser/parser/sql.y (lines 2360-2368)
unique_or_primary:
UNIQUE
{
$$.val = true
}
| PRIMARY
{
$$.val = false
}postgres/parser/sem/tree/alter_table.go (lines 423-424)
ctx.WriteString(" USING INDEX")
node.Index.Format(ctx)ℹ️ ALTER INDEX unsupported diagnostic omits object identifiers
- What failed: Expected unsupported diagnostics to include identifier context for the referenced index and partition names, but execution always returns a generic message with no object names.
- Impact: Unsupported-operation errors provide weak debugging context, which slows troubleshooting when multiple index operations are being tested. Core parser behavior still works, but diagnostics are less actionable.
- Steps to reproduce:
- Parse ALTER INDEX app.parent_idx ATTACH PARTITION app.child_idx.
- Format the AST and confirm qualified object names are preserved.
- Trigger the unsupported execution conversion and inspect the returned error text.
- Stub / mock context: The run used a local parser harness and rendered deterministic SQL outputs in local browser data pages; no API route interception or bypass flag was used for this test. Temporary local startup patches were applied outside the parser object-name paths under test.
- Code analysis: I reviewed parse/format code and the AST conversion path. Parser and formatter preserve qualified partition index names, but server/ast/alter_index.go returns a fixed unsupported message regardless of input identifiers.
- Why this is likely a bug: The unsupported error path discards parsed object identity even though the AST preserves it, causing diagnosability loss in production error reporting.
Relevant code:
postgres/parser/parser/sql.y (lines 2029-2031)
| ALTER INDEX table_index_name ATTACH PARTITION db_object_name
{
$$.val = &tree.AlterIndex{Index: $3.tableIndexName(), Cmd: &tree.AlterIndexAttachPartition{Index: $6.unresolvedObjectName()}}
}postgres/parser/sem/tree/alter_index.go (lines 99-102)
func (node *AlterIndexAttachPartition) Format(ctx *FmtCtx) {
ctx.WriteString(" ATTACH PARTITION ")
node.Index.Format(ctx)
}server/ast/alter_index.go (lines 29-30)
// Only PARTITION alterations are supported by the parser, so there's nothing to convert to yet
return NotYetSupportedError("ALTER INDEX is not yet supported")⚠️ Corrupted auth database startup crash
- What failed: Corrupted bytes can propagate into unchecked reader operations and deserialize errors that are escalated via panic, crashing startup instead of handling corruption safely.
- Impact: A damaged auth file can take the service down during boot. Operators get a crash path rather than controlled failure handling or safe recovery.
- Steps to reproduce:
- Create non-empty default privileges and persist auth state to auth.db.
- Truncate or corrupt the persisted auth.db bytes.
- Restart the service and observe startup behavior during auth deserialize.
- Stub / mock context: Deterministic auth setup was used by bypassing SCRAM authentication in server/authentication_scram.go and bypassing domain constraint injection in server/analyzer/domain_constraints.go. This case intentionally truncated local auth.db bytes to simulate storage corruption before restart.
- Code analysis: I traced startup load and low-level decoding. Startup panics directly on deserialize errors, and the reader APIs index and slice the buffer without bounds checks, allowing malformed data to trigger runtime panics.
- Why this is likely a bug: Production startup code can panic on malformed persisted auth data instead of failing safely, which is a real reliability defect in core boot-time auth loading.
Relevant code:
server/auth/database.go (lines 165-177)
authData, err := fileSystem.ReadFile(authFileName)
if os.IsNotExist(err) {
dbInitDefault()
if err = dbInitCreateAuthDirectory(authFileName); err != nil {
panic(err)
}
if err = fileSystem.WriteFile(authFileName, globalDatabase.serialize(), 0644); err != nil {
panic(err)
}
} else if err != nil {
panic(err)
} else if err = globalDatabase.deserialize(authData); err != nil {
panic(err)
}utils/reader.go (lines 82-90)
func (reader *Reader) Uint32() uint32 {
reader.offset += 4
return binary.BigEndian.Uint32(reader.buf[reader.offset-4:])
}
func (reader *Reader) Uint64() uint64 {
reader.offset += 8
return binary.BigEndian.Uint64(reader.buf[reader.offset-8:])
}utils/reader.go (lines 196-199)
func (reader *Reader) String() string {
length := reader.VariableUint()
reader.offset += length
return string(reader.buf[reader.offset-length : reader.offset])
}Commit: 8800444
Tell us how we did: Give Ito Feedback
Ito Diff Report ❌Tested: Across 13 test cases, 5 passed and 8 failed, showing that key restore and fail-closed behaviors (unsupported auth.db header rejection, backup restore consistency, and recovery after controlled corruption) worked as expected but substantial defects remain. The most important findings were five high-severity issues—startup crashes from truncated or counter-inflated auth.db data, acceptance of downgraded version-byte tampering, unauthorized DROP SEQUENCE due to missing execution-time privilege checks, and default-privilege behavior diverging before vs. after restart when persistence fails—along with parser/diagnostic defects ( ❌ Failures (4)
🟠 USING INDEX primary key grammar mismatch
Relevant code:
| ADD CONSTRAINT constraint_name unique_or_primary USING INDEX db_object_name opt_deferrable_mode opt_initially
{
$$.val = tree.AlterTableConstraintUsingIndex{Constraint: tree.Name($3), IsUnique: $4.bool(), Index: $7.unresolvedObjectName(), Deferrable: $8.deferrableMode(), Initially: $9.initiallyMode()}
}
unique_or_primary:
UNIQUE
{
$$.val = true
}
| PRIMARY
{
$$.val = false
}
if node.IsUnique {
ctx.WriteString(" UNIQUE")
} else {
ctx.WriteString(" PRIMARY KEY")
}
ctx.WriteString(" USING INDEX")🟡 ALTER INDEX diagnostic omits object names
Relevant code:
func (node *AlterIndexAttachPartition) Format(ctx *FmtCtx) {
ctx.WriteString(" ATTACH PARTITION ")
node.Index.Format(ctx)
}
// Only PARTITION alterations are supported by the parser, so there's nothing to convert to yet
return NotYetSupportedError("ALTER INDEX is not yet supported")
// NotYetSupportedError returns an unsupported error with the given message, or a NoOp statement if the environment
// variable DOLTGRES_IGNORE_UNSUPPORTED is set.
func NotYetSupportedError(errorMsg string) (vitess.Statement, error) {
if ignoreUnsupportedStatements {
return NewNoOp(errorMsg), nil
}
return nil, errors.Errorf(errorMsg + " Please file an issue at https://github.com/dolthub/doltgresql/issues")
}
|
| Category | Summary | Screenshot |
|---|---|---|
| Serialization | Backup restore workflow preserved pre-restart permission behavior after server restart. |  |
| Serialization | Interrupted auth persistence failed closed and recovered cleanly after restoring a known-good auth.db. |  |
| Serialization | Late-stage v2 corruption failed closed on startup, then recovered to consistent role and privilege behavior. |  |
| Serialization | Full v2 privilege and membership state persisted correctly across restart. |  |
| Serialization | Unsupported auth.db version headers are rejected and SQL stays unavailable. |  |
↪️ Inherited from Prior Run (12)
Tests that passed in the prior run. c3 judged them unaffected by the diff and did not retest.
| Category | Summary | Screenshot |
|---|---|---|
| Catalog | Verified pg_default_acl returns rows for configured TABLE and FUNCTION defaults. | N/A |
| Catalog | Verified large ACL arrays remain queryable with 20 ACL entries and valid aclitem formatting. | N/A |
| Object | Old table stayed denied; new table inherited default SELECT grant. | N/A |
| Object | EXECUTE stayed denied on old routines and allowed on newly created routines. | N/A |
| Object | SERIAL table path applied default privileges to both table SELECT and sequence usage. | N/A |
| Object | Forced auth persistence failure returned an explicit error and no callable routine remained. | N/A |
| Parser | Parser round-trip formatted ATTACH PARTITION with child_tbl (not parent_tbl). | N/A |
| Parser | Both DETACH statements formatted with child_tbl and preserved CONCURRENTLY/FINALIZE modifiers. | N/A |
| Privilege | Default table grant applied; grantee could read the newly created table. | N/A |
| Privilege | Default privileges without FOR ROLE resolved to the active owner session and propagated to new tables. | N/A |
| Privilege | REVOKE GRANT OPTION FOR preserved SELECT while full REVOKE removed SELECT for later tables. | N/A |
| Privilege | REVOKE ... CASCADE was rejected and existing default ACL behavior remained unchanged. | N/A |
⚠️ Additional Findings (4)
These findings are unrelated to the current changes but were observed during testing.
| Origin | Category | Severity | Summary | Screenshot |
|---|---|---|---|---|
| 🆕 New | Serialization | Downgraded auth.db header tampering to v1 was accepted and SQL remained available. |  |
|
| 🆕 New | Serialization | Inflated nested counter values in auth.db can crash startup with slice-bounds panic. |  |
|
| 🆕 New | Serialization | 🟠 Medium | Stale role IDs can leave ACL text projection inconsistent with privilege enforcement checks. |  |
| 🆕 New | Serialization | Non-granted DROP SEQUENCE succeeds after restart because authorization is not enforced in execution. |
 |
⚠️ Reject downgraded auth.db version-byte tampering
- What failed: The server accepted a version-downgraded header and continued serving SQL, but expected behavior is fail-closed rejection of mismatched/tampered auth payloads.
- Impact: A tampered auth file can be accepted under a downgraded parser path, allowing the server to boot with inconsistent authorization state interpretation. This weakens startup integrity checks for security-sensitive auth state.
- Steps to reproduce:
- Create a valid v2 auth.db.
- Modify only the version header bytes from 2 to 1.
- Restart the server and attempt a SQL connection.
- Stub / mock context: SCRAM authentication was bypassed during this scenario so startup behavior with a tampered auth file could be exercised directly, and domain-cast constraint checks were temporarily disabled in analyzer logic. The tamper itself was a deliberate header-byte downgrade on auth.db followed by restart and live SQL reachability checks.
- Code analysis: I inspected the auth deserialization entrypoint and v1 path; the code trusts the version header and parses v1 without validating payload consistency or requiring full-buffer consumption, so a v2 payload labeled as v1 can still load.
- Why this is likely a bug: Production code accepts a header-controlled downgrade path without structural integrity checks, which contradicts the expected fail-closed behavior for tampered auth state.
Relevant code:
server/auth/serialization.go (lines 64-75)
reader := utils.NewReader(data)
version := reader.Uint32()
switch version {
case 0:
return db.deserializeV0(reader)
case 1:
return db.deserializeV1(reader)
case 2:
return db.deserializeV2(reader)
default:
return errors.Errorf("Authorization database format %d is not supported, please upgrade Doltgres", version)
}server/auth/serialization.go (lines 107-134)
func (db *Database) deserializeV1(reader *utils.Reader) error {
// ...
db.roleMembership.deserialize(1, reader)
// V1 has no default privileges; initialize empty
db.defaultPrivileges.deserialize(1, reader)
return nil
}server/auth/default_privileges.go (lines 250-256)
func (dp *DefaultPrivileges) deserialize(version uint32, reader *utils.Reader) {
dp.Data = make(map[DefaultPrivilegeKey]DefaultPrivilegeValue)
switch version {
case 0:
case 1:
case 2:⚠️ Inflated nested counters in auth.db should not exhaust startup resources
- What failed: Malformed count values can drive unbounded reads that panic with a slice-bounds runtime error instead of returning a bounded deserialize error.
- Impact: A malformed auth file can crash server startup and deny service until the file is manually repaired. This creates a reliability and availability risk in a core boot path.
- Steps to reproduce:
- Start from a valid auth.db.
- Inflate nested count and length bytes while keeping the auth header valid.
- Restart the server and observe startup behavior and logs.
- Stub / mock context: The run used a deliberate malformed auth.db variant with oversized nested counters to test startup safety boundaries, while SCRAM authentication and domain-cast checks remained bypassed for deterministic execution. After reproducing the panic behavior, a clean auth.db was restored to confirm recovery.
- Code analysis: I inspected the generic reader and auth decode loops; count and string length values are consumed from untrusted bytes and used for offset arithmetic/slicing without explicit bounds checks, enabling panic conditions during deserialize.
- Why this is likely a bug: The deserialize path uses attacker-controlled lengths without defensive bounds validation, so malformed auth bytes can trigger runtime panics in production startup logic.
Relevant code:
utils/reader.go (lines 195-200)
func (reader *Reader) String() string {
length := reader.VariableUint()
reader.offset += length
return string(reader.buf[reader.offset-length : reader.offset])
}server/auth/default_privileges.go (lines 256-275)
dataCount := reader.Uint64()
for i := uint64(0); i < dataCount; i++ {
dpv := DefaultPrivilegeValue{Grantees: make(map[RoleID]DefaultPrivilegeGranteeValue)}
dpv.Key.OwnerRole = RoleID(reader.Uint64())
dpv.Key.Schema = reader.String()
dpv.Key.ObjectType = PrivilegeObject(reader.Uint8())
granteeCount := reader.Uint64()
for j := uint64(0); j < granteeCount; j++ {
granteeValue := DefaultPrivilegeGranteeValue{
Grantee: RoleID(reader.Uint64()),
Privileges: make(map[Privilege]map[GrantedPrivilege]bool),
}server/auth/database.go (lines 165-178)
authData, err := fileSystem.ReadFile(authFileName)
if os.IsNotExist(err) {
// ...
} else if err != nil {
panic(err)
} else if err = globalDatabase.deserialize(authData); err != nil {
panic(err)
}🟠 Dropped role IDs yield inconsistent ACL display and enforcement
- What failed: ACL text projection resolves missing role IDs to empty names while privilege enforcement still treats stored grant entries as effective, so catalog visibility and actual permission behavior diverge.
- Impact: Users and operators can see misleading ACL metadata after role deletion while authorization decisions still allow operations. This weakens trust in access introspection and can cause incorrect privilege/audit conclusions.
- Steps to reproduce:
- Create default privileges where role A grants privileges to role B.
- Drop role A from the auth database.
- Query pg_catalog.pg_default_acl and compare ACL strings with actual privilege checks for role B.
- Stub / mock context: This conclusion came from direct production-code inspection of role-drop, ACL projection, and privilege-check logic rather than a mocked API response. A temporary auth/domain bypass patch in server/authentication_scram.go and server/analyzer/domain_constraints.go was active in the run environment.
- Code analysis: I reviewed role deletion, role-name lookup, ACL text rendering, and privilege evaluation paths under server/auth and server/tables/pgcatalog. DropRole deletes role maps but leaves privilege/default-ACL structures untouched, ACL rendering converts unresolved role IDs to empty names, and privilege checks only require a non-empty privilege map.
- Why this is likely a bug: The code keeps privileges keyed by dropped-role IDs and later renders those IDs as empty ACL names while still authorizing via non-empty privilege maps, producing an internally inconsistent and user-visible authorization model.
Relevant code:
server/auth/database.go (lines 65-71)
// DropRole removes the given role from the database. If the role does not exist, then this is a no-op.
func DropRole(name string) {
if roleID, ok := globalDatabase.rolesByName[name]; ok {
delete(globalDatabase.rolesByName, name)
delete(globalDatabase.rolesByID, roleID)
// TODO: remove from ownership, schema privileges, table privileges, and role membership
}
}server/tables/pgcatalog/pg_default_acl.go (lines 55-64)
granteeName := auth.GetRoleName(granteeValue.Grantee)
for priv, grantedMap := range granteeValue.Privileges {
for grantedPriv, withGrantOption := range grantedMap {
grantorName := auth.GetRoleName(grantedPriv.GrantedBy)
privStr := string(priv)
if withGrantOption {
privStr += "*"
}
aclItems = append(aclItems, fmt.Sprintf("%s=%s/%s", granteeName, privStr, grantorName))
}
}server/auth/table_privileges.go (lines 78-80)
if tablePrivilegeValue, ok := globalDatabase.tablePrivileges.Data[key]; ok {
if privilegeMap, ok := tablePrivilegeValue.Privileges[privilege]; ok && len(privilegeMap) > 0 {
return true
}
}⚠️ Unauthorized sequence drop succeeds after restart
- What failed: The non-owner grantee can execute
DROP SEQUENCEsuccessfully even when destructive permission was not granted; expected behavior is permission denial for non-granted destructive sequence actions. - Impact: Unauthorized users can delete sequences despite missing grants, breaking core authorization guarantees for destructive operations. This can remove schema objects without intended ownership or grant checks.
- Steps to reproduce:
- Create a sequence and grant only selected sequence privileges to a non-owner role.
- Restart with persisted auth data.
- Execute a granted operation (
nextval) and then attempt non-grantedDROP SEQUENCEas the grantee.
- Stub / mock context: Authentication and domain-constraint checks were bypassed in
server/authentication_scram.goandserver/analyzer/domain_constraints.goto keep the local run progressing after startup instability, and the scenario ran in a temporary containerized runtime. The observed authorization gap is still supported by direct production-code inspection of the drop-sequence execution path. - Code analysis: I reviewed sequence auth checks and the
DROP SEQUENCEpath.server/auth/auth_handler.godefinescheckPrivilegeOnSequence, butserver/node/drop_sequence.godrops the sequence directly through the collection API without invoking any sequence privilege check, and AST conversion wires directly to that node. - Why this is likely a bug: Production code provides sequence privilege-check logic but the destructive drop execution path bypasses it, creating an authorization gap that matches the observed behavior.
Relevant code:
server/node/drop_sequence.go (lines 66-105)
func (c *DropSequence) RowIter(ctx *sql.Context, r sql.Row) (sql.RowIter, error) {
schema, err := core.GetSchemaName(ctx, nil, c.schema)
if err != nil {
return nil, err
}
// ...
collection, err := core.GetSequencesCollectionFromContext(ctx, ctx.GetCurrentDatabase())
if err != nil {
return nil, err
}
sequenceID := id.NewSequence(schema, c.sequence)
// ...
if err = collection.DropSequence(ctx, sequenceID); err != nil {
return nil, err
}
return sql.RowsToRowIter(), nil
}server/auth/auth_handler.go (lines 333-350)
func checkPrivilegeOnSequence(state AuthorizationQueryState, schemaName, seqName string, privileges []Privilege) error {
roleSequenceKey := SequencePrivilegeKey{Role: state.role.ID(), Schema: schemaName, Name: seqName}
publicSequenceKey := SequencePrivilegeKey{Role: state.public.ID(), Schema: schemaName, Name: seqName}
for _, privilege := range privileges {
if !HasSequencePrivilege(roleSequenceKey, privilege) && !HasSequencePrivilege(publicSequenceKey, privilege) {
return errors.Errorf("permission denied for sequence %s", seqName)
}
}
return nil
}server/ast/drop_sequence.go (lines 41-45)
return vitess.InjectedStatement{
Statement: pgnodes.NewDropSequence(node.IfExists, name.SchemaQualifier.String(), name.Name.String(),
node.DropBehavior == tree.DropCascade),
Children: nil,
}, nilTell us how we did: Give Ito Feedback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.