> 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
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
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
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
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
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
y with any of the following variations of the scheme, as well:
> >
> > \#foo\# (tested; works)
> > \#foo# (not tested; reduces ident length by 1)
> >
> > We can choose a different character, instead of #. Perhaps \{foo} !
>
> Please find attached the p
\# (tested; works)
> \#foo# (not tested; reduces ident length by 1)
>
> We can choose a different character, instead of #. Perhaps \{foo} !
Please find attached the patch that uses \{foo} styled Named
Operators. This is in line with Tom's reluctant hint at possibly using
curly braces as
e Row Pattern Recognition feature!)
Considering that there are almost no printable characters left in
1-255 ASCII range for us to choose from, I had to get creative; and I
believe I have found a way to make it work.
Unless the SQL committee has their eyes on a freestanding backslash \
character f
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
>
>
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
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:
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
s 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_pronounceable_name: instead of having to choose from t
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 cal
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
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
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_pronounceable_name: instead of having to choose from the special
21 matches
Mail list logo
