Get desktop application:
View/edit binary Protocol Buffers messages
This represents the serialized form of the annotation map for bigquery_ml_utils::AnnotatedType.
Indicates that an element of array or a field of struct is null. In ArrayAnnotationMap and StructAnnotationMap class, a null element/field indicates that the AnnotationMap for the element/field (and all its children if applicable) is empty. <is_null> can only be true for struct field or array element, or an error is throw during deserialization. If <is_null> is true, the rest of this proto is ignored.
If AnnotatedType is a complex type, then exactly one of the two fields will be populated.
Map entry from AnnotationSpec ID to AnnotationValue.
Used in:
Key for the map entry.
Value of the map entry.
Used in:
(message has no fields)
DEPRECATED - Encoding has been folded into the Type enum above. This should not be used directly.
Like in FieldFormat, PACKED32 is the wrong name, and people should be using DATE_DECIMAL instead. This whole enum definition is deprecated though, so this definition probably won't be fixed.
This is the wrong name. The format is DATE_DECIMAL.
Contains information about a deprecation warning emitted by the analyzer. Currently attached to any absl::Status returned by AnalyzerOutput::deprecation_warnings().
Used in:
Used in:
User code that switches on this enum must have a default case so builds won't break if new enums get added.
proto.has_<field>() is not well-defined if 'proto' comes from a file with proto3 syntax, but it is currently supported by the analyzer.
Used in:
The _full_ name of the enum without the catalog name.
The index of the FileDescriptorSet in the top-level TypeProto that can be used to deserialize this particular EnumType.
An opaque enum type 'hides' it's proto-based implementation from the end-user. See bigquery_ml_utils::EnumType::IsOpaque for more information.
This proto is used as a absl::Status error payload to give the location for SQL parsing and analysis errors.
Used in: ,
1-based <line> and <column> offset in the input SQL string. <column> may point to one character off the end of a line when the error occurs at end-of-line. NOTE: <line> is computed assuming lines can be split with \n, \r or \r\n, and <column> is computed assuming tabs expand to eight characters.
An optional filename related to the error, if applicable. May be used to express more general error source information than a filename, for instance if the error comes from a module imported from datascape. ErrorLocation typically gets formatted as 'filename:line:column', so this field content should make sense in this format (i.e., it should probably avoid whitespace).
An optional list of error source information for the related Status. The last element in this list is the immediate error cause, with the previous element being its cause, etc. These error sources should normally be displayed in reverse order.
Mode describing how errors should be constructed in the returned absl::Status.
The error string does not contain a location. An ErrorLocation proto will be attached to the absl::Status with a location, when applicable. See error_helpers.h for working with these payloads. See error_location.proto for how line and column are defined.
The error string contains a suffix " [at <line>:<column>]" when an error location is available.
The error string matches ERROR_MESSAGE_ONE_LINE, and also contains a second line with a substring of the input query, and a third line with a caret ("^") pointing at the error location above.
This proto indicates an error that is the source of another error. It is expected that all of <error_message>, <error_message_caret_string>, and <error_location> are populated in normal use cases. An example of usage is for deferred, nested resolution of SQL expressions related to SQL UDFs inside Modules. Resolving a SQL UDF (func1) that references another SQL UDF (func2) can cause nested resolution, and if the resolution of func2 fails then that error information is captured in an ErrorSource that is attached to the error Status returned by func1's resolution. The returned Status may also have its own ErrorLocation related to func1, while the ErrorSource will be specific to func2's resolution.
Used in: ,
The error message for this ErrorSource.
An additional error string added to <error_message> when in ErrorMessageMode ERROR_MESSAGE_MODE_MULTI_LINE_WITH_CARET. This is constructed as one line of input text, a newline, and then a second line with the caret in the position pointing at the error in the first line.
The error location indicating a position in the original input file containing the statement with the error. This <error_location> should not itself have <error_source> filled in.
(message has no fields)
No format annotation. This is meant as a no-annotation marker in code and should not actually be written as an annotation in .proto files.
A SQL DATE, encoded as days since 1970-01-01 UTC. Can be applied to a field with ctype int32 or an int64. The function DecodeFormattedDate in public/functions/date_time_util.h can be used to decode all supported date formats.
A SQL timestamp. Timestamps are encoded as elapsed seconds, millis, micros, or nanos since 1970-01-01 00:00:00 UTC. TIMESTAMP_SECONDS is the standard unix time_t type. Should be applied to fields with ctype int64.
A SQL DATE encoded in the MySQL date decimal format, which looks like YYYYMMDD written as an integer. Can be applied to a field with type int32 or an int64. NOTE: The value 0 decodes to NULL in this format. (Otherwise it would be an invalid date.) The function DecodeFormattedDate in public/functions/date_time_util.h can be used to decode all supported date formats.
A SQL TIME encoded in an 8-byte bit field. See public/civil_time.h for encoding methods. Can be applied to a field with ctype int64.
A SQL DATETIME encoded in an 8-byte bit field. See public/civil_time.h for encoding methods. Can be applied to a field with ctype int64. NOTE: The value 0 decodes to NULL in this format. (Otherwise it would be an invalid datetime.) To have the default DATETIME value at 1970-01-01 00:00:00, use 138630961515462656 as the default integer value.
A SQL GEOGRAPHY encoded using either C++'s STGeographyEncoder::Encode (util/geometry/st_lib/stgeography_coder.h) or Java's STGeographyCoder.encode (java/com/google/common/geometry/stlib/STGeographyCoder.java). Can be applied to bytes fields.
A SQL NUMERIC value. These values are encoded as scaled integers in two's complement form with the most significant bit storing the sign. See NumericValue::SerializeAsProtoBytes() for serialization format details. Can be applied to bytes fields.
A SQL BIGNUMERIC value. These values are encoded as scaled integers in two's complement form with the most significant bit storing the sign. See BigNumericValue::SerializeAsProtoBytes() for serialization format details. Can be applied to bytes fields.
A SQL JSON value. These values are encoded as JSON strings according to the JSON RFC (RFC 7159)). Can be applied to string fields.
A SQL INTERVAL value. See IntervalValue::SerializeAsBytes() for serialization format details. Can be applied to bytes fields.
User code that switches on this enum must have a default case so builds won't break if new enums get added.
A non-absl::Status-based representation of a deprecation warning that can be stored in objects that can be stored in the resolved AST (e.g., FunctionSignatures).
Serialized form of ParseLocationPoint, only to be used inside the SQL library to attach an error location in internal form to a absl::Status. This should never leave the library: externally we should attach an ErrorLocation proto.
An optional list of error source information for the related Status. The last element in this list is the immediate error cause, with the previous element being its cause, etc.
The list of optional features that engines may or may not support. Features can be opted into in AnalyzerOptions. There are three types of LanguageFeatures. * Cross-version - Optional features that can be enabled orthogonally to versioning. Some engines will never implement these features, and SQL code will always support this switch. * Versioned - Features that describe behavior changes adopted as of some language version. Eventually, all engines should support these features, and switches in the SQL code (and tests) should eventually be removed. All of these, and only these, show up in VERSION_CURRENT. * Experimental - Features not currently part of any language version. All optional features are off by default. Some features have a negative meaning, so turning them on will remove a feature or enable an error.
Enable analytic functions. See (broken link).
Enable the TABLESAMPLE clause on scans. See (broken link).
If enabled, give an error on GROUP BY, DISTINCT or set operations (other than UNION ALL) on floating point types. This feature is disabled in the idealized SQL (i.e. LanguageOptions::EnableMaximumLanguageFeatures) because enabling it turns off support for a feature that is normally on by default.
If enabled, treats TIMESTAMP literal as 9 digits (nanos) precision. Otherwise TIMESTAMP has 6 digits (micros) precision. In general, a TIMESTAMP value has only 6 digits precision. This feature will only affect how a timestamp literal string is interpreted into a TIMESTAMP value. If enabled, a timestamp literal string can have up to 9 digits of subseconds(nanos). Otherwise, it can only have up to 6 digits of subseconds (micros). 9 digits subsecond literal is not a valid timestamp string in the later case.
Enable support for JOINs in UPDATE statements, see (broken link).
Enable table-valued functions. For more information, see table_valued_functions.h.
This enables support for CREATE AGGREGATE FUNCTION.
This enables support for CREATE TABLE FUNCTION. For more information, see (broken link).
This enables support for GROUP BY ROLLUP.
This enables support for creating and calling functions with templated argument types, using CREATE FUNCTION, CREATE AGGREGATE FUNCTION, or CREATE TABLE FUNCTION statements. For example, a function argument may be written as "argument ANY TYPE" to match against any scalar value. For more information, see (broken link).
Enables support for PARTITION BY with CREATE TABLE and CREATE TABLE AS. See (broken link).
Enables support for CLUSTER BY with CREATE TABLE and CREATE TABLE AS. See (broken link).
NUMERIC type support, see (broken link).
Enables support for NOT NULL annotation in CREATE TABLE. See comment on FEATURE_CREATE_TABLE_FIELD_ANNOTATIONS and (broken link) for details.
Enables support for annotations (e.g., NOT NULL and OPTIONS()) for struct fields and array elements in CREATE TABLE. Does not affect table options or table column annotations. Example: Among the following queries Q1: CREATE TABLE t (c STRUCT<a INT64> NOT NULL) Q2: CREATE TABLE t (c STRUCT<a INT64 NOT NULL>) Q3: CREATE TABLE t (c STRUCT<a INT64> OPTIONS(foo=1)) Q4: CREATE TABLE t (c STRUCT<a INT64 OPTIONS(foo=1)>) Q5: CREATE TABLE t (c STRUCT<a INT64 NOT NULL OPTIONS(foo=1)>) Allowed queries FEATURE_CREATE_TABLE_FIELD_ANNOTATIONS =0 =1 FEATURE_CREATE_TABLE_NOT_NULL=0 {Q3} {Q3, Q4} FEATURE_CREATE_TABLE_NOT_NULL=1 {Q1, Q3} {Q1, Q2, Q3, Q4, Q5} See (broken link).
Enables support for column definition list in CREATE TABLE AS SELECT. Example: CREATE TABLE t (x FLOAT64) AS SELECT 1 x The features in the column definition list are controlled by FEATURE_CREATE_TABLE_NOT_NULL and FEATURE_CREATE_TABLE_FIELD_ANNOTATIONS.
Indicates that an engine that supports primary keys does not allow any primary key column to be NULL. Similarly, non-NULL primary key columns cannot have any NULL array elements or struct/proto fields anywhere inside them. Only interpreted by the compliance tests and the reference implementation (not the analyzer). It exists so that engines can disable tests for this atypical behavior without impacting their compliance ratios. It can never be totally enforced in the analyzer because the analyzer cannot evaluate expressions.
Indicates that an engine that supports primary keys does not allow any primary key column to be modified with UPDATE. Only interpreted by the compliance tests and the reference implementation (not the analyzer) for now. It exists so that engines can disable tests for this atypical behavior without impacting their compliance ratios.
Enables support for the TABLESAMPLE clause applied to table-valued function calls. For more information about table-valued functions, please see table_valued_functions.h and (broken link).
Enable encryption- and decryption-related functions. See (broken link).
Differentially private anonymization functions, syntax, and semantics. ((broken link)).
Geography type support per (broken link)
Enables support for stratified TABLESAMPLE. For more information about stratified sampling, please see: (broken link).
Enables foreign keys (see (broken link)).
Enables BETWEEN function signatures for UINT64/INT64 comparisons.
Enables check constraint (see (broken link)).
Enables statement parameters and system variables in the GRANTEE list of GRANT, REVOKE, CREATE ROW POLICY, and ALTER ROW POLICY statements.
Enables support for named arguments in function calls using a syntax like this: 'SELECT function(argname => 'value', otherarg => 42)'. Function arguments with associated names in the signature options may specify values by providing the argument name followed by an equals sign and greater than sign (=>) followed by a value for the argument. Function calls may include a mix of positional arguments and named arguments. The resolver will compare provided arguments against function signatures and handle signature matching appropriately. For more information, please refer to (broken link).
Enables support for the old syntax for the DDL for ROW ACCESS POLICY, previously called ROW POLICY. When this feature is enabled, either the legacy or new syntax can be used for CREATE/DROP ROW [ACCESS] POLICY. Note, however, that when using the new syntax the GRANT TO clause is required (the GRANT TO clause is optional when the feature is off). When it is not enabled, the new syntax must be used for CREATE ROW ACCESS POLICY and DROP ALL ROW ACCESS POLICIES. The new syntax is always required for ALTER ROW ACCESS POLICY and DROP ROW ACCESS POLICY: at the time of this writing, these statements are new/not in use. This is a temporary feature that preserves legacy engine behavior that will be deprecated, and the new syntax will become mandatory. For more details on syntax changes, see (broken link).
Enables support for PARTITION BY with CREATE MATERIALIZED VIEW. See (broken link).
Enables support for CLUSTER BY with CREATE MATERIALIZED VIEW. See (broken link).
Enables support for column definition list in CREATE EXTERNAL TABLE. Example: CREATE EXTERNAL TABLE t (x FLOAT64)
Enables using NOT ENFORCED in primary keys. See (broken link).
BIGNUMERIC data type. (broken link)
Extended types (TYPE_EXTENDED): (broken link).
JSON data type. (broken link)
Enables support for WITH PARTITION COLUMNS in CREATE EXTERNAL TABLE. Example: CREATE EXTERNAL TABLE t WITH PARTITION COLUMNS (x int64) More details: (broken link)
INTERVAL data type. (broken link)
If enabled, JSON parsing fails for JSON documents containing number values that cannot fit into the range of numbers supported by uint64, int64 or double. For unsigned integers, the valid range is [0, 2^64-1] For signed integers, the valid range is [-2^63, 2^63-1]. For floating point values, the valid range contains all numbers that can round-trip from string -> double -> string. The round-tripped string doesn't need to match the input string exactly, but must hold the same number value (i.e. "1e+3" -> double -> "1000" is a valid round-trip). If precision loss occurs as a result of the round-trip, the number is not considered valid (i.e. 0.142857142857142857142857142857142857 -> double -> 14285714285714285 is not valid).
When enabled, (table) function argument names will hide column names in expression resolution and relational table function argument names will hide table names from the catalog. This changes name resolution and is a backward compatibility breaking change.
Enables support for the following parameterized types. - STRING(L) / BYTES(L) - NUMERIC(P) / NUMERIC(P, S) - BIGNUMERIC(P) / BIGNUMERIC(P, S) See (broken link) for details.
Enables support for CREATE TABLE LIKE Example: CREATE TABLE t1 LIKE t2
Enable support for JSON_EXTRACT_STRING_ARRAY, JSON_VALUE_ARRAY and JSON_QUERY_ARRAY. (broken link)
Enables explicit column list for CREATE VIEW. Example: CREATE VIEW v(a, b) AS SELECT ...
Enables support for CREATE TABLE CLONE Example: CREATE TABLE t1 CLONE t2
Enables support for CLONE DATA INTO Example: CLONE DATA INTO ds.tbl;
Enables support for ALTER COLUMN SET DATA TYPE. See (broken link) for details.
Enables support for CREATE SNAPSHOT TABLE (broken link)
Enables support for defining argument defaults in function calls using syntax like: CREATE FUNCTION foo (a INT64 DEFAULT 5) AS (a); In effect, the argument with a default becomes optional when the function is called, like: SELECT foo(); For more information, please refer to (broken link).
Enables support for WITH CONNECTION in CREATE EXTERNAL TABLE. Example: CREATE EXTERNAL TABLE t WITH CONNECTION `project.region.connection_1` More details: (broken link)
Enables support for CREATE TABLE COPY Example: CREATE TABLE t1 COPY t2
Enables support for ALTER TABLE RENAME COLUMN. See (broken link) for details.
Enables STRING(JSON), INT64(JSON), BOOL(JSON), DOUBLE(JSON), JSON_TYPE(JSON) functions. See (broken link) for details.
Disallows "unicode", "unicode:ci", "unicode:cs" in ORDER BY ... COLLATE and other collation features. "unicode" is a legacy feature, and the desired behavior is to allow only "binary" and valid icu language tags. Enabling this feature must produce an error if 'unicode' is specified as a collation name.
Enables TIMESTAMP_BUCKET, DATE_BUCKET and DATETIME_BUCKET functions. See (broken link) for details.
Enables the new trigonometric math functions CSC, SEC, COT, CSCH, SECH, and COTH DEPRECATED
RANGE data type. (broken link)
Enable support for non SQL procedure.
Enables the CBRT function
Enable support for Spanner-specific DDL syntax. This is an extended syntax mode allowing compatibility with legacy Spanner DDL syntax and is meant to allow Cloud Spanner Emulator to use SQL for all processing needs. It is implemented only in the parser and analysis is disallowed in this mode, with resolver failing immediately. Spanner-specific syntax is not supported outside of this mode and will cause parsing errors.
This feature can be enabled to disable the new SQL functions ARRAY_MIN and ARRAY_MAX. It is here to ensure there is a way to turn these functions off in case they cause trouble.
When FEATURE_FUNCTION_ARGUMENTS_WITH_DEFAULTS is also enabled, apply a strict (and correct) type coercion from the given default argument value to the specified argument type. This feature is disabled by default, to avoid breaking existing production queries that rely on FEATURE_FUNCTION_ARGUMENTS_WITH_DEFAULTS.
Enable ORDER BY COLLATE. See (broken link).
Enable WITH clause on subqueries. Without this, WITH is allowed only at the top level. The WITH subqueries still cannot be correlated subqueries.
Enable the SELECT * EXCEPT and SELECT * REPLACE features. See (broken link).
Enable the ORDER BY in aggregate functions. See (broken link)
Enable casting between different array types.
Enable comparing array equality.
Enable LIMIT in aggregate functions.
Enable HAVING modifier in aggregate functions.
Enable IGNORE/RESPECT NULLS modifier in analytic functions.
Enable IGNORE/RESPECT NULLS modifier in aggregate functions.
Enable FOR SYSTEM_TIME AS OF (time travel). See (broken link).
Enable TIME and DATETIME types and related functions.
Enable SAFE mode function calls. e.g. SAFE.FUNC(...) for FUNC(...). (broken link).
Enable support for GROUP BY STRUCT.
Enable use of proto extensions with NEW.
Enable support for GROUP BY ARRAY.
Enable use of proto extensions with UPDATE ... SET.
Allows nested DML statements to refer to names defined in the parent scopes. Without this, a nested DML statement can only refer to names created in the local statement - i.e. the array element. Examples that are allowed only with this option: UPDATE Table t SET (UPDATE t.ArrayColumn elem SET elem = t.OtherColumn) UPDATE Table t SET (DELETE t.ArrayColumn elem WHERE elem = t.OtherColumn) UPDATE Table t SET (INSERT t.ArrayColumn VALUES (t.OtherColumn)) UPDATE Table t SET (INSERT t.ArrayColumn SELECT t.OtherColumn)
Enable use of WEEK(<Weekday>) with the functions that support it.
Enable use of array element [] syntax in targets with UPDATE ... SET. For example, allow UPDATE T SET a.b[OFFSET(0)].c = 5.
Enable nested updates/deletes of the form UPDATE/DELETE ... WITH OFFSET AS ... .
Enable Generated Columns on CREATE and ALTER TABLE statements. See (broken link).
Enables support for the PROTO_DEFAULT_IF_NULL() function, see (broken link)
Enables support for proto field pseudo-accessors in the EXTRACT function. For example, EXTRACT(FIELD(x) from foo) will extract the value of the field x defined in message foo. EXTRACT(HAS(x) from foo) will return a boolean denoting if x is set in foo or NULL if foo is NULL. EXTRACT(RAW(x) from foo) will get the value of x on the wire (i.e., without applying any FieldFormat.Format annotations or automatic conversions). If the field is missing, the default is always returned, which is NULL for message fields and the field default (either the explicit default or the default default) for primitive fields. If the containing message is NULL, NULL is returned. (broken link)
If enabled, the analyzer will return an error when attempting to check if a proto3 scalar field has been explicitly set (e.g., proto3.has_scalar_field and EXTRACT(HAS(scalar_field) from proto3)). This feature is deprecated and should not be used, since proto3 now supports scalar field presence testing. Eventually we will remove this feature and the underlying code.
Enable array ordering (and non-equality comparisons). This enables arrays in the ORDER BY of a query, as well as in aggregate and analytic function arguments. Also enables inequality comparisons between arrays (<, <=, >, >=). This flag enables arrays for MIN/MAX, although semantics over array inputs are surprising sometimes. Note: there is a separate flag for GREATEST/LEAST, as not all engines are ready to implement them for arrays. Spec: (broken link)
Allow omitting column and value lists in INSERT statement and INSERT clause of MERGE statement. Spec: (broken link)
If enabled, the 'use_defaults' and 'use_field_defaults' annotations are ignored for proto3 scalar fields. This results in the default value always being returned for proto3 scalar fields that are not explicitly set, including when they are annotated with 'use_defaults=false' or their parent message is annotated with 'use_field_defaults=false'. This aligns with proto3 semantics as proto3 does not expose whether scalar fields are set or not.
Enables support for the REPLACE_FIELDS() function. REPLACE_FIELDS(p, <value> AS <field_path>) returns the proto obtained by setting p.field_path = value. If value is NULL, this unsets field_path or returns an error if the last component of field_path is a required field. Multiple fields can be modified: REPLACE_FIELDS(p, <value_1> AS <field_path_1>, ..., <value_n> AS <field_path_n>). REPLACE_FIELDS() can also be used to modify structs using the similar syntax: REPLACE_FIELDS(s, <value> AS <struct_field_path>). (broken link)
Enable NULLS FIRST/NULLS LAST in ORDER BY expressions.
Allows dashes in the first part of multi-part table name. This is to accommodate GCP project names which use dashes instead of underscores, e.g. crafty-tractor-287. So fully qualified table name which includes project name normally has to be quoted in the query, i.e. SELECT * FROM `crafty-tractor-287`.dataset.table This feature allows it to be used unquoted, i.e. SELECT * FROM crafty-tractor-287.dataset.table
CONCAT allows arguments of different types, automatically coerced to STRING for FN_CONCAT_STRING signature. Only types which have CAST to STRING defined are allowed, and BYTES is explicitly excluded (since BYTES should match FN_CONCAT_BYTES signature).
Enable WITH RECURSIVE ((broken link))
Support maps in protocol buffers. ((broken link))
Enables support for the ENUM_VALUE_DESCRIPTOR_PROTO() function, see (broken link)
Allows DECIMAL as an alias of NUMERIC type, and BIGDECIMAL as an alias of BIGNUMERIC type. By itself, this feature does not enable NUMERIC type or BIGNUMERIC, which are controlled by FEATURE_NUMERIC_TYPE and FEATURE_BIGNUMERIC_TYPE.
Support UNNEST and FLATTEN on paths through arrays. ((broken link))
Allows consecutive ON/USING clauses for JOINs, such as t1 JOIN t2 JOIN t3 ON cond1 USING (col2)
Enables support for optional parameters position and occurrence in REGEXP_EXTRACT. In addition, allows alias REGEXP_SUBSTR. ((broken link))
Additional signatures for DATE, TIMESTAMP, TIME, DATETIME and STRING constructor functions.
Enables DATE +/- INT64 arithmetics. ((broken link))
Enable support for additional string functions.
Enable support for aggregate functions with WITH GROUP_ROWS syntax.
Additional signatures for [DATE|DATETIME|TIMESTAMP]_[ADD|SUB|DIFF|TRUNC] functions. ((broken link)).
Additional signatures for ST_GeogFromText/FromGeoJson/From* functions. ((broken link)).
Inline lambda function argument. (broken link)
PIVOT clause ((broken link)).
This flag enables propagation of annotation during query analysis. See public/types/annotation.h for the introduction of annotation framework. Engines must turn on this flag before turning on any built-in annotation feature or passing in engine defined AnnotationSpec.
Enables collation annotation support.
IS [NOT] DISTINCT FROM ((broken link)).
If true, FORMAT clause is supported in CAST(). Fully implemented: BYTES <=> STRING DATE/DATETIME/TIME/TIMESTAMP => STRING Under development: STRING => DATE/DATETIME/TIME/TIMESTAMP NUMBER => STRING
UNPIVOT clause ((broken link)).
If true, dml returning is supported ((broken link))
Enables support for the FILTER_FIELDS() function. FILTER_FIELDS(p, <-|+><field_path>, ...) returns the proto obtained by keeping p.field_path whose sign is '+' and remove p.field_path whose sign is '-'. (broken link)
QUALIFY clause ((broken link)).
Enable support for REPEAT...UNTIL...END REPEAT statement. (broken link)
Enables column DEFAULT clause in CREATE and ALTER TABLE statements. See (broken link)
Enable support for FOR...IN...DO...END FOR statement. // NOTYPO (broken link)
Enables support for initializing KLLs with weights as an additional parameter. Support for this feature in addition to the weighting functionality also requires support for named arguments as the weight argument must be named. (broken link).
LIKE ANY/SOME/ALL support. (broken link)
Enable support for CASE...WHEN...THEN...END CASE statement. (broken link)
Support for table names that start with slash and contain slashes, dashes, and colons before the first dot: /span/test/my-grp:db.Table. (broken link)
Enable the TYPEOF(expr) debugging and exploration function.
Enable support for SCRIPT LABELS (e.g. L1: BEGIN...END) (broken link)
Enable support for remote function (e.g. CREATE FUNCTION ... REMOTE ...) (broken link)
If Array ordering is enabled, this flag enables arrays for GREATEST/LEAST.
Enables braced constructors for protocol buffers. See (broken link)
Allow WITH-expressions. See (broken link).
Allow ordered elements in primary key definition. See (broken link).
Allow TTL clauses (ROW DELETION POLICY). See (broken link).
Allow bare array access like a[0]. See (broken link)
Enable builtin functions ARRAY_MIN, ARRAY_MAX, ARRAY_SUM and ARRAY_AVG.
Using string type argument as a placeholder for enum type argument. Related functions include ARRAY_OFFSET(S), ARRAY_FIND, and ARRAY_FIND_ALL. This language feature guard is added temporarily to unblock related functions development from enum development. This feature will be removed.
Enable SAFE mode for function calls with lambda arguments, e.g. SAFE.ARRAY_TRANSFORM(array_input, e -> 1 /e ) (broken link).
Enable support for remote models (e.g. CREATE MODEL ... REMOTE ...) (broken link)
Allow struct field access like s[OFFSET(0)]. See (broken link)
Enable SQL MODULES. For an engine to fully opt into this feature, they must enable this feature flag and add support for the related StatementKinds: RESOLVED_IMPORT_STMT and RESOLVED_MODULE_STMT. See (broken link)
These are not real features. They are just for unit testing the handling of various LanguageFeatureOptions.
User code that switches on this enum must have a default case so builds won't break if new enums get added.
Annotations for LanguageFeature enum values. Only for consumption by SQL code. LanguageOptions::EnableMaximumLanguageFeatures() enables all features with 'ideally_enabled == true' and 'in_development == false'. LanguageOptions::EnableMaximumLanguageFeaturesForDevelopment() enables all features with 'ideally_enabled == true'.
Indicates whether a feature is enabled in the idealized SQL. (One reason to disable a feature is if it exists only to support backwards compatibility with older SQL behavior.)
Indicates whether a feature is still undergoing development. Users should not enable features that are still in development, but internal SQL tests may do so.
SQL language versions. See (broken link) for more detail. A language version defines a stable set of features and required semantics. LanguageVersion VERSION_x_y implicitly includes the LanguageFeatures below named FEATURE_V_x_y_*. The features and behavior supported by an engine can be expressed as a LanguageVersion plus a set of LanguageFeatures added on top of that version. New version numbers will be introduced periodically, and will normally include the new features that have been specified up to that point. Engines should move their version number forwards over time rather than accumulating large sets of LanguageFeatures. LINT: LEGACY_NAMES
All current features, including features that are not part of a frozen version. For example, when v1.0 is the maximum released version number, this includes features that have been developed for v1.1. This does not include cross-version or experimental features. WARNING: Using this version means query behavior will change under you.
Version 1.0, frozen January 2015.
Version 1.1, frozen February 2017.
Version 1.2, frozen January 2018.
Version 1.3, frozen May 2022.
Version 1.4. Freeze May 2023 (12 mo)
User code that switches on this enum must have a default case so builds won't break if new enums get added.
This can be used to select strict name resolution mode. In strict mode, implicit column names cannot be used unqualified. This ensures that existing queries will not be broken if additional elements are added to the schema in the future. For example, SELECT c1, c2 FROM table1, table2; is not legal in strict mode because another column could be added to one of these tables, making the query ambiguous. The query must be written with aliases in strict mode: SELECT t1.c1, t2.c2 FROM table1 t1, table t2; SELECT * is also not allowed in strict mode because the number of output columns may change. See (broken link) for full details.
This is allowed only for hardcoded builtin enum types for use when they are used as opaque enums. The name should be SNAKE_CASE.
If true, SQL will treat this value as invalid when performing casting and coercion operations. Note: The proto-style guide requires each proto have a '<enum_name>_unspecified' value: https://developers.google.com/protocol-buffers/docs/style#enums However, in general, these enum values are not part of the SQL specification of a given enum type, and thus, should set this to true.
Mode describing how parameters are defined and referenced.
Parameters are defined by name (the default) and referenced using the syntax @param_name.
Parameters are defined positionally and referenced with ?. For example, if two parameters are bound, the first occurrence of ? in the query string refers to the first parameter and the second occurrence to the second parameter.
No parameters are allowed in the query.
This message stores the start and end byte offsets of a parsed string. It also (optionally) stores the name of the file where this parsed string is located.
If present, the name of the file containing the parsed string. It is expected that the start and end of a parsed string would both be located in just one file, so we have only one field to store the filename.
Byte offset of the first character of the symbol string.
Byte offset of the character after the last character of the symbol string.
The option controlling what kind of parse location is recorded in a resolved AST node.
Parse locations are not recorded.
Parse locations cover the entire range of the related node, e.g., the full function call text associated with a ResolvedFunctionCall, or the full expression text associated with a ResolvedCast.
Parse locations of nodes cover a related object name in the text, as convenient for code search, e.g., just the function name associated with a ResolvedFunctionCall, or the target Type text associated with a ResolvedCast.
This identifies whether SQL works in INTERNAL (inside Google) mode, or in EXTERNAL (exposed to non-Googlers in the products such as Cloud). See (broken link) for details.
Used in:
The _full_ name of the proto without the catalog name.
The index of the FileDescriptorSet in the top-level TypeProto that can be used to deserialize this particular ProtoType.
Used in:
Supported SQL resolved AST rewrites. We support these rewrites to allow syntactic improvements which generate new node types to be quickly and easily available to engines without needing each engine to implement support for the new node types.
Make sure default value of 0 is not an resolved AST rewrite.
Rewrites ResolvedFlatten nodes into equivalent array scans / subqueries.
Supports rewriting ResolvedAnonymizedAggregateScan and related. See (broken link).
Rewrites proto map functions (e.g. map[KEY(key)]) with equivalent unnest/subquery expressions. This rewrite will only occur when such functions are present in a resolved AST, which requires the V_1_3_PROTO_MAPS language feature.
Rewrites array function calls into equivalent SubqueryExpr.
Rewrites unpivot ast to equivalent scan.
Rewrites PIVOT scans. See (broken link).
Rewrites ARRAY_INCLUDES function calls into equivalent SubqueryExpr.
Rewrite typeof function. See (broken link)
Rewrite WithExpr into subquery.
Inline SQL Functions. Experimental, functionality may change before generally available. Functions that are added to the Catalog that are subtypes of SQLFunctionBase will be inlined. That removes the ResolvedFunctionCall and replaces it with an expression that evaluates the function body. Currently, not all shapes of functions are supported: * Argument references inside WITH subqueries will result in an kUnimplemented error.
Inline SQL TVFs (Table Valued Functions). Experimental, functionality may change before generally available. Functions that are added to the Catalog that are subtypes of SQLFunctionBase will be inlined. That removes the ResolvedFunctionCall and replaces it with an expression that evaluates the function body. Currently, not all shapes of functions and function calls are supported: * Argument references inside WITH subqueries will result in an kUnimplemented error. * Correlated subqueries cannot be used as arguments to TABLE parameters.
Rewrite NULLIFERROR(expr) into IFERROR(expr, NULL) See (broken link)
Rewrite unary functions into subqueries. The functions that use unary rewriter have single input.
Rewrite LIKE ANY/SOME/ALL functions with pattern lists represented as (pattern1, ...), UNNEST(<array-expression>), or a subquery See (broken link)
Rewrite ternary functions into subqueries. The functions that use ternary rewriter have three inputs.
Rewrite binary functions into subqueries. The functions that use binary rewriter have two inputs.
Inline SQL Views. Experimental. Functionality may change before generally available. Views that are added to the Catalog that are subtypes of SQLView will be inlined if SQLView::enable_view_inline returns true. That removes the ResolvedTableScan and replaces it with an expression that evaluates the view body, much as if the view was written inline.
Whether the rewrite is enabled by default or not.
Indicates whether a rewrite is still undergoing development. Users should not enable rewrites that are still in development for production code, and should check with SQL-team@ before using in experimental code.
Represents an immutable simple value. SimpleValue is a light weight version of value class. It can be used in the type library to avoid circular dependency of directly using value class in the type library.
Used in:
Set when SimpleValue::type_ is TYPE_INT64.
Set when SimpleValue::type_ is TYPE_STRING.
Set when SimpleValue::type_ is TYPE_BOOL.
Set when SimpleValue::type_ is TYPE_DOUBLE.
Set when SimpleValue::type_ is TYPE_BYTES.
User code that switches on this oneof enum must have a default case so builds won't break when new fields are added.
This identifies whether statements are resolved in module context (i.e., as a statement contained in a module), or in normal/default context (outside of a module). See (broken link) for details about module context.
Used in:
Used in:
NEXT_ID: 31
Used in:
User code that switches on this enum must have a default case so builds won't break if new enums get added.
This can be used by consumers to record an unknown type. This is not used internally by SQL. Most functions that take TypeKind will fail on TYPE_UNKNOWN.
TIME and DATETIME is controlled by FEATURE_V_1_2_CIVIL_TIME
GEOGRAPHY is controlled by FEATURE_GEOGRAPHY
NUMERIC is controlled by FEATURE_NUMERIC_TYPE
BIGNUMERIC is controlled by FEATURE_BIGNUMERIC_TYPE
Extended types are controlled by FEATURE_EXTENDED_TYPES
JSON is controlled by FEATURE_JSON_TYPE
INTERVAL type is controlled by FEATURE_INTERVAL_TYPE
RANGE type is controlled by FEATURE_RANGE_TYPE
This represents the serialized form of the bigquery_ml_utils::Type.
Used in: , ,
If the type is not a simple type, then one (and only one) of these will be populated.
These <file_descriptor_set>s may (optionally) be populated only for the 'outermost' TypeProto when serializing a SQL Type, in particular when the TypeProto is created using bigquery_ml_utils::Type::SerializeToSelfContainedProto(). They will not be populated for nested TypeProtos. If populated, they must capture all file dependencies related to the type and all of its descendants, in order be used for deserializing back to the SQL Type. If they are not populated, then deserialization can still be done if the relevant FileDescriptorSets are provided to deserialization independent of this proto. One FileDescriptorSet is created for every distinct DescriptorPool from which an enum or proto type contained within this type originates. For example, serializing a struct with two proto fields from different DescriptorPools would result in two FileDescriptorSets.
Full name of an extended type. Extended types can either use this field to encode their name and/or use their own proto extensions. It's up to the ExtendedTypeDeserializer implementation to look at the name and what extensions are present to figure out what ExtendedType to create.