2008/12/10 Bruce Momjian <[EMAIL PROTECTED]>: > Pavel Stehule wrote: >> >> PL/pgSQL < PL/SQL < ADA so using '=>' is only consistent and natural. >> >> And it is my goal. >> > >> > Well, that is interesting, but in SQL we already use 'AS' in most places >> > where we want to assign a label to a value, so it seems AS is more >> > logical for SQL at this point. >> >> Question is - what is label - is it parameter name or some other value? >> >> Every output in SQL has default label - column name, or some default. >> And we use "AS" for change this default label. So using AS for param >> names is bad idea. >> >> Please, show me other case. > > Well, we use AS in the FROM clause to label tables and those labels can > be used to reference the table in other places in the query. I see us > using AS here as a way to assign the contant to a label that is > referenced as a function parameter.
this is still change of existing label - and it's argument for me - it is label - not name of argument. you cannot call function in postgresql in any other context (PostgreSQL doesn't support statement CALL), so every AS sets label for given value. You change property of some constant. Or we should to go via Perl way, where every operator has different meaning in different content (but I hope, so not). SELECT column AS bbbb from foo; AS specifies other label than column name SELECT sin(column AS bbb) from foo; ---> so it reason why using AS for param names is wrong, with change of context I changing meaning. > >> > The problem with a GUC is that when it is changed it breaks things and >> > it might be set in a dump file but not in postgresql.conf; there is a >> > long list of problems we have encountered when changing SQL semenatics >> > via GUC, autocommit being one of them. >> >> ofcourse, users have to use own mind - but it not break postgresql >> using. GUC allow implement new feature in some steps. Actually it's >> used for standard literals, and I don't know about any problems. >> >> Autocommit is different case - it's invisible but important change. >> Named params change syntax and impact is much more less than moving >> tsearch2 to core. > > The problem is that function text might rely on a certain setting of the > GUC and unless the function sets the GUC itself it could break > functions. > can you show sample? > -- > Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
