Re: PL/pgSQL 'i = i + 1' Syntax

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: PL/pgSQL 'i = i + 1' Syntax
Дата
Msg-id 1148069001.3833.20.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: PL/pgSQL 'i = i + 1' Syntax  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: PL/pgSQL 'i = i + 1' Syntax
Список pgsql-hackers
Ühel kenal päeval, R, 2006-05-19 kell 14:39, kirjutas Jim C. Nasby:
> On Fri, May 19, 2006 at 09:57:29PM +0300, Hannu Krosing wrote:
> > ??hel kenal p??eval, R, 2006-05-19 kell 11:24, kirjutas Jim C. Nasby:
> > 
> > > Something that's always bugged me is how horribly variables are handled
> > > in plpgsql, namely that if you have a variable and a field with the same
> > > name it can be extremely difficult to keep them seperated. Perhaps := vs
> > > = might be a way to keep it clear as to which is which...
> > 
> > I can't see how := helps here. Once you have fields, you are either in
> > SQL-land and always use = or have the fields selected into a type or
> > recors and can use record.field syntax.
>  
> The problem happens down in the SQL layer. Actually, I guess := wouldn't
> help anything...
> 
> > > Though, a better way would probably just be to provide a built-in
> > > construct for referencing plpgsql variables, such as $.
> > 
> > Where is it exactly a problem which can't be solved simply by naming
> > your variables differently from fields?
> 
> That's how I solve it, but a lot of newbies get bit by this. 

A newbie will be bit by several things anyway. For example you could
write code in C (and several other languages) with all your loop
variables named "i", and those in inner scopes overshadowing those in
outer.

> What makes
> it really bad is that they typically get bit after they've already
> written a bunch of code that doesn't prefix variable names with
> something, so then they have to switch coding-conventions after they
> already have a bunch of code written.

A less disruptive change would be to have some predefined "record" where
all local variables belong to, perhaps called 'local' or '_local_' :) so
one could access both input parameter inp_orderdate and declared
variable var_orderdate as local.inp_orderdate and local.var_orderdate
respectively ? The old use (without local.) should still work.

> I think it would be better to at least strongly recommend always
> prefixing variables and parameters with something. 

At least we should use such convention in our sample code in docs.

> I'd argue that it'd
> be even better to put us on the road of eventually mandating plpgsql
> variables be prefixed with something (like $), but I'm not holding my
> breath on that one...

I dont believe in mandating non-backward-compatible changes, but prefix
$ may be one way to disambiguate vars and fieldnames.

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: [OT] MySQL is bad, but THIS bad?
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: text_position worst case runtime