Hi
pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez napsal:
> Hello hackers,
>
> Currently a function definition must include its body inline. Because of
> this, when storing function definitions in files, linters and syntax
> highlighters for non-SQL languages (python, perl, tcl, etc) won't work.
Pavel Stehule writes:
> pá 26. 1. 2024 v 19:41 odesílatel Steve Chavez 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
>> plpy
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 :{s
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 fi
On Fri, Jan 26, 2024 at 12:23 PM Tom Lane wrote:
>
> \set fbody `cat source_file.txt`
> CREATE FUNCTION foo() RETURNS whatever AS :'fbody' LANGUAGE ...;
>
> and maybe we should say that that's sufficient.
I really don't have a problem, and kinda prefer, using psql variables this
way but feel mu
pá 26. 1. 2024 v 20:45 odesílatel napsal:
> 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.
>
th
walt...@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 spr
Pavel Stehule 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 ev
pá 26. 1. 2024 v 21:04 odesílatel Tom Lane napsal:
> Pavel Stehule 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
Pavel Stehule 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
\creat
pá 26. 1. 2024 v 21:17 odesílatel Tom Lane napsal:
> Pavel Stehule 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
idea: what about custom functions for (each) IDE, which calls psql -c
"CREATE FUNCTION ..." when the user saves the file? (it would easy to
prototype for emacs...)
(obviously, this isn't a core feature...)
On Fri, Jan 26, 2024 at 3:19 PM Pavel Stehule
wrote:
>
>
> pá 26. 1. 2024 v 21:17 odesíl
On 2024-01-26 Fr 15:17, Tom Lane wrote:
Pavel Stehule 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, an
> I like your ideas upthread about \file_read and :{filename}
Great ideas! :{filename} looks more convenient to use than \file_read just
because it's one less command to execute.
However, :{?variable_name} is already taken by psql to test whether a
variable is defined or not. It might be confusin
po 29. 1. 2024 v 17:54 odesílatel Steve Chavez napsal:
> > I like your ideas upthread about \file_read and :{filename}
>
> Great ideas! :{filename} looks more convenient to use than \file_read just
> because it's one less command to execute.
>
> However, :{?variable_name} is already taken by psql
Steve Chavez 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
po 29. 1. 2024 v 18:11 odesílatel Tom Lane napsal:
> Steve Chavez 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
> Maybe we could go with :{+...} or the like?
> or maybe :{{ ... }}
Tab completion didn't work for :{?} and I noted that the same problem
would arise for :{+ or :{{ (and tab completion would be more important
here). So I fixed that on:
https://www.postgresql.org/message-id/flat/CAGRrpzZU48F2oV3d8
18 matches
Mail list logo