kernel

func BoolFilterConst ¶ added in v0.18.4

func BoolFilterConst(v any) (val, ok bool)

BoolFilterConst resolves a BOOL-column filter constant to a Go bool. A Go bool arrives from a parameter; a SQL text literal (Go string, or []byte from a binary parameter) is read through PostgreSQL's boolean input grammar. ok is false only for a string that names no boolean, and a nil kernel is how this package asks the caller (exec.boolConstError) to raise 22P02 — the same "nil kernel, caller raises" convention the network and DECIMAL arms use.

func CanonicalFloat32 ¶ added in v0.18.1

func CanonicalFloat32(f float32) float32

CanonicalFloat32 is CanonicalFloat64 for float32.

func CanonicalFloat64 ¶ added in v0.18.1

func CanonicalFloat64(f float64) float64

CanonicalFloat64 / CanonicalFloat32 fold a value onto the one bit pattern the order above treats as canonical for it: every NaN payload onto one NaN, and -0.0 onto +0.0. CompareFloat64/32 call both of those pairs EQUAL, and the standing invariant (ADR-0012 item 8) is that two values the comparator calls equal must also SERIALIZE alike — otherwise a GROUP BY splits one group in two, a hash join misses a pair the comparator matches, or a shuffle routes two equal keys to different partitions and the distributed answer stops agreeing with the single-process one.

func CidrOrderKey ¶ added in v0.18.3

func CidrOrderKey(s string) string

CidrOrderKey is CidrSortKey for every CIDR consumer that needs a definite key for EVERY stored value, not just the ones that parse: ORDER BY, GROUP BY / DISTINCT / COUNT(DISTINCT) / hash-join hash keys, MIN/MAX, and the distributed shuffle router (#520 — the residual ADR-0012 item 10 left open after #492 fixed WHERE-clause comparison: those consumers still keyed a CIDR column on its raw stored TEXT, so '10.0.0.1' and '10.0.0.1/32' were two GROUP BY groups, two DISTINCT values and could land in two different hash-join buckets or shuffle partitions, while `=` already called them one value).

A stored value that names no address at all falls back to its own raw text: the column is unvalidated (internal/storage/ingest), so a malformed row still needs a stable, total-order position instead of a panic or an arbitrary collision — it groups/sorts with other byte-identical garbage, which is the same answer every OTHER type gives an unparseable value it cannot special-case either. This is deliberately NOT the same rule as a FILTER LITERAL that names no address (kernel.ResolveFilterKernel's TypeCIDR arm, exec.networkConstError): a bad literal in a WHERE/comparison is a query the engine cannot answer at all (22P02); a bad STORED value is just one row with no defined place in the order, same as a NULL.

func CidrSortKey ¶ added in v0.18.2

func CidrSortKey(s string) (string, bool)

CidrSortKey re-keys a CIDR/inet TEXT value ("192.168.1.0/24", "10.0.0.1/8", or a bare "10.0.0.1") into PostgreSQL's `inet` order — network_cmp — as a byte string two keys compare LEXICALLY in exactly that order.

PostgreSQL's network_cmp_internal compares, in this sequence:

1. the address FAMILY (v4 before v6),
2. the common bits under the SMALLER of the two prefix lengths,
3. the prefix length itself,
4. the FULL, UNMASKED address.

The key is [family][address masked to its own prefix, full width][prefix length][full unmasked address], which reproduces that order exactly. Step 2 needs both operands and no single-value key can hold it directly, but the masked address is equivalent: if the first min(len) bits differ, both keys retain the differing bit and compare the same way; if they agree, the shorter prefix's key has zeros where the longer one may have ones, so it sorts first — which is step 3's answer — and when those bits are zero too the keys tie and the explicit prefix-length byte decides. The trailing full address is step 4.

Verified against live PostgreSQL 17 over host-bearing and canonical values, v4 and v6, at mixed prefix lengths — the whole table is TestCidrSortKeyMatchesPostgresInetOrder's fixture. Three of its consequences are worth naming because a simpler key gets them wrong:

'9.255.255.255/32' < '10.0.0.0/8'   — common bits decide before the mask
'192.168.1.5/24'   < '192.168.1.0/32' — the MASK outranks the address
'10.0.0.0/8'       < '10.0.0.1/8'   — host bits are kept, and ordered last

That last one is why the key cannot be built from net.ParseCIDR's MASKED network alone, which is what this function did when #492 introduced it: keying only ipnet.IP threw the host bits away, so '10.0.0.1/8' and '10.0.0.0/8' became the SAME value and `= '10.0.0.1/8'` answered rows holding a different address. Wadjet's CIDR column is unvalidated text (internal/storage/ingest), and host-bearing prefixes are ordinary in the network data this type exists for, so those are not edge values.

A BARE address with no "/" is a /32 (v4) or /128 (v6), which is what PostgreSQL's inet does with the same input — `'10.0.0.1'::inet = '10.0.0.1/32'::inet` is true. A v4-MAPPED v6 address ("::ffff:10.0.0.2") keeps the v6 family, also matching PostgreSQL (`family()` answers 6).

ok is false when s is not an address at all. Callers must turn that into a query ERROR, never a match-nothing kernel: see ResolveFilterKernel's TypeCIDR arm.

Exported — unlike this file's other literal parse helpers (parseIPv4ToInt64, parseMACToInt64), which internal/engine/expr duplicates locally rather than importing — because this one is not a trivial re-encode: expr.CmpNetworkLit's CIDR literal and this kernel's per-row CIDR key MUST agree bit for bit, and two structural parsers maintained separately is exactly the shape #492 already is (the kernel path numeric, the expr path lexical). One implementation, shared, is what keeps them from drifting apart again.

func CompareDecimalAt ¶

func CompareDecimalAt(a *batch.Vector, ai int, b *batch.Vector, bi int) int

CompareDecimalAt orders two DECIMAL values by NUMERIC value, which is what PostgreSQL's `numeric` ordering means and what every other comparator in this file already does for its type. Before this arm existed, DECIMAL fell through the three resolvers' defaults to a comparator that reports every row equal, so `ORDER BY dec_col` was a stable no-op that returned input order, and a sort-merge join on a DECIMAL key matched every row against every row. The other path in the tree — compareAny over Vector.GetValue — compares the FORMATTED string instead, where "10.001" sorts before "2.0002". Same query, three different sequences depending on which path answered (#394).

The comparison is EXACT at every scale. Equal scales compare the unscaled Int128s directly — that is every sort over one column, every sorted run and every k-way merge over runs. Unequal scales, reachable where two separately declared DECIMAL columns meet, rescale the smaller-scale operand by 10^(delta) and compare the unscaled integers; if that product overflows Int128 the two are compared as big.Int rather than approximated.

Exactness is not a nicety here: SortMergeJoin uses this comparator for key EQUALITY (sort_merge_join.go), so an approximate answer is a spurious JOIN MATCH. The float64 rescale this replaced held to 2^53 unscaled units and then started reporting 9007199254740993 and 9007199254740992.0 — which differ by one unscaled unit at the common scale — as the same key.

func CompareDecimalValues ¶ added in v0.18.1

func CompareDecimalValues(av batch.Int128, as int, bv batch.Int128, bs int) int

CompareDecimalValues is CompareDecimalAt on values already read out of their columns — the form the col-col FILTER kernel needs, which reads its two slices once per batch rather than per row. One function so the sort comparator, the sort-merge join key and the filter cannot drift apart.

func CompareFloat32 ¶ added in v0.18.1

func CompareFloat32(a, b float32) int

CompareFloat32 orders two float32 values with NaN greatest and NaN == NaN.

Native float32 comparisons, not a widen-to-float64-and-delegate: widening every element cost ZZSortFloat32NoNulls +2.03% (benchmarked against CompareFloat64(float64(a), float64(b)), the form this replaced) for a rule that needs nothing float64 offers — float32's `<`/`>`/`==`/self-inequality already carry the same PostgreSQL order this function documents for float64.

func CompareFloat64 ¶ added in v0.18.1

func CompareFloat64(a, b float64) int

CompareFloat64 orders two float64 values with NaN greatest and NaN == NaN.

func CompareValuesAt ¶ added in v0.18.1

func CompareValuesAt(a *batch.Vector, ai int, b *batch.Vector, bi int) int

CompareValuesAt orders two values of the same type, WITHOUT consulting either row's null bit. Callers that can see a NULL use compareElemAt (for a container's elements) or one of the resolvers (for a column).

The type comes from a: two vectors reaching one comparator always carry the same type — the sort compares one column against itself and the join's planner gate requires identical key types.

func DateLiteralDays ¶ added in v0.18.3

func DateLiteralDays(v any) (int32, error)

DateLiteralDays is toDateInt32 exported for exec.dateConstError to recover the same failure ResolveFilterKernel/ResolveInFilterKernel already saw when they returned a nil kernel for a DATE constant, mirroring CidrSortKey/IPv6LitKey/DecimalConstText's role for their own types.

func DecimalConstText ¶ added in v0.18.1

func DecimalConstText(v any) (string, bool)

DecimalConstText renders a comparison constant as the decimal text a DECIMAL column's domain is reached through, and reports whether the constant IS a number.

The second result is not decoration. A constant nobody can read used to resolve to the value ZERO and match every stored zero (#463) — the worst shape a failure can take, because it neither errors nor returns nothing. PostgreSQL refuses the query instead ("invalid input syntax for type numeric"), and ADR-0012 makes PostgreSQL the authority on error-versus-not, so a false here is a query error at the caller, not a value.

Exponent form is passed through untouched: batch.DecimalTextAt folds the exponent into the scaling exactly, where expanding it through a float64 first is what lost 1e400 entirely.

func FiniteDecimalText ¶ added in v0.18.5

func FiniteDecimalText(s string) bool

FiniteDecimalText reports whether text names a FINITE number — isDecimalText without the comparison bounds.

It exists for the one caller whose question is not "can a DECIMAL column be compared against this": folding a unary minus into a quoted string literal (expr.compileWithCtx). `-'NaN'` is not a value in PostgreSQL either — an unknown-typed literal under unary minus is 42725 there, "operator is not unique" — and negating the text would produce '-NaN', which PostgreSQL's numeric input refuses outright. So that fold keeps the narrow reader and `-'NaN'` stays the refusal it already was.

func Float32LitUnrepresentable ¶ added in v0.18.5

func Float32LitUnrepresentable(v any) bool

Float32LitUnrepresentable reports whether a literal's boxed value is one PostgreSQL refuses to put in a `real`. It is the check exec.floatConstError turns into 22003, the same "nil kernel, caller raises" convention DateLiteralDays serves for DATE.

func FloatCompareOp ¶ added in v0.18.1

func FloatCompareOp[T FloatOrdered](a, b T, op CompareOp) bool

FloatCompareOp applies one of the six predicates to a pair. The row-at-a- time paths (exec's ColumnCompare fallback, expr's CmpFloat64) use this so they answer what the vectorized kernel answers; the kernels themselves resolve the operator ONCE and keep the per-row form above.

func FloatEq ¶ added in v0.18.1

func FloatEq[T FloatOrdered](a, b T) bool

FloatEq reports a = b under PostgreSQL's float order (NaN equals NaN).

func FloatGe ¶ added in v0.18.1

func FloatGe[T FloatOrdered](a, b T) bool

FloatGe reports a >= b under PostgreSQL's float order.

func FloatGt ¶ added in v0.18.1

func FloatGt[T FloatOrdered](a, b T) bool

FloatGt reports a > b under PostgreSQL's float order.

func FloatLe ¶ added in v0.18.1

func FloatLe[T FloatOrdered](a, b T) bool

FloatLe reports a <= b under PostgreSQL's float order.

func FloatLt ¶ added in v0.18.1

func FloatLt[T FloatOrdered](a, b T) bool

FloatLt reports a < b under PostgreSQL's float order (NaN is greatest).

func FloatNe ¶ added in v0.18.1

func FloatNe[T FloatOrdered](a, b T) bool

FloatNe reports a <> b under PostgreSQL's float order.

`a == a || b == b` rather than `!(a != a && b != b)`: the two are the same predicate, but this one short-circuits on the FIRST operand for every non-NaN row, which is the row the branch predictor sees.

func FloatSpecialText ¶ added in v0.18.5

func FloatSpecialText(text string) (float64, bool)

FloatSpecialText reads the NaN/±Infinity spellings PostgreSQL's FLOAT input accepts, and reports ok=false for everything else — including ordinary numbers, which are the caller's own business.

It is deliberately a second reader beside batch.DecimalSpecialText, because the two grammars differ in one place and that place is observable: float8 accepts a SIGNED NaN (`'+NaN'::float8` and `'-NaN'::float8` are both NaN) where numeric refuses it with 22P02. Verified live on postgres:17-alpine (17.11) for both float8 and float4; everything else matches — case insensitive, C whitespace stripped, `inf` and `infinity` with an optional adjacent sign, and no prefix matching (`Infin`, `infinit`, `infinityy` and `- inf` are all refused).

The VALUE returned is the ordinary IEEE one, so the caller compares it with CompareFloat64 and gets PostgreSQL's float order for free: a FLOAT column HOLDS all three, so its comparison against one of them is a plain float comparison — unlike DECIMAL, where the same literal is a BOUND because the carrier has no such value at all (ADR-0024 item 6, #534).

func IPv4LitKey ¶ added in v0.18.3

func IPv4LitKey(s string) (int64, bool)

IPv4LitKey exports parseIPv4ToInt64 for exec.networkConstError, which needs to know whether a filter literal named an address at all — not just its encoded value — the same way kernel.IPv6LitKey and kernel.CidrSortKey already do for their two types.

func IPv6LitKey ¶ added in v0.18.2

func IPv6LitKey(s string) (key string, ok bool)

IPv6LitKey re-keys an IPv6 filter literal into the form a TypeIPv6 column's rows compare against: the address's raw 16 bytes, which a byte comparison orders exactly as the address's own big-endian numeric value.

A v4-shaped literal is not that, and is not a v4-MAPPED v6 address either. PostgreSQL's inet compares the FAMILY first and puts every v4 address below every v6 one (`'255.255.255.255'::inet < '::'::inet` is true), including below a v4-mapped v6 address, which it still calls family 6 (`family('::ffff:10.0.0.2'::inet)` answers 6). The key for a v4 literal is therefore the EMPTY string: it is shorter than, and a prefix of, every 16-byte row value, so it compares strictly below all of them and equals none — PostgreSQL's family rule, with no per-row re-keying.

Reading a v4 literal as its v4-mapped 16 bytes instead — which is what the TypeIPv6 kernel arm used to do, through a plain net.ParseIP — placed it in the MIDDLE of the v6 range (below 2001:db8:: and above ::1), while the row-at-a-time path fell through to a lexical text comparison entirely: two paths, two orders, neither PostgreSQL's.

ok is false for a literal that is no address at all; the caller raises the query error, the same as CidrSortKey's.

func IPv6RowKey ¶ added in v0.18.3

func IPv6RowKey(s string) (string, bool)

IPv6RowKey re-keys a TypeIPv6 column's RENDERED text back into the raw 16 bytes the column actually stores, which is what the vectorized kernel compares (ResolveColColFilterKernel's TypeIPv6 arm reads BytesData directly) and what a byte comparison orders as the address's own big-endian value.

It exists because the two evaluation sites read the column through different doors. The kernel has the vector and reads the 16 bytes; the row-at-a-time evaluator has ColRef.Eval's BOX, which for TypeIPv6 is the address's TEXT (Vector.GetValue renders `net.IP(raw).String()`). Comparing that text lexically is not the address's order — "2001:db8::9" sorts ABOVE "2001:db8::10" as text and BELOW it as an address — so `WHERE a < z` answered one thing through the scan and the opposite through a projection or a later DAG stage's re-parsed filter (#565, #492's finding one type over).

The round trip is exact: Vector.SetValue stores `net.ParseIP(s).To16()` and GetValue renders that back, so parsing the rendering recovers the identical bytes — including for a v4-MAPPED address, which Go renders as a dotted quad and re-parses to the same v4-mapped 16 bytes, keeping the row on the v6 side of PostgreSQL's family split the way the stored bytes already put it. That is why this is NOT IPv6LitKey: a LITERAL dotted quad is a v4 address and keys BELOW every v6 row (PostgreSQL compares family first), while a STORED one is a v4-mapped v6 address and keys among them.

ok is false for a rendering that names no address, which a 16-byte column does not produce — GetValue answers "" only for a value that is not 16 bytes wide, which SetValue never writes.

func Int32FilterBound ¶ added in v0.18.11

func Int32FilterBound(v any, op CompareOp) (int32, CompareOp, IntBoundVerdict, IntConstStatus)

Int32FilterBound is IntFilterBound narrowed to the int32-backed integer types. A bound OUTSIDE int32 is the whole column's answer here rather than the IntConstRange refusal Int32FilterConst makes for an equality constant: `c_i32 > 3.5e9` names no int32 and no int32 satisfies it, which is a verdict and not an error.

func IntFilterBound ¶ added in v0.18.11

func IntFilterBound(v any, op CompareOp) (int64, CompareOp, IntBoundVerdict, IntConstStatus)

IntFilterBound resolves an integer column's filter constant AND its operator together, which is what a NON-INTEGRAL constant needs and Int64FilterConst alone cannot give (#704).

`int64(3.5)` is 3, so `c = 3.5` matched the row holding 3 and `c IN (3.5)` matched it too; Go truncates TOWARD ZERO, so `c = -0.5` matched the row holding 0. PostgreSQL compares `bigint = numeric` exactly and answers no rows for all three. The typemx measurement in the arc brief read 0 for the INT64 column only because no row of it holds 3 — `c_i64 = 1000003.5` matched one, which is the same defect one fixture row away.

For an integer column c and a constant f with a fraction, floor(f) = n:

c =  f  ->  no row          c <> f  ->  every non-NULL row
c >  f  ->  c >  n          c >= f  ->  c >  n
c <  f  ->  c <= n          c <= f  ->  c <= n

The same rewrite answers a constant OUTSIDE int64 entirely (±Infinity included, which is why the infinities need no arm of their own): there the verdict is the whole column's, one way or the other. A NaN constant declines — the caller raises rather than comparing against an implementation-defined conversion — and no SQL spelling reaches this with one, since a quoted 'NaN' is read by the integer grammar and refused there.

Every non-float box delegates to Int64FilterConst with the operator unchanged, so the ordinary path is exactly what it was.

func IsDateSyntaxError ¶ added in v0.18.4

func IsDateSyntaxError(err error) bool

IsDateSyntaxError reports whether err is a malformed-DATE-literal failure (PostgreSQL 22007, invalid_datetime_format) as opposed to a nonexistent or out-of-range calendar date (22008, datetime_field_overflow). exec. dateConstError reads it to pick the SQLSTATE, the same "nil kernel, caller raises" convention CidrSortKey/DecimalConstText use. The classification is owned by parquet.ParseDateDays, the one string->date conversion the filter path, the writers and the ingest boundary all share (#560).

func KeyFloat32Bits ¶ added in v0.18.1

func KeyFloat32Bits(f float32) uint32

KeyFloat32Bits is KeyFloat64Bits for float32.

func KeyFloat64Bits ¶ added in v0.18.1

func KeyFloat64Bits(f float64) uint64

KeyFloat64Bits / KeyFloat32Bits are Float64bits/Float32bits over the canonical value — the bits any KEY, hash or partition router should use for a float.

func MACLitKey ¶ added in v0.18.3

func MACLitKey(s string) (int64, bool)

MACLitKey exports parseMACToInt64 for exec.networkConstError; see IPv4LitKey.

func NumericTypeName ¶ added in v0.18.5

func NumericTypeName(typ batch.TypeID) (string, bool)

NumericTypeName is the PostgreSQL type name a numeric column's refusal message carries. ok=false for every type with no literal rule of this kind.

The wadjet-native PORT/PROTOCOL/DURATION have no PostgreSQL equivalent, so they name themselves; the rest use PostgreSQL's own spelling, which the pg-oracle's wire arm checks byte-for-byte.

func ParseBoolText ¶ added in v0.18.4

func ParseBoolText(s string) (val, ok bool)

ParseBoolText is `parse_bool_with_len` (src/backend/utils/adt/bool.c), which is what PostgreSQL's `text::boolean` runs — the boolean INPUT grammar, not a rendered-bool string match.

It accepts, case-insensitively and after trimming C `isspace` whitespace, any non-empty PREFIX of "true", "false", "yes" or "no", plus "on"/"off" and the single characters "1" and "0". The prefix rule is not decoration: `'tr'::boolean` and `'fals'::boolean` answer on live PostgreSQL 17, and a stricter reader would raise 22P02 for values PostgreSQL accepts. "o" alone is the one prefix REFUSED, because it cannot choose between "on" and "off".

This is the ONE binding for the grammar (#574): both comparison paths read a BOOL-column-versus-text-literal through it — the vectorized kernel here (ResolveFilterKernel's TypeBool arm and inFilterBool) and the row-at-a-time expr.compare — so they can no longer disagree with each other or with PostgreSQL. internal/engine/expr.parseBoolText delegates here rather than keeping a second copy. Before this, kernel.toBool read every string as false (so `bo = 't'` matched the FALSE rows) while expr.compare rendered the bool as "true"/"false" and matched only those exact spellings — two wrong answers in opposite directions, ADR-0012 item 8's two-path split one type over from the boxed-pair fixes.

func QuotedConstText ¶ added in v0.18.5

func QuotedConstText(v any) (string, bool)

QuotedConstText reports a filter constant's TEXT when the constant is a QUOTED literal (or a text-shaped parameter), and ok=false for a numeric box.

This is the whole of the quoted-versus-numeric distinction the rule turns on, and it is deliberately a test of the BOX rather than of a declaration: the planner boxes a quoted string literal as a Go string and an unquoted numeric literal as a float64/int64/int (see exec.decimalLitValue, which substitutes a numeric literal's source text ONLY for the DECIMAL and STRING column types), so "which spelling did the user write" is exactly what the box carries here and nothing else does.

func RealLitTextUnrepresentable ¶ added in v0.18.5

func RealLitTextUnrepresentable(text string) bool

RealLitTextUnrepresentable reports whether literal TEXT names a number a `real` cannot carry, in either direction — the condition that makes PostgreSQL's cast of an IN list to real[] fail with 22003. Both directions: 1e40 overflows to +Inf and 1e-46 underflows to 0.0, and each would match rows the predicate must not (see kernel.Float32Fit).

Text, not a float64 box: the box has already been through the compiler's numeric conversion, and a literal past float64's OWN range (1e400) arrives there as +Inf, which is a legal real value and would be waved through. Reading the digits keeps "the user wrote a number too big for a real" apart from "the user wrote infinity", which PostgreSQL also keeps apart (#549's Float32FitOf draws the same distinction for a boxed value).

func RealOverflowText ¶ added in v0.18.5

func RealOverflowText(text string) string

RealOverflowText renders a numeric literal's source text the way PostgreSQL's `numeric` output does — expanded, never in exponent form — for the SQLSTATE 22003 message raised when that literal will not fit a `real`.

The message is part of the answer, not decoration. PostgreSQL raises

ERROR:  "10000000000000000000000000000000000000000" is out of range for type real

for `real IN (1e40, 3.1)`, and it prints the same forty-one digits whether the query spelled the literal 1e40, 1e+40, 1.0e40 or in full: the cast that fails is numeric->real, and a numeric's text is its digits. Wadjet used to print whatever Go's %v gave the boxed float64 ("1e+40"), so the two evaluation paths could not even produce the same message for the same query, and neither matched PostgreSQL (ADR-0012 item 1 makes the SQLSTATE and its text PostgreSQL's to decide).

Text that is not a number at all is returned unchanged: this function renders, it does not validate — the caller has already established that the value overflows.

func StatsDomainValue ¶ added in v0.18.1

func StatsDomainValue(typ batch.TypeID, scale int, v any) (any, bool)

StatsDomainValue converts a SQL literal into the representation a column's parquet STATISTICS and DICTIONARY entries are in, and reports whether the conversion exists.

It is the producer half of the rule the prune layer cannot enforce for itself: `scan.CanPruneRowGroup` compares two `any` values by their Go kind and has no idea what either MEANS, so a raw file bound and an engine literal that both land in the same kind get compared as if they agreed. Three columns did exactly that (#442, and #438 which is the same defect seen through a DECIMAL):

DECIMAL(18,4)  stats hold the UNSCALED integer (1500.15 -> 15001500)
               and the literal arrives as float64(1500.15), so every row
               group whose unscaled bound exceeds the literal is pruned.
IPV6, UUID     stats hold the RAW 16 bytes and the literal arrives as
               text, and '2' (0x32) sorts above every byte of a
               2001:db8:: address, so every row group is pruned.

The engine's own order for those columns is the stored one — the filter kernel converts the LITERAL (IPv6LitKey, and decimalLiteralAt against the vector's scale) rather than rendering the column — so this function is that same conversion, hoisted to where the planner still knows the column's type and scale. Rendering the bounds the other way would be wrong for IPv6: text order is not address order ('2001:db8::10' sorts below '2001:db8::5').

A false second result means "no conversion" and the caller must WITHHOLD the predicate from the prune layer entirely. Every type is listed explicitly and there is no pass-through default, because a new type that silently inherited "compare it raw" is precisely how this class arrives.

func UUIDLiteralToRaw ¶

func UUIDLiteralToRaw(s string) (string, bool)

UUIDLiteralToRaw is parseUUIDToRawString for the row-at-a-time predicate in package exec, so the two comparison paths convert the literal identically.