Re: psql: add \create_function command
| От | Steve Chavez |
|---|---|
| Тема | Re: psql: add \create_function command |
| Дата | |
| Msg-id | CAGRrpzaKtU4PDnZ3ZwKP3ygMex-j=tS3xeR4ggcMCeA2n2R25A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: psql: add \create_function command (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: psql: add \create_function command
|
| Список | pgsql-hackers |
> 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 confusing to use the same syntax.
How about using the convention of interpreting an identifier as a file path if it has an slash on it?
This is used in the Nix language and from experience it works very well: https://nix.dev/manual/nix/2.18/language/values#type-path
It also makes it very clear that you're using a file path, e.g. :{filename} vs :./filename. Examples:
select jsonb_to_recordset(:./contents.json);
create function foo() returns text AS :/absolute/path/contents.py language plpython3u;
Any thoughts?
Best regards,
Steve Chavez
On Mon, 29 Jan 2024 at 08:42, Andrew Dunstan <andrew@dunslane.net> wrote:
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
В списке pgsql-hackers по дате отправления: