Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chore: Clarify where table functions run #2165

Closed
scsmithr opened this issue Nov 24, 2023 · 2 comments · Fixed by #2288
Closed

Chore: Clarify where table functions run #2165

scsmithr opened this issue Nov 24, 2023 · 2 comments · Fixed by #2288
Assignees
Labels
chore DX, infra etc that's not build or CI related

Comments

@scsmithr
Copy link
Member

Description

I'm currently running through adding some table funcs, and I'm unsure what gets run where.

The full interface:

#[async_trait]
pub trait TableFunc: Sync + Send {
    /// The name for this table function. This name will be used when looking up
    /// function implementations.
    fn name(&self) -> &str;
    fn runtime_preference(&self) -> RuntimePreference;
    fn detect_runtime(
        &self,
        _args: &[FuncParamValue],
        _parent: RuntimePreference,
    ) -> Result<RuntimePreference> {
        Ok(self.runtime_preference())
    }

    /// Return a table provider using the provided args.
    async fn create_provider(
        &self,
        ctx: &dyn TableFuncContextProvider,
        args: Vec<FuncParamValue>,
        opts: HashMap<String, FuncParamValue>,
    ) -> Result<Arc<dyn TableProvider>>;
    /// Return the signature for this function.
    /// Defaults to None.
    // TODO: Remove the default impl once we have `signature` implemented for all functions
    fn signature(&self) -> Option<Signature> {
        None
    }
}

From what I'm reading, create_provider always gets run remotely if runtime preference is remote. If this is the case, then that should be documented.

@scsmithr scsmithr added the chore DX, infra etc that's not build or CI related label Nov 24, 2023
@scsmithr
Copy link
Member Author

Also not sure what detect_runtime is for.

@vrongmeal
Copy link
Contributor

Taking a look at this. Will document/refactor as required.

@vrongmeal vrongmeal self-assigned this Dec 21, 2023
vrongmeal added a commit that referenced this issue Dec 22, 2023
We should only have 1 source of truth for runtime preference for the
functions. Here, `runtime_preference` method is removed so the runtime
is always calculated from `detect_runtime`.

Fixes #2165

Signed-off-by: Vaibhav <vrongmeal@gmail.com>
vrongmeal added a commit that referenced this issue Dec 27, 2023
We should only have 1 source of truth for runtime preference for the
functions. Here, `runtime_preference` method is removed so the runtime
is always calculated from `detect_runtime`.

Fixes #2165

---------

Signed-off-by: Vaibhav <vrongmeal@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore DX, infra etc that's not build or CI related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants