Ăș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
>

Reply via email to