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 very_long_name.*;
or something?
I thought about it - but I don't think so this syntax is correct - in your case it should be
lnm.* ALIAS FOR ALL very_long_name.*;
but it looks a little bit scary in ADA based language.
Maybe
DECLARE lnm LABEL ALIAS FOR very_long_name;
or
DECLARE lnm ALIAS FOR LABEL very_long_name;
I think so implementation should not be hard. But there are advantages, disadvantages - 1. label aliasing increases the complexity of variable searching (instead comparing string with name of namespace, you should compare list of names). Probably not too much. 2. The syntax is a little bit harder than #option. Implementation based on #option can just rename top namespace, so there is not any overhead, and parsing #option syntax is pretty simple (and the syntax is shorter). So from implementation reasons I prefer #option based syntax. There is clear zero impact on performance.
Regards
I checked code - and I have to change my opinion - the current implementation of namespaces in plpgsql doesn't allow renaming or realising labels elegantly. The design has low memory requirements but it is not flexible. I wrote a proof concept patch, and I had to hack the nsitem little bit.
postgres=# create or replace function bubu(a int, b int) returns void as $$
#routine_label b
maybe a better name for this option can be "routine_alias".
begin raise notice '% %', b.a, b.b; end; $$ language plpgsql; CREATE FUNCTION postgres=# select bubu(10,20); NOTICE: 10 20 ┌──────┐ │ bubu │ ╞══════╡ │ │ └──────┘ (1 row)
Pavel
(And would it be cool if Table C.1 [1] had some sort of javascript-y filtering on reservedness categories, for just such kinds of bikeshedding?)
