implement alter default privileges

[jennifersp]

No description provided.

[github-actions]

	Main	PR

[github-actions]

	Main	PR
Total	42090	42090
Successful	18250	18256
Failures	23840	23834
Partial Successes1	5385	5383

	Main	PR
Successful	43.3595%	43.3737%
Failures	56.6405%	56.6263%

${\color{red}Regressions (2)}$

psql

QUERY:          SELECT pg_catalog.pg_get_userbyid(d.defaclrole) AS "Owner",
  n.nspname AS "Schema",
  CASE d.defaclobjtype WHEN 'r' THEN 'table' WHEN 'S' THEN 'sequence' WHEN 'f' THEN 'function' WHEN 'T' THEN 'type' WHEN 'n' THEN 'schema' END AS "Type",
  pg_catalog.array_to_string(d.defaclacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_default_acl d
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.defaclnamespace
WHERE (n.nspname OPERATOR(pg_catalog.~) E'^(no\\.such\\.default\\.access\\.privilege)$' COLLATE pg_catalog.default
        OR pg_catalog.pg_get_userbyid(d.defaclrole) OPERATOR(pg_catalog.~) E'^(no\\.such\\.default\\.access\\.privilege)$' COLLATE pg_catalog.default)
ORDER BY 1, 2, 3;
RECEIVED ERROR: cast from type oid to type oid is mislabeled as binary-coercible (errno 1105) (sqlstate HY000)

QUERY:          SELECT pg_catalog.pg_get_userbyid(d.defaclrole) AS "Owner",
  n.nspname AS "Schema",
  CASE d.defaclobjtype WHEN 'r' THEN 'table' WHEN 'S' THEN 'sequence' WHEN 'f' THEN 'function' WHEN 'T' THEN 'type' WHEN 'n' THEN 'schema' END AS "Type",
  pg_catalog.array_to_string(d.defaclacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_default_acl d
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.defaclnamespace
WHERE (n.nspname OPERATOR(pg_catalog.~) E'^(no\\.such\\.schema.no\\.such\\.default\\.access\\.privilege)$' COLLATE pg_catalog.default
        OR pg_catalog.pg_get_userbyid(d.defaclrole) OPERATOR(pg_catalog.~) E'^(no\\.such\\.schema.no\\.such\\.default\\.access\\.privilege)$' COLLATE pg_catalog.default)
ORDER BY 1, 2, 3;
RECEIVED ERROR: cast from type oid to type oid is mislabeled as binary-coercible (errno 1105) (sqlstate HY000)

${\color{lightgreen}Progressions (8)}$

dependency

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_dep_user1 IN SCHEMA deptest
  GRANT ALL ON TABLES TO regress_dep_user2;

event_trigger

QUERY: alter default privileges for role regress_evt_user
 revoke delete on tables from regress_evt_user;

matview

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_matview_user
  REVOKE INSERT ON TABLES FROM regress_matview_user;

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_matview_user
  GRANT INSERT ON TABLES TO regress_matview_user;

object_address

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_addr_user IN SCHEMA public GRANT ALL ON TABLES TO regress_addr_user;

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_addr_user REVOKE DELETE ON TABLES FROM regress_addr_user;

select_into

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_selinto_user
	  REVOKE INSERT ON TABLES FROM regress_selinto_user;

QUERY: ALTER DEFAULT PRIVILEGES FOR ROLE regress_selinto_user
	  GRANT INSERT ON TABLES TO regress_selinto_user;

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

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	⚠️ Global-scope pg_default_acl verification hit an OID type panic during catalog reads.
Privilege	⚠️ ALTER DEFAULT PRIVILEGES mutates in-memory ACL state before persistence; failed writes can leave restart-divergent authorization behavior.
Serialization	⚠️ auth.db is written as v2 but restart deserializers panic on version 2 privilege payloads.	N/A
Serialization	⚠️ v1-to-v2 upgrade flow can persist v2 state that panics on subsequent restart.

⚠️ OID typing mismatch crashes catalog reads

• What failed: Catalog reads can panic with interface conversion: interface {} is uint32, not id.Id, preventing verification of expected global-scope rows (defaclnamespace = 0).
• Impact: Queries against pg_default_acl can fail at runtime for valid introspection workflows, blocking visibility into default privilege state. This breaks a core catalog surface for authorization diagnostics.
• Steps to reproduce:
  1. Execute global-scope ALTER DEFAULT PRIVILEGES FOR ROLE GRANT SELECT ON TABLES TO without IN SCHEMA.
  2. Query pg_catalog.pg_default_acl.
  3. Read OID-typed fields during projection or filtering.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I traced pg_default_acl row construction and compared it to the OID type contract. The handler emits raw uint32 for OID columns, but the OID type serializer/deserializer expects id.Id; this mismatch explains the runtime interface-conversion panic.
• Why this is likely a bug: The handler violates the declared OID runtime type contract (id.Id), which directly causes query-time type conversion failures in production code.

Relevant code:

server/tables/pgcatalog/pg_default_acl.go (lines 70-75)

rows = append(rows, sql.Row{
    uint32(oid + 1), // oid (synthetic, 1-based index)
    uint32(entry.Key.OwnerRole),
    uint32(0), // defaclnamespace: 0 = any schema (schema OID lookup not yet implemented)
    auth.DefaultPrivilegeObjTypeChar(entry.Key.ObjectType),
    aclItems,
})

server/types/oid.go (lines 61-74)

// serializeTypeOid handles serialization from the standard representation to our serialized representation that is
// written in Dolt.
func serializeTypeOid(ctx *sql.Context, t *DoltgresType, val any) ([]byte, error) {
    return []byte(val.(id.Id)), nil
}

// deserializeTypeOid handles deserialization from the Dolt serialized format to our standard representation used by
// expressions and nodes.
func deserializeTypeOid(ctx *sql.Context, t *DoltgresType, data []byte) (any, error) {
    if len(data) == 0 {
        return nil, nil
    }
    return id.Id(data), nil
}

⚠️ Default privilege mutation is not atomic with persistence

• What failed: The statement returns a persistence error, but the in-memory default ACL mutation is already applied, so pre-restart behavior can reflect the new default while post-restart behavior (after reloading from durable state) does not.
• Impact: Authorization outcomes can diverge across restart boundaries after a write failure, producing inconsistent access control decisions for the same role and object scope. Recovery can include restart instability when corrupted auth state is deserialized.
• Steps to reproduce:
  1. Run ALTER DEFAULT PRIVILEGES while forcing persistence to fail at write time.
  2. In the same process, create a new object owned by the altered role and verify inherited privilege behavior.
  3. Restart the server and create another object for the same owner/scope to compare inherited privileges.
• Stub / mock context: To exercise persistence-failure handling, the run temporarily forced the auth persistence target into a non-writable state so ALTER DEFAULT PRIVILEGES returned a write error, then restored normal writes for restart comparison.
• Code analysis: I inspected default-privilege execution and auth serialization paths and found mutation occurs before PersistChanges, with no rollback when persistence fails. The same code path also writes auth state directly and panics on deserialize errors at startup, which matches the observed restart fragility under failed persistence scenarios.
• Why this is likely a bug: The implementation commits default-ACL mutations to in-memory state before durability succeeds and does not revert on write failure, so authorization behavior can legitimately split between pre-restart memory and post-restart persisted state.

Relevant code:

server/node/alter_default_privileges.go (lines 64-73)

auth.LockWrite(func() {
	err = n.execute(ctx)
	if err != nil {
		return
	}
	err = auth.PersistChanges()
})
if err != nil {
	return nil, err
}

server/node/alter_default_privileges.go (lines 123-137)

for _, ownerRole := range ownerRoles {
	for _, schema := range schemas {
		key := auth.DefaultPrivilegeKey{
			OwnerRole:  ownerRole.ID(),
			Schema:     schema,
			ObjectType: n.ObjectType,
		}
		for _, granteeRole := range granteeRoles {
			for _, priv := range n.Privileges {
				grantedPrivilege := auth.GrantedPrivilege{
					Privilege: priv,
					GrantedBy: ownerRole.ID(),
				}
				if n.Grant {
					auth.AddDefaultPrivilege(key, granteeRole.ID(), grantedPrivilege, n.GrantOption)

server/auth/serialization.go (lines 25-28)

func PersistChanges() error {
	if fileSystem != nil {
		return fileSystem.WriteFile(authFileName, globalDatabase.serialize(), 0644)
	}

server/auth/database.go (lines 176-177)

} else if err = globalDatabase.deserialize(authData); err != nil {
				panic(err)

⚠️ Auth DB version 2 restart panic

• What failed: Restart reads auth data as version 2, then panics while deserializing privilege maps that only support versions 0/1, so default privileges are not recoverable after restart.
• Impact: Persisting default privileges can make the server fail to start on the next boot. This breaks a core auth workflow and has no practical runtime workaround once the file is written.
• Steps to reproduce:
  1. Connect as superuser and configure default table privileges for an owner role.
  2. Restart the server process using persisted auth.db state.
  3. Create a new table as the owner role and verify reader-role access after restart.
• 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 before running restart checks. This case also manipulated local auth.db files (backup and replacement) to validate restart behavior under persisted state transitions.
• Code analysis: I reviewed auth serialization/deserialization flow and privilege map decoders. The serializer writes version 2 and deserializeV2 routes version 2 into legacy privilege deserializers that explicitly panic on unknown versions.
• Why this is likely a bug: The code persists version 2 auth data but immediately routes version 2 reads into decoders that intentionally panic on that version, creating a deterministic restart failure path.

Relevant code:

server/auth/serialization.go (lines 36-55)

// Write the version
writer.Uint32(2)
// Write the database privileges
db.databasePrivileges.serialize(writer)
// Write the schema privileges
db.schemaPrivileges.serialize(writer)
// Write the table privileges
db.tablePrivileges.serialize(writer)
// Write the sequence privileges
db.sequencePrivileges.serialize(writer)
// Write the routine privileges
db.routinePrivileges.serialize(writer)
// Write the role chain
db.roleMembership.serialize(writer)
// Write the default privileges
db.defaultPrivileges.serialize(writer)

server/auth/serialization.go (lines 149-162)

// Read the database privileges
db.databasePrivileges.deserialize(2, reader)
// Read the schema privileges
db.schemaPrivileges.deserialize(2, reader)
// Read the table privileges
db.tablePrivileges.deserialize(2, reader)
// Read the sequence privileges
db.sequencePrivileges.deserialize(2, reader)
// Read the routine privileges
db.routinePrivileges.deserialize(2, reader)
// Read the role membership
db.roleMembership.deserialize(2, reader)

server/auth/database_privileges.go (lines 173-200)

switch version {
case 0, 1:
    // Read the total number of values
    dataCount := reader.Uint64()
    for dataIdx := uint64(0); dataIdx < dataCount; dataIdx++ {
        // Read the key
        spv := DatabasePrivilegeValue{Privileges: make(map[Privilege]map[GrantedPrivilege]bool)}
        spv.Key.Role = RoleID(reader.Uint64())
        spv.Key.Name = reader.String()
    }
default:
    panic("unexpected version in DatabasePrivileges")
}

⚠️ Upgrade path v1 to v2 break

• What failed: After first v2 persistence, restart deserializes with version 2 while multiple privilege and membership decoders still only accept 0/1 and panic, breaking upgrade continuity.
• Impact: A v1 environment can appear to upgrade but then fail on the first subsequent restart after v2 persistence. This risks post-upgrade outages in core authorization behavior.
• Steps to reproduce:
  1. Start from a v1 auth.db fixture and run the newer binary.
  2. Execute ALTER DEFAULT PRIVILEGES and persist auth state so the file is rewritten as v2.
  3. Restart and verify inherited privileges for newly created objects.
• 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 also used a synthetic legacy auth.db variant to exercise the v1-to-v2 upgrade-and-restart path.
• Code analysis: I inspected upgrade serialization routing and all downstream deserializers used by deserializeV2. Several maps still gate on versions 0/1 only and panic for version 2, so upgrade plus restart is structurally incompatible.
• Why this is likely a bug: The upgrade flow writes version 2 data but restart decode paths still reject version 2 in multiple required structures, making the failure reproducible from source logic alone.

Relevant code:

server/auth/serialization.go (lines 149-162)

// Read the database privileges
db.databasePrivileges.deserialize(2, reader)
// Read the schema privileges
db.schemaPrivileges.deserialize(2, reader)
// Read the table privileges
db.tablePrivileges.deserialize(2, reader)
// Read the sequence privileges
db.sequencePrivileges.deserialize(2, reader)
// Read the routine privileges
db.routinePrivileges.deserialize(2, reader)
// Read the role membership
db.roleMembership.deserialize(2, reader)

server/auth/schema_privileges.go (lines 173-200)

switch version {
case 0, 1:
    // Read the total number of values
    dataCount := reader.Uint64()
    for dataIdx := uint64(0); dataIdx < dataCount; dataIdx++ {
        // Read the key
        spv := SchemaPrivilegeValue{Privileges: make(map[Privilege]map[GrantedPrivilege]bool)}
        spv.Key.Role = RoleID(reader.Uint64())
        spv.Key.Schema = reader.String()
    }
default:
    panic("unexpected version in SchemaPrivileges")
}

server/auth/role_membership.go (lines 141-165)

switch version {
case 0, 1:
    // Read the total number of members
    memberCount := reader.Uint64()
    for memberIdx := uint64(0); memberIdx < memberCount; memberIdx++ {
        // Read the number of groups
        groupCount := reader.Uint64()
        groupMap := make(map[RoleID]RoleMembershipValue)
        var member RoleID
    }
default:
    panic("unexpected version in RoleMembership")
}

✅ Passed (12)

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	⚠️ Corrupted auth.db bytes can trigger unchecked deserialization panics during startup.	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:
  1. Create owner and grantee roles.
  2. Run ALTER DEFAULT PRIVILEGES FOR ROLE GRANT SELECT ON TABLES TO WITH GRANT OPTION.
  3. 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:
  1. Parse ALTER TABLE app.orders ADD CONSTRAINT orders_pkey PRIMARY KEY USING INDEX app.orders_idx.
  2. Format the generated AST back into SQL.
  3. 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:
  1. Parse ALTER INDEX app.parent_idx ATTACH PARTITION app.child_idx.
  2. Format the AST and confirm qualified object names are preserved.
  3. 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:
  1. Create non-empty default privileges and persist auth state to auth.db.
  2. Truncate or corrupt the persisted auth.db bytes.
  3. 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

View Full Run

---

Tell us how we did: Give Ito Feedback