Thread: psql: add \create_function command

Pavel Stehule <pavel.stehule@gmail.com> writes:
> pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez <steve@supabase.io> napsal:
>> To solve the above issue, this patch adds a psql command to create a
>> function and obtain its body from another file. It is used as:
>> \create_function from ./data/max.py max(int,int) returns int LANGUAGE
>> plpython3u

> looks a little bit obscure - why do you need to do it from psql? And how
> frequently do you do it?
> I think so this is fix on wrong place - you should to fix linters, not psql
> - more without header you cannot do correct linting

It feels wrong to me too.  I'm not sure where is a better place to
implement something like this though.  We can't support it server-side
because of permissions issues, so if there's to be any merging of
files it has to happen on the client side.

It strikes me though that thinking about this in terms of CREATE
FUNCTION is thinking too small.  ISTM that the requirement of
"grab the content of a file, quote it as a string literal, and
embed it into a SQL command" exists elsewhere.  For one thing
there's CREATE PROCEDURE, but I've needed this occasionally
just as a way of feeding data into SELECT, INSERT, etc.

Now, you can do it today:

\set fbody `cat source_file.txt`
CREATE FUNCTION foo() RETURNS whatever AS :'fbody' LANGUAGE ...;

and maybe we should say that that's sufficient.  It's a bit
klugy though.  One level of improvement could be to get rid
of the dependency on "cat" by inventing a backslash command
to read a file into a variable:

\file_read fbody source_file.txt
CREATE FUNCTION foo() RETURNS whatever AS :'fbody' LANGUAGE ...;

(\file_write to go the other way seems potentially useful too.)

Or we could cut out the intermediate variable altogether
by inventing something that works like :'...' but reads
from a file not a variable.  That might be too specialized
though, and I'm not sure about good syntax for it either.
Maybe like

CREATE FUNCTION foo() RETURNS whatever AS :{source_file.txt} LANGUAGE ...;

            regards, tom lane

Tom Lane:
> Or we could cut out the intermediate variable altogether
> by inventing something that works like :'...' but reads
> from a file not a variable.  That might be too specialized
> though, and I'm not sure about good syntax for it either.
> Maybe like
> 
> CREATE FUNCTION foo() RETURNS whatever AS :{source_file.txt} LANGUAGE ...;

That would indeed be very useful! I would immediately use this in a lot 
of places.

Pavel Stehule:
> looks a little bit obscure - why do you need to do it from psql? And how 
> frequently do you do it?

I store all my SQL code in git and use "psql -e" to "bundle" it into an 
extension, which is then deployed to production.

The code is spread over many files, which include other files via \ir. 
Sometimes you need to include other types of files, though - for example 
code in other languages as Steve mentioned, but I have also had cases 
for yaml files, markdown templates, even binary assets which should 
still be considered "code" and not data.

So anything in that direction would help.

walther@technowledgy.de writes:
> Pavel Stehule:
>> looks a little bit obscure - why do you need to do it from psql? And how 
>> frequently do you do it?

> I store all my SQL code in git and use "psql -e" to "bundle" it into an 
> extension, which is then deployed to production.

> The code is spread over many files, which include other files via \ir. 

That reminds me: if we do either \file_read or :{file}, we should
define relative paths as working like \ir, that is it's relative
to the current script's directory when we're reading from a script.
This is almost always the behavior you want, and the principal
functional problem with the `cat ...` solution is that it doesn't
work that way.

            regards, tom lane

Pavel Stehule <pavel.stehule@gmail.com> writes:
> but why you need to do in psql? - you can prepare content outside and
> execute just like echo "CREATE FUNCTION ...." | psql

The bit that's probably hard if you're trying to do this in a shell
script is "quote this data as a SQL string literal".  psql can get
that right even in the face of encoding considerations,
standard_conforming_strings, etc.  Not sure you can build a
fully bulletproof solution outside.

            regards, tom lane

Pavel Stehule <pavel.stehule@gmail.com> writes:
> I don't know, maybe I have a problem with the described use case. I cannot
> imagine holding the body and head of PL routines in different places and I
> don't understand the necessity to join it.

It seems a little weird to me too, and I would vote against accepting
\create_function as described because I think too few people would
want to use it.  However, the idea of an easy way to pull in a file
and convert it to a SQL literal seems like it has many applications.

            regards, tom lane

On 2024-01-26 Fr 15:17, Tom Lane wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> I don't know, maybe I have a problem with the described use case. I cannot
>> imagine holding the body and head of PL routines in different places and I
>> don't understand the necessity to join it.
> It seems a little weird to me too, and I would vote against accepting
> \create_function as described because I think too few people would
> want to use it.  However, the idea of an easy way to pull in a file
> and convert it to a SQL literal seems like it has many applications.
>
>             


Yes, this proposal is far too narrow and would not cater for many use 
cases I have had in the past.

I like your ideas upthread about \file_read and :{filename}


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Steve Chavez <steve@supabase.io> writes:
> However, :{?variable_name} is already taken by psql to test whether a
> variable is defined or not. It might be confusing to use the same syntax.

Hmm.  Maybe we could go with :{+...} or the like?

> How about using the convention of interpreting an identifier as a file path
> if it has an slash on it?

Sorry, that is just horrid.  foo/bar means division, and "foo/bar"
is simply an identifier per SQL standard, so you can't squeeze that
in without breaking an ocean of stuff.  Plus, there are many use-cases
where there's no reason to put a slash in a relative filename.

            regards, tom lane