Ășt 17. 11. 2020 v 21:45 odesĂlatel Chapman Flack <c...@anastigmatix.net> 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 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 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?) > > Regards, > -Chap > > > [1] > https://www.postgresql.org/docs/13/sql-keywords-appendix.html#KEYWORDS-TABLE >