> On 8 Feb 2023, at 16:57, Tom Lane wrote:
> I do not think this proposal is going anywhere as-written.
Reading this thread, it seems there is concensus against this proposal in its
current form, and no updated patch has been presented, so I will mark this as
Returned with Feedback. Please feel
I wrote:
> This approach does have a couple of shortcomings:
> * You still have to invent an operator name, even if you never
> plan to use it in queries. This is just cosmetic though.
> It's not going to matter if the operator name is long or looks like
> line noise, if you only need to use it a
Peter Eisentraut writes:
> On 12.01.23 14:55, Matthias van de Meent wrote:
>>> Matter of taste, I guess. But more importantly, defining an operator
>>> gives you many additional features that the planner can use to
>>> optimize your query differently, which it can't do with functions. See
>>> the
On 27.01.23 16:34, Matthias van de Meent wrote:
On Fri, 27 Jan 2023 at 16:26, Peter Eisentraut
wrote:
On 12.01.23 14:55, Matthias van de Meent wrote:
Matter of taste, I guess. But more importantly, defining an operator
gives you many additional features that the planner can use to
optimize yo
On Fri, 27 Jan 2023 at 16:26, Peter Eisentraut
wrote:
>
> On 12.01.23 14:55, Matthias van de Meent wrote:
> >> Matter of taste, I guess. But more importantly, defining an operator
> >> gives you many additional features that the planner can use to
> >> optimize your query differently, which it can
On 12.01.23 14:55, Matthias van de Meent wrote:
Matter of taste, I guess. But more importantly, defining an operator
gives you many additional features that the planner can use to
optimize your query differently, which it can't do with functions. See
the COMMUTATOR, HASHES, etc. clause in the CRE
On Fri, Jan 20, 2023 at 9:32 AM Ted Yu wrote:
>
> Since `validIdentifier` doesn't modify the contents of `name` string, it
> seems that there is no need to create `tmp` string in `validNamedOperator`.
> You can pass the start and end offsets into the string (name) as second and
> third parameter
On Fri, Jan 20, 2023 at 9:17 AM Gurjeet Singh wrote:
> On Sat, Jan 14, 2023 at 6:14 AM Gurjeet Singh wrote:
> >
> > I agree that an identifier _surrounded_ by the same token (e.g. #foo#)
> > or the pairing token (e.g. {foo}) looks better aesthetically, so I am
> > okay with any of the following
On Sat, Jan 14, 2023 at 6:14 AM Gurjeet Singh wrote:
>
> I agree that an identifier _surrounded_ by the same token (e.g. #foo#)
> or the pairing token (e.g. {foo}) looks better aesthetically, so I am
> okay with any of the following variations of the scheme, as well:
>
> \#foo\# (tested; works)
>
On Thu, Jan 12, 2023 at 5:55 AM Matthias van de Meent
wrote:
> On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh wrote:
> > ... defining an operator
> > gives you many additional features that the planner can use to
> > optimize your query differently, which it can't do with functions. See
> > the COMM
On Thu, Jan 12, 2023 at 10:14 AM Tom Lane wrote:
> Isaac Morland writes:
> > What about backticks (`)? They are allowed as operator characters but do
> > not otherwise appear in the lexical syntax as far as I can tell:
> > https://www.postgresql.org/docs/current/sql-syntax-lexical.html
>
> Since
On 1/12/23 18:14, Tom Lane wrote:
Pretty much the only available syntax space is curly braces,
and I don't really want to give those up for this either.
(One has to assume that the SQL committee has their eyes
on those too.)
They are used in row pattern recognition.
--
Vik Fearing
Isaac Morland writes:
> What about backticks (`)? They are allowed as operator characters but do
> not otherwise appear in the lexical syntax as far as I can tell:
> https://www.postgresql.org/docs/current/sql-syntax-lexical.html
Since they're already allowed as operator characters, you can't
use
On Thu, 12 Jan 2023 at 05:59, Gurjeet Singh wrote:
I'll consider using one of the other special characters. Do you have
> any suggestions?
>
What about backticks (`)? They are allowed as operator characters but do
not otherwise appear in the lexical syntax as far as I can tell:
https://www.postg
On Thu, Jan 12, 2023 at 3:59 AM Gurjeet Singh wrote:
> On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
> wrote:
>
> > I'm -1 on the chosen syntax; :name: shadows common variable
> > substitution patterns including those of psql.
>
> I'll consider using one of the other special characters.
Matthias van de Meent writes:
> I'm -1 on the chosen syntax; :name: shadows common variable
> substitution patterns including those of psql.
Yeah, this syntax is DOA because of that. I think almost
anything you might invent is going to have conflict risks.
We could probably make it work by allo
On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh wrote:
>
> On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
> wrote:
> >
> > On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> > >
> > > Technically correct name of this feature would be Readable Names for
> > > Operators, or Pronounceable Name
On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
wrote:
>
> On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> >
> > Technically correct name of this feature would be Readable Names for
> > Operators, or Pronounceable Names for Operators. But I'd like to call
> > it Named Operators.
> >
>
On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
>
> Technically correct name of this feature would be Readable Names for
> Operators, or Pronounceable Names for Operators. But I'd like to call
> it Named Operators.
>
> With this patch in place, the users can name the operators as
> :some_pronou
Please see attached a slightly updated patch. There were some comment
changes sitting in uncommitted in Git worktree, that were missed.
Best regards,
Gurjeet
http://Gurje.et
named_operators_v1.patch
Description: Binary data
20 matches
Mail list logo
