st 17. 3. 2021 v 4:52 odesÃlatel Michael Paquier <mich...@paquier.xyz>
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 items, with the namespace associated to the routine name being
> the first one pushed to the list after plpgsql_ns_init() initializes
> the top of it. Then, the proposed patch hijacks the namespace lookup
> list by doing a replacement of the root label while parsing the
> routine and then tweaks the lookup logic when a variable is qualified
> (aka name2 != NULL) to bump the namespace list one level higher so as
> it does not look after the namespace with the routine name but instead
> fetches the one defined by ROUTINE_NAME. That seems rather bug-prone
> to me, to say the least.
>
I'll check what can be done. I am not sure if it is possible to push a new
label to the same level as the top label.
> No changes to plpgsql_compile_inline()?
>
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("redundant option"),
> + errhint("The command \"routine_label\" can be used
> only once in rutine."),
> + plpgsql_scanner_errposition(location)));
> s/rutine/routine/
>
> + /* Don't allow repeated redefination of routine label */
> redefination?
>
I'll check it. But inline block has not top label
> 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 the top-most namespace which is the
> routine name now, meaning that we would maintain not one, but N top
> namespace labels that could be used as aliases of the root one.
>
I do not have a strong opinion, but I am inclined to disallow this. I am
afraid so code can be less readable.
There is a precedent - SQL doesn't allow you to use table names as
qualifiers when you have an alias.
But it is a very important question. The selected behavior strongly impacts
an implementation.
What is the more common opinion about it? 1. Should we allow the original
top label or not? 2. Should we allow to define more top labels?
Regards
Pavel
> --
> Michael
>
