Add BIT support by JelteF · Pull Request #117 · duckdb/duckdb-go

JelteF · 2026-02-09T14:00:18Z

This adds support for reading/writing the BIT type. Since there is no native type for representing bitstrings in Go, this adds a custom Go type that represents one. It uses the same internal storage as DuckDB so that conversions are cheap and require minimal copying.

P.S. Strictly speaking there is the BitString type in the encoding/asn1, but that's not meant for general purpose use. It's really only there so that X509 certificates can be decoded. It's also laid out very differently than DuckDB its BIT type (e.g. it uses 0's for padding instead of 1's).

mlafeldt

Thanks! Found some minor inconsistencies and missing tests. Otherwise looks great.

mlafeldt · 2026-02-10T10:14:23Z

types.go

+}
+
+// NewBitFromString creates a Bit from a string of '0' and '1' characters.
+func NewBitFromString(s string) (*Bit, error) {


This returns *Bit while all other type constructors return values - should be Bit, error) for consistency

mlafeldt · 2026-02-10T10:34:23Z

value.go

+	case TYPE_BIT:
+		bit := mapping.GetBit(v)
+		defer mapping.DestroyBit(&bit)
+		return Bit{data: mapping.BitMembers(&bit)}, nil


In this file, TYPE_BIT is still marked as "Invalid or unsupported" in isPrimitiveType() and missing from inferPrimitiveType()

mlafeldt · 2026-02-10T10:37:57Z

types.go

+// The slice is consumed directly without copying, so the caller must not modify it afterwards.
+func NewBitFromRaw(data []byte) (*Bit, error) {
+	if len(data) <= 1 {
+		return &Bit{}, nil


Nitpicky inconsistency:

NewBitFromString("") → error ("empty bit string")

NewBitFromRaw(nil) → success, returns &Bit{}

mlafeldt · 2026-02-10T10:44:14Z

appender_test.go

 	require.Equal(t, expected, r)
 }

+func TestAppenderBit(t *testing.T) {


Can we also test scanning non-null into var r *Bit?

This adds support for reading/writing the BIT type. Since there is no native type for representing bitstrings in Go, this adds a custom Go type that represents one. It uses the same internal storage as DuckDB so that conversions are cheap and require minimal copying. P.S. Strictly speaking there is the BitString type in the encoding/asn1, but that's not meant for general purpose use. It's really only there so that X509 certificates can be decoded. It's also laid out very differently than DuckDB its BIT type (e.g. it uses 0's for padding instead of 1's).

JelteF · 2026-02-10T13:04:19Z

I think I addressed all of your comments.

I also removed NewBitFromRaw after trying these new APIs in my own project. Instead I now simply made the Data field public (I added a Validate() method so people can still check if it's stored in the correct format). The reason for doing so is that for my own usecase I wanted to access the raw bits and convert them to some other bitstring form, without going through the String representation. I could have added a getter method, but that would either have to create a copy of the bytes or return the actual slice. I wanted to do conversion to the other form with minimal amount of copies so that disqualified the first option. And having a getter return the actual slice, just seemed like a complicated way of effectively making the field public. So that's what I did.

mlafeldt

Thanks for the changes. I had another look and left a few more inline comments to address before merging.

mlafeldt · 2026-03-03T10:45:25Z

types.go

+// Validate checks that Data is a valid DuckDB bit encoding: the padding count
+// (first byte) must be 0-7, and the padding bits in the first data byte must
+// all be set to 1.
+func (b Bit) Validate() error {


This is never called on any write path. Both setBit and bindBit pass Data (which is public) straight to DuckDB without validation.

mlafeldt · 2026-03-03T10:54:30Z

types.go

+// all be set to 1.
+func (b Bit) Validate() error {
+	if len(b.Data) <= 1 {
+		return nil


We also need to reject single-byte with nonzero padding

if len(b.Data) == 1 && b.Data[0] != 0 { return fmt.Errorf("invalid padding count %d with no data bytes", b.Data[0]) }

mlafeldt · 2026-03-03T11:01:39Z

types.go

+// NewBitFromString creates a Bit from a string of '0' and '1' characters.
+func NewBitFromString(s string) (Bit, error) {
+	if len(s) == 0 {
+		return Bit{}, nil


This will return Bit{Data: nil}. Passing it to setBit or bindBit sends a nil slice into C code.

I suggest to either return an error for empty strings or return Bit{Data: []byte{0}} as the canonical empty encoding.

mlafeldt · 2026-03-03T11:03:40Z

connection.go

 func (conn *Conn) CheckNamedValue(nv *driver.NamedValue) error {
 	switch nv.Value.(type) {
-	case *big.Int, Interval, []any, []bool, []int8, []int16, []int32, []int64, []int, []uint8, []uint16,
+	case *big.Int, Interval, Bit, []any, []bool, []int8, []int16, []int32, []int64, []int, []uint8, []uint16,


This should also handle *Bit

mlafeldt · 2026-03-03T11:06:49Z

statement.go

 		}
 		return mapping.BindInterval(*s.preparedStmt, mapping.IdxT(n+1), i), nil
+	case Bit:
+		return s.bindBit(&v, n)


This should also handle *Bit

mlafeldt · 2026-03-03T11:09:05Z

value.go

 		// Complex type.
 		return false
-	case TYPE_INVALID, TYPE_BIT, TYPE_ANY:
+	case TYPE_INVALID, TYPE_ANY:


In value.go, Bit is still not handled in inferPrimitiveType and createPrimitiveValue

taniabogatsch requested a review from mlafeldt February 10, 2026 09:55

JelteF force-pushed the bit-support branch from 437ec08 to bfff763 Compare February 10, 2026 10:35

mlafeldt reviewed Feb 10, 2026

View reviewed changes

JelteF force-pushed the bit-support branch from bfff763 to 650a0d2 Compare February 10, 2026 11:22

JelteF force-pushed the bit-support branch from 650a0d2 to b244179 Compare February 10, 2026 12:13

mlafeldt requested changes Mar 3, 2026

View reviewed changes

Conversation

JelteF commented Feb 9, 2026

Uh oh!

mlafeldt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JelteF commented Feb 10, 2026

Uh oh!

mlafeldt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mlafeldt Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mlafeldt Mar 3, 2026 •

edited

Loading