Type change for columns that do not exist in the schema

[3ru]

What kind of change does this PR introduce?

The type for columns that do not exist in the schema, which used to be ? to null.

What is the current behavior?

Currently, given a column that does not exist, the property can still be specified.

What is the new behavior?

If a non-existent column is given, the user cannot specify a non-existent column in order to return null.

This makes it easier to recognize column name problems from why they are null or from errors.

Additional context

It may be that this should return an error type similar to ParserError , GenericStringError, etc., but I think that would greatly expand the area to be modified.

[soedirgo]

Thanks for the PR! I've updated it so it throws an error which shows the missing column. Let me know if that looks good and I'll merge this.

[3ru]

@soedirgo
Beautiful🙌
Thank you and merging is fine!

[github-actions]

🎉 This PR is included in version 1.7.1 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[lopezjurip]

It broke custom calculated columns using psql functions

Here is an example:

create table profiles (
  id uuid not null primary key default uuid_generate_v4(),
  user_id uuid unique references auth.users (id) on delete cascade not null,
);

create or replace function _email(this profiles)
  returns text strict stable
  language plpgsql
  as $$
    begin
      return (select users.email from auth.users as users where users.id = this.user_id and users.id = auth.uid() limit 1);
    end;
  $$;

const { data } = await supabase.from("profiles").select("id, email: _email");
// data type is: SelectQueryError<"Referencing missing column `_email`">

Previous version just declared email as unknown and I could overwrite that later.