On Mon, Mar 07, 2022 at 06:35:45AM +0100, Pavel Stehule wrote:
>
> this patch should be rejected. There is no consensus.
Thanks for the confirmation, I will take care of it!
Hi
po 7. 3. 2022 v 3:31 odesílatel Julien Rouhaud napsal:
> On Mon, Mar 07, 2022 at 11:27:14AM +0900, Michael Paquier wrote:
> > On Sat, Mar 05, 2022 at 07:31:53PM +0900, Michael Paquier wrote:
> > > I got a short look at what was proposed in the patch a couple of
> > > months ago, and still
On Mon, Mar 07, 2022 at 10:31:40AM +0800, Julien Rouhaud wrote:
> I was actually waiting a bit to make sure that Pavel could read the thread,
> since it was the weekend and right now it's 3:30 AM in Czech Republic...
Sorry about that. I have reset the state of the patch.
--
Michael
On Mon, Mar 07, 2022 at 11:27:14AM +0900, Michael Paquier wrote:
> On Sat, Mar 05, 2022 at 07:31:53PM +0900, Michael Paquier wrote:
> > I got a short look at what was proposed in the patch a couple of
> > months ago, and still found the implementation confusing with the way
> > aliases are
On Sat, Mar 05, 2022 at 07:31:53PM +0900, Michael Paquier wrote:
> I got a short look at what was proposed in the patch a couple of
> months ago, and still found the implementation confusing with the way
> aliases are handled, particularly when it came to several layers of
> pl/pgsql. I am fine
On Sat, Mar 05, 2022 at 04:54:18PM +0800, Julien Rouhaud wrote:
> On Thu, Jan 06, 2022 at 05:05:32PM +0800, Julien Rouhaud wrote:
>> Anyway, the only committer that showed some interest in the feature is
>> Michael,
>> and he seemed ok in principle with the "alias-implementation" approach.
>>
On Thu, Jan 06, 2022 at 05:05:32PM +0800, Julien Rouhaud wrote:
>
> Anyway, the only committer that showed some interest in the feature is
> Michael,
> and he seemed ok in principle with the "alias-implementation" approach.
> Michael, did you have a look at this version ([1]), or do you think it
On Thu, Jan 6, 2022, at 21:38, Pavel Stehule wrote:
> I say, semantically - how I understand the meaning of the word "in" is not
> good to use it for generic alias of function arguments (when we have out
> arguments too).
Trying to imagine a situation where you would need a shorthand also for
čt 6. 1. 2022 v 21:04 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 20:24, Pavel Stehule wrote:
> > But there is nothing similar in standard.
> > Standard doesn't specify any column or table or label names in the
> custom area.
>
> I think that's an unfair comparison.
> This isn't
On Thu, Jan 6, 2022, at 20:24, Pavel Stehule wrote:
> But there is nothing similar in standard.
> Standard doesn't specify any column or table or label names in the custom
> area.
I think that's an unfair comparison.
This isn't at all the same thing as dictating column or table names.
I merely
čt 6. 1. 2022 v 20:03 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 19:03, Pavel Stehule wrote:
> > The possibility to define a label dynamically is a better solution (not
> by some buildin keyword),
> > because it allows some possibility for the end user to define what he
>
On Thu, Jan 6, 2022, at 19:03, Pavel Stehule wrote:
> The possibility to define a label dynamically is a better solution (not by
> some buildin keyword),
> because it allows some possibility for the end user to define what he prefers.
I'm trying to understand why you think a user-defined
>
>
>
> I accept that both issues are valid, and I don't think we can find a good
> design that solves both issues, because there are different objective
> expectations.
>
I accept that both issues are valid, and I don't think we can find a
**one** good design that solves both issues, because
čt 6. 1. 2022 v 18:18 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 17:55, Tom Lane wrote:
> > Even if it works today, we could be letting ourselves in for future
> > trouble. The SQL standard is a moving target, and they could easily
> > standardize some future syntax involving IN
čt 6. 1. 2022 v 17:48 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 17:10, Pavel Stehule wrote:
> > I understand well, and I don't think it's nice.
> >
> > Are there some similar features in other programming languages?
>
> It would be similar to "this" in Javascript/Java/C++,
> but
On Thu, Jan 6, 2022, at 17:55, Tom Lane wrote:
> Even if it works today, we could be letting ourselves in for future
> trouble. The SQL standard is a moving target, and they could easily
> standardize some future syntax involving IN that creates a problem here.
Perhaps the "in." notation could
Pavel Stehule writes:
> čt 6. 1. 2022 v 16:59 odesílatel Joel Jacobson napsal:
>> How could the SQL parser have a problem with it, if "in" is currently
>> never followed by "." (dot)?
> you can check it. It is true, so IN is usually followed by "(", but until
> check I am not able to say if
On Thu, Jan 6, 2022, at 17:10, Pavel Stehule wrote:
> I understand well, and I don't think it's nice.
>
> Are there some similar features in other programming languages?
It would be similar to "this" in Javascript/Java/C++,
but instead using "in" to access function parameters.
Currently, we
čt 6. 1. 2022 v 16:59 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 15:05, Pavel Stehule wrote:
> >>čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson
> napsal:
> >>How about using the existing reserved keyword "in" followed by "." (dot)
> and then the function parameter name?
> >>
>
On Thu, Jan 6, 2022, at 15:05, Pavel Stehule wrote:
>>čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson napsal:
>>How about using the existing reserved keyword "in" followed by "." (dot) and
>>then the function parameter name?
>>
>>This idea is based on the assumption "in." would always be a syntax
čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson napsal:
> On Thu, Jan 6, 2022, at 10:05, Julien Rouhaud wrote:
> > I agree, but on the other hand I don't see how defining a top level block
> > alias identical for every single plpgsql function would really make
> sense.
> > Not every function has
On Thu, Jan 6, 2022, at 10:05, Julien Rouhaud wrote:
> I agree, but on the other hand I don't see how defining a top level block
> alias identical for every single plpgsql function would really make sense.
> Not every function has a very long name and would benefit from it, and no one
> can really
On Thu, Jan 06, 2022 at 08:52:23AM +0100, Pavel Stehule wrote:
>
> I am not sure if there is enough agreement and if there is enough necessity
> for this feature.
>
> In this discussion there were more general questions about future
> development of plpgsql (about possible configurations and
čt 6. 1. 2022 v 8:02 odesílatel Julien Rouhaud napsal:
> Hi Pavel,
>
> On Wed, Mar 24, 2021 at 08:09:13AM +0100, Pavel Stehule wrote:
> >
> > I am continuing to talk with Hannu about syntax. I think so using the
> > compile option is a good direction, but maybe renaming from
> "routine_label"
>
Hi Pavel,
On Wed, Mar 24, 2021 at 08:09:13AM +0100, Pavel Stehule wrote:
>
> I am continuing to talk with Hannu about syntax. I think so using the
> compile option is a good direction, but maybe renaming from "routine_label"
> to "topscope_label" (proposed by Hannu) or maybe "outerscope_label"
ne 28. 3. 2021 v 17:58 odesílatel Julien Rouhaud
napsal:
> On Sun, Mar 28, 2021 at 05:12:10PM +0200, Pavel Stehule wrote:
> >
> > Yes, this has a benefit just for plpgsql. I can imagine a little bit
> > different API of plpgsql that allows more direct calls than now. For
> example
> >
> > static
On Sun, Mar 28, 2021 at 05:12:10PM +0200, Pavel Stehule wrote:
>
> Yes, this has a benefit just for plpgsql. I can imagine a little bit
> different API of plpgsql that allows more direct calls than now. For example
>
> static PLpgSQL_function *
> do_compile(FunctionCallInfo fcinfo,
> <--><-->
ne 28. 3. 2021 v 16:04 odesílatel Julien Rouhaud
napsal:
> On Sun, Mar 28, 2021 at 03:52:35PM +0200, Joel Jacobson wrote:
> > On Sun, Mar 28, 2021, at 15:12, Pavel Stehule wrote:
> > > Maybe I don't understand your proposal well, I am sorry. Creating your
> own language should not be hard, but
On Sun, Mar 28, 2021 at 03:52:35PM +0200, Joel Jacobson wrote:
> On Sun, Mar 28, 2021, at 15:12, Pavel Stehule wrote:
> > Maybe I don't understand your proposal well, I am sorry. Creating your own
> > language should not be hard, but in this case the plpgsql is not well
> > extendable. The
On Sun, Mar 28, 2021, at 15:12, Pavel Stehule wrote:
> Maybe I don't understand your proposal well, I am sorry. Creating your own
> language should not be hard, but in this case the plpgsql is not well
> extendable. The important structures are private. You can do it, but you
> should do a full
ne 28. 3. 2021 v 14:45 odesílatel Joel Jacobson napsal:
> On Sun, Mar 28, 2021, at 14:27, Pavel Stehule wrote:
>
> ne 28. 3. 2021 v 13:49 odesílatel Joel Jacobson
> napsal:
>
> It would of course be a problem since other plpgsql extensions could be in
> conflict with such a label,
> so maybe we
On Sun, Mar 28, 2021, at 14:27, Pavel Stehule wrote:
> ne 28. 3. 2021 v 13:49 odesílatel Joel Jacobson napsal:
>> __It would of course be a problem since other plpgsql extensions could be in
>> conflict with such a label,
>> so maybe we could allow creating a new language, "plmycorp", using the
ne 28. 3. 2021 v 13:49 odesílatel Joel Jacobson napsal:
> +1
>
> I really like this feature.
>
> Is there a way to avoid having to write the "#ROUTINE_LABEL" for every
> function defined?
>
> I'm thinking if a company writing a lot of plpgsql functions want to
> decide on a company wide
+1
I really like this feature.
Is there a way to avoid having to write the "#ROUTINE_LABEL" for every function
defined?
I'm thinking if a company writing a lot of plpgsql functions want to decide on
a company wide hard-coded label to use for all their plpgsql functions. Could
it be set
st 24. 3. 2021 v 8:42 odesílatel Erik Rijkers napsal:
> > On 2021.03.24. 08:09 Pavel Stehule wrote:
> > [...]
> > [plpgsql-routine-label-20210324.patch]
>
>
> Hi,
>
> In that sgml
>
> "the functions' arguments"
>
> should be
>
> "the function's arguments"
>
fixed,
thank you for check
>
>
> On 2021.03.24. 08:09 Pavel Stehule wrote:
> [...]
> [plpgsql-routine-label-20210324.patch]
Hi,
In that sgml
"the functions' arguments"
should be
"the function's arguments"
Erik
st 17. 3. 2021 v 23:32 odesílatel Michael Paquier
napsal:
> On Wed, Mar 17, 2021 at 05:04:48PM +0100, Pavel Stehule wrote:
> > This tree has a different direction than is usual, and then replacing the
> > root node is not simple.
>
> Yeah, it is not like we should redesign this whole part just
pá 19. 3. 2021 v 14:14 odesílatel Hannu Krosing napsal:
> On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule
> wrote:
>
> > But we don't support this feature. We are changing just a top scope's
> label. So syntax "ALIAS FOR FUNCTION is not good. The user can have false
> hopes
>
> In this case it
On Thu, Mar 18, 2021 at 4:23 PM Pavel Stehule wrote:
> But we don't support this feature. We are changing just a top scope's label.
> So syntax "ALIAS FOR FUNCTION is not good. The user can have false hopes
In this case it looks like it should go together with other labels and
have <<
čt 18. 3. 2021 v 15:59 odesílatel Hannu Krosing napsal:
> On Thu, Mar 18, 2021 at 3:45 PM Pavel Stehule
> wrote:
> >
> >
> >
> > čt 18. 3. 2021 v 15:19 odesílatel Hannu Krosing
> napsal:
> ...
> >> Variation could be
> >>
> >> DECLARE
> >>fnarg ALIAS FOR FUNCTION
čt 18. 3. 2021 v 15:49 odesílatel Hannu Krosing napsal:
> I went to archives and read the whole discussion for this from the
> beginning
>
> I did not really understand, why using the ALIAS FOR syntax is
> significantly
> harder to implement then #routine_label
>
just because it can be used in
On Thu, Mar 18, 2021 at 3:45 PM Pavel Stehule wrote:
>
>
>
> čt 18. 3. 2021 v 15:19 odesílatel Hannu Krosing napsal:
...
>> Variation could be
>>
>> DECLARE
>>fnarg ALIAS FOR FUNCTION a_function_with_an_inconveniently_long_name;
>>
>> so it is clear that we are aliasing current function name
I went to archives and read the whole discussion for this from the beginning
I did not really understand, why using the ALIAS FOR syntax is significantly
harder to implement then #routine_label
The things you mentioned as currently using #OPTION seem to be in a different
category from the
čt 18. 3. 2021 v 15:19 odesílatel Hannu Krosing napsal:
> On Thu, Mar 18, 2021 at 5:27 AM Pavel Stehule
> wrote:
> >
> >
> > There are few main reasons:
> >
> > a) compile options are available already - so I don't need invent new
> syntax - #OPTION DUMP, #PRINT_STRICT ON, #VARIABLE_CONFLICT
On Thu, Mar 18, 2021 at 5:27 AM Pavel Stehule wrote:
>
>
> There are few main reasons:
>
> a) compile options are available already - so I don't need invent new syntax
> - #OPTION DUMP, #PRINT_STRICT ON, #VARIABLE_CONFLICT ERROR
Are these documented anywhere ?
At least a quick search for
st 17. 3. 2021 v 23:16 odesílatel Hannu Krosing napsal:
> why are you using yet another special syntax for this ?
>
> would it not be better to do something like this:
> CREATE FUNCTION a_reall_long_and_winding_function_name(i int, out o int)
> LANGUAGE plpgsql AS $plpgsql$
> DECLARE
>args
st 17. 3. 2021 v 23:32 odesílatel Michael Paquier
napsal:
> On Wed, Mar 17, 2021 at 05:04:48PM +0100, Pavel Stehule wrote:
> > This tree has a different direction than is usual, and then replacing the
> > root node is not simple.
>
> Yeah, it is not like we should redesign this whole part just
On Wed, Mar 17, 2021 at 05:04:48PM +0100, Pavel Stehule wrote:
> This tree has a different direction than is usual, and then replacing the
> root node is not simple.
Yeah, it is not like we should redesign this whole part just for the
feature discussed here, and that may impact performance as the
why are you using yet another special syntax for this ?
would it not be better to do something like this:
CREATE FUNCTION a_reall_long_and_winding_function_name(i int, out o int)
LANGUAGE plpgsql AS $plpgsql$
DECLARE
args function_name_alias
BEGIN
args.o = 2 * args.i
END;
$plpgsql$;
or at
st 17. 3. 2021 v 9:20 odesílatel Michael Paquier
napsal:
> On Wed, Mar 17, 2021 at 02:06:57PM +0800, Julien Rouhaud wrote:
> > I also think that there should be a single usable top label, otherwise
> it will
> > lead to confusing code and it can be a source of bug.
>
> Okay, that's fine by me.
On Wed, Mar 17, 2021 at 02:06:57PM +0800, Julien Rouhaud wrote:
> I also think that there should be a single usable top label, otherwise it will
> lead to confusing code and it can be a source of bug.
Okay, that's fine by me. Could it be possible to come up with an
approach that does not hijack
On Wed, Mar 17, 2021 at 05:30:30AM +0100, Pavel Stehule wrote:
> st 17. 3. 2021 v 4:52 odesílatel Michael Paquier
>
> > I am wondering whether it would be better to allow multiple aliases
> > though, and if it would bring more readability to the routines written
> > if these are treated equal to
st 17. 3. 2021 v 4:52 odesílatel Michael Paquier
napsal:
> On Mon, Mar 15, 2021 at 05:31:18AM +0100, Pavel Stehule wrote:
> > Thank you very much
>
> I am not much a fan of the implementation done here. Based on my
> understanding of the PL code, the namespace lookup is organized as a
> list of
On Mon, Mar 15, 2021 at 05:31:18AM +0100, Pavel Stehule wrote:
> Thank you very much
I am not much a fan of the implementation done here. Based on my
understanding of the PL code, the namespace lookup is organized as a
list of items, with the namespace associated to the routine name being
the
po 15. 3. 2021 v 4:54 odesílatel Julien Rouhaud napsal:
> On Sun, Mar 14, 2021 at 08:41:15PM +0100, Pavel Stehule wrote:
> >
> > My English is good enough for taking beer everywhere in the world :) . Ti
> > is not good, but a lot of people who don't understand to English
> understand
> > my
On Sun, Mar 14, 2021 at 08:41:15PM +0100, Pavel Stehule wrote:
>
> My English is good enough for taking beer everywhere in the world :) . Ti
> is not good, but a lot of people who don't understand to English understand
> my simplified fork of English language.
I have the same problem. We can
Hi
so 13. 3. 2021 v 12:48 odesílatel Julien Rouhaud
napsal:
> On Sat, Mar 13, 2021 at 12:10:29PM +0100, Pavel Stehule wrote:
> >
> > so 13. 3. 2021 v 9:53 odesílatel Julien Rouhaud
> napsal:
> > >
> > > I don't think that it makes sense to have multiple occurences of this
> > > command,
> > >
On Sat, Mar 13, 2021 at 12:10:29PM +0100, Pavel Stehule wrote:
>
> so 13. 3. 2021 v 9:53 odesílatel Julien Rouhaud napsal:
> >
> > I don't think that it makes sense to have multiple occurences of this
> > command,
> > and we should simply error out if plpgsql_curr_compile->root_ns->itemno is
> >
Hi
so 13. 3. 2021 v 9:53 odesílatel Julien Rouhaud napsal:
> I think that this can be a useful feature in many occasions, especially
> since
> the overhead is almost inexistent.
>
> The implementation is sensible and there are regression tests to cover the
> new
> feature.
>
> There's a problem
I think that this can be a useful feature in many occasions, especially since
the overhead is almost inexistent.
The implementation is sensible and there are regression tests to cover the new
feature.
There's a problem however if you try to add multiple #routine_label commands in
the same
Hi
fix broken regress test
Regards
Pavel
diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
index 5336793a93..585959e12f 100644
--- a/src/pl/plpgsql/src/pl_comp.c
+++ b/src/pl/plpgsql/src/pl_comp.c
@@ -377,6 +377,10 @@ do_compile(FunctionCallInfo fcinfo,
*/
Hi
this is less invasive, and probably more correct work with ns items patch.
čt 19. 11. 2020 v 1:54 odesílatel Vik Fearing
napsal:
> On 11/18/20 9:21 PM, Pavel Stehule wrote:
> > postgres=# create or replace function bubu(a int, b int)
> > returns void as $$
> > #routine_label b
> > begin
> >
On 11/18/20 9:21 PM, Pavel Stehule wrote:
> postgres=# create or replace function bubu(a int, b int)
> returns void as $$
> #routine_label b
> begin
> raise notice '% %', b.a, b.b;
> end;
> $$ language plpgsql;
Why not use the block labeling syntax we already have?
create or replace function
st 18. 11. 2020 v 21:21 odesílatel Pavel Stehule
napsal:
>
>
> st 18. 11. 2020 v 6:58 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> út 17. 11. 2020 v 21:45 odesílatel Chapman Flack
>> napsal:
>>
>>> On 11/17/20 15:18, Jack Christensen wrote:
>>> >> CREATE OR REPLACE FUNCTION
st 18. 11. 2020 v 6:58 odesílatel Pavel Stehule
napsal:
>
>
> út 17. 11. 2020 v 21:45 odesílatel Chapman Flack
> napsal:
>
>> On 11/17/20 15:18, Jack Christensen wrote:
>> >> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
>> >> RETURNS int AS $$
>> >> #routine_label lnm
>> >> BEGIN
>> >>
út 17. 11. 2020 v 21:45 odesílatel Chapman Flack
napsal:
> On 11/17/20 15:18, Jack Christensen wrote:
> >> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
> >> RETURNS int AS $$
> >> #routine_label lnm
> >> BEGIN
> >> RAISE NOTICE '%', lnm.par1;
>
> Could that be somehow shoehorned into
On 11/17/20 15:18, Jack Christensen wrote:
>> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
>> RETURNS int AS $$
>> #routine_label lnm
>> BEGIN
>> RAISE NOTICE '%', lnm.par1;
Could that be somehow shoehorned into the existing ALIAS syntax, maybe as
DECLARE
lnm ALIAS FOR ALL
On Tue, Nov 17, 2020 at 1:36 PM Pavel Stehule
wrote:
>
> Personally in your example I very much like notation "update_item.id",
> because there is a clean signal so "id" is the function's argument. When
> you use "$id", then it is not clean if "id" is a local variable or
> function's argument.
Hi
út 17. 11. 2020 v 19:04 odesílatel Jack Christensen
napsal:
> When arguments and other local variables in pl/pgsql functions have the
> same name as columns referenced in queries it is necessary to disambiguate
> the names. This can be done by prefixing the function name (e.g.
>
When arguments and other local variables in pl/pgsql functions have the
same name as columns referenced in queries it is necessary to disambiguate
the names. This can be done by prefixing the function name (e.g.
my_func.name), using the argument number is the case of an argument (e.g.
$1), or
70 matches
Mail list logo
