Re: psql: add \create_function command

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Chavez <steve(at)supabase(dot)io>, Andrew Dunstan <andrew(at)dunslane(dot)net>, walther(at)technowledgy(dot)de, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: add \create_function command
Date: 2024-01-29 17:29:12
Message-ID: CAFj8pRDrg2a=2vRDn=gaWENUHZxubK_mP8MPX6twHR=6NdYPMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 29. 1. 2024 v 18:11 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Steve Chavez <steve(at)supabase(dot)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.
>

sometimes paths starts by $ or .

or maybe :{{ ... }}

>
> regards, tom lane
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-01-29 17:37:37 meson + libpq_pipeline
Previous Message Alvaro Herrera 2024-01-29 17:13:35 Re: Report planning memory in EXPLAIN ANALYZE