You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PostgresSQL has a fairly readable and precise hint if any invalid parameter is used during sql udf's definition time, as shown below.
create function better_hint(INT, a INT, INT) returns varchar language sql as $$select $1 + aa + $3$$;
ERROR: column "aa" does not exist
LINE 1: ...NT) returns varchar language sql as $$select $1 + aa + $3$$;
^
Our current sql udf implementation does have some hint on the missing item, but the overall error message looks large and heavy, which is also not readable and precise as postgres's, as follows.
create function better_hint(INT, a INT, INT) returns varchar language sql as $$select $1 + aa + $3$$;
ERROR: Failed to run the query
Caused by:
Invalid input syntax: failed to conduct semantic check, please see if you are calling non-existence functions: Failed to bind expression: $1 + aa + $3: Item not found: Invalid column: aa
Thus, it's better that we could have a better hint display especially when an error happens during sql udf's definition time, to help users better understand what's happening under the hood.
The text was updated successfully, but these errors were encountered:
PostgresSQL has a fairly readable and precise hint if any invalid parameter is used during sql udf's definition time, as shown below.
Our current sql udf implementation does have some hint on the missing item, but the overall error message looks large and heavy, which is also not readable and precise as postgres's, as follows.
Thus, it's better that we could have a better hint display especially when an error happens during sql udf's definition time, to help users better understand what's happening under the hood.
The text was updated successfully, but these errors were encountered: