Skip to content
Closed
93 changes: 93 additions & 0 deletions extensions/functions_table.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
%YAML 1.2
---
# Table functions: Functions that produce relations (zero or more records).
urn: extension:io.substrait:functions_table
table_functions:
- name: "generate_series"
description: >-
Generates a series of integer values from start to stop, incrementing by step.

Produces zero or more records containing a single integer value. The series
includes both the start and stop values if they fall on a step boundary.
If step is positive, stops when the value exceeds stop. If step is negative,
stops when the value is less than stop. Returns empty if step is zero or if
the step direction doesn't allow reaching stop from start.
impls:
- args:
- name: start
value: i64
description: The starting value of the series
- name: stop
value: i64
description: The ending value of the series (inclusive)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there is an interesting spilit between stop being inclusive and exclusive.

  • python, pandas and snowflake exclude the stop value.
  • PostgreSQL, T-SQL, ZetaSQL include the stop value.

I guess either way is fine... Another problem is that some systems do support generating series for other numeric types (e.g., fp32, fp64, decimal) but we can add those later.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add this as a function option which specifies if they include or exclude the stop value. What do others think?

- name: step
value: i64
description: The increment between values
return:
names:
- value
struct:
types:
- i64
- args:
- name: start
value: i32
description: The starting value of the series
- name: stop
value: i32
description: The ending value of the series (inclusive)
- name: step
value: i32
description: The increment between values
return:
names:
- value
struct:
types:
- i32
- args:
- name: start
value: i64
description: The starting value of the series
- name: stop
value: i64
description: The ending value of the series (inclusive)
return:
names:
- value
struct:
types:
- i64
- args:
- name: start
value: i32
description: The starting value of the series
- name: stop
value: i32
description: The ending value of the series (inclusive)
return:
names:
- value
struct:
types:
- i32
- name: "unnest"
description: >-
Expands one or more list expressions into a set of rows.

When multiple lists are provided, produces rows by expanding the lists in parallel (like a zip operation).
For example, unnest([1,2], [3,4]) produces rows: (1,3), (2,4).
If lists have different lengths, shorter lists are padded with nulls.
impls:
- args:
- name: input
value: list<any1>
description: The list(s) to unnest
variadic:
min: 1
return:

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have made this a draft PR again. I need to have a proper think about how we can represent this dynamic return type if we really want to have these functions be variadic 😰

names:
- element
struct:
types:
- any1
40 changes: 40 additions & 0 deletions proto/substrait/algebra.proto
Original file line number Diff line number Diff line change
Expand Up @@ -552,6 +552,45 @@ message ExpandRel {
}
}

// Invokes a table-valued function that produces a relation (zero or more records).
//
//
// Table functions produce a table with a schema that can be:
// - Statically defined (concrete types in YAML)
// - Type-parameterized (derived from argument types, e.g., unnest(list<T>) -> {element: T})
//
// Future extensions may add an optional input field to support transformation
// table functions that operate on input relations.
message TableFunctionRel {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is a more appropriate name for this GeneratorTableFunctionRel as introduced by
@jacques-n here?

In my mind there are two possible paths we can go down which determine the appropriate name.

  1. We could explore expanding this proto (by e.g. adding a relations input field) so that it appropriately models both kinds of table functions. In this case, keeping the name as TableFunctionRel makes sense.
  2. We could introduce a brand new relation to represent table functions which take relations as input. In this case, it would make sense to rename this relation to GeneratorTableRel or some name which distinguishes it from the other kind of table function.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my biased view, it is better to categorize them... roughly

  • Scan like (0 relational input)
  • Project or Filter like (1 relational input)
  • (N-ary) Join like (2+ relational inputs optional grouping support)
  • Group like (1 relational input with grouping support)

This gives way more modular and systematic way to describe a table function.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your suggestion to have a different relation for each one of those? Or one shared relation? Maybe something like the following would be preferable...

message TableFunctionRel {
  ...
  oneof {
    ScanLike scan_like = 1; // PR implements this one
    //ProjectLike project_like = 2;
    //JoinLike join_like = 3;
    //GroupLike group_like = 4;
  }
  // implementations below
  ...
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer Rel for each type, clearly expressing the degree of input at message level. But I'm open to exploring oneof definition.

RelCommon common = 1;

// Points to a function_anchor defined in this plan, which must refer
// to a table function in the associated YAML file. Avoid using
// anchor/reference zero.
uint32 function_reference = 2;

// The arguments to be bound to the function. This must have exactly the
// number of arguments specified in the function definition from the YAML file,
// and the argument types must also match exactly:
// - Value arguments must be bound using FunctionArgument.value.
// - Type arguments must be bound using FunctionArgument.type.
// - Enum arguments must be bound using FunctionArgument.enum with a
// string that case-insensitively matches one of the allowed options.
repeated FunctionArgument arguments = 3;

// Options to specify behavior for corner cases, or leave behavior
// unspecified if the consumer does not need specific behavior in these
// cases.
repeated FunctionOption options = 5;

// The concrete output schema of the relation. For schemas which can be derived
// from their YAML specification this must match the schema computed by evaluating the
// YAML ExpressionNamedStruct with the bound argument types.
NamedStruct table_schema = 6;

substrait.extensions.AdvancedExtension advanced_extension = 7;
}

// A relation with output field names.
//
// This is for use at the root of a `Rel` tree.
Expand Down Expand Up @@ -581,6 +620,7 @@ message Rel {
WriteRel write = 19;
DdlRel ddl = 20;
UpdateRel update = 22;
TableFunctionRel table_function = 23;
// Physical relations
HashJoinRel hash_join = 13;
MergeJoinRel merge_join = 14;
Expand Down
20 changes: 20 additions & 0 deletions proto/substrait/function.proto
Original file line number Diff line number Diff line change
Expand Up @@ -106,6 +106,26 @@ message FunctionSignature {
}
}

message Table {
repeated Argument arguments = 2;
repeated string name = 3;
Description description = 4;

// The schema expression that defines the output relation structure.
// This must be an ExpressionNamedStruct since table functions always
// produce relations with named fields. The struct can be:
// - Static (concrete field types)
// - Type-parameterized (field types derived from argument types)
DerivationExpression.ExpressionNamedStruct schema = 5;

oneof final_variable_behavior {
FinalArgVariadic variadic = 6;
FinalArgNormal normal = 7;
}

repeated Implementation implementations = 8;
}

message Description {
string language = 1;
string body = 2;
Expand Down
Loading
Loading