Re: WIP: default values for function parameters

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: WIP: default values for function parameters
Date: 2008-12-10 13:44:29
Message-ID: 200812101344.mBADiTm26790@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> > 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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-12-10 13:58:11 Re: WIP: default values for function parameters
Previous Message KaiGai Kohei 2008-12-10 13:36:09 Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)