Skip site navigation (1) Skip section navigation (2)

Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm

From: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: chriskl(at)familyhealth(dot)com(dot)au, pgsql-patches(at)postgresql(dot)org, neilc(at)samurai(dot)com
Subject: Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
Date: 2005-12-21 07:38:05
Message-ID: BAY20-F6D6D4F2A8A4CA06C57EADF9310@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-patches
>
>"Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> writes:
> >>>> x, y := r;
> >
> >>> That strikes me as a really bad idea.  It weakens both syntax and
> >>> semantic error checking, to accomplish how much?
> >>
> >> Could use PHP-style thingy:
> >> LIST(x, y) := r;
>
>Actually, ROW(x, y) would be the right spelling per SQL convention.

I am not sure. Allow SQL function on left side of assigment?
>
> > It's inconsystency :-(.
> > EXECUTE INTO and SELECT INTO use scalar of vectors without anything.
>

>But in both of those cases there are required leading keywords to give
>you some clue what's supposed to come next.  Allowing bare x, y at the
>start of a statement is just a recipe for misconstruing stuff that was
>intended as something else and is one or two punctuation characters shy
>of perfection.
>
Yes. But it's not neccessery or maybe T_SCALAR is keyword by self. And code 
of actual patch is very natural (but I have to use 
plpgsq_push_back_token()). If I use ROW(...) := syntax, I have to change for 
others statements:

EXECUTE '...' INTO ROW(a,b,c); -- atc.
FOR ROW(a,b,c) IN SELECT

but it's not wrong idea? What do you think?

I don't have objective arguments. It's questions personal preferences. What 
I know, some others languages has similar syntax.

1. a,b,c := r;    -- C, Python
2. (a,b,c) := r; -- Perl
3. ROW(a,b,c) := r; -- Perl, PHP

>There is also the problem of insufficient semantic cross-checking.  A
>record variable doesn't have any very well-defined order of fields, so
>who's to say which value goes to x and which to y?  For that matter,
>if I just have
>	x := y
>and y is a single-field rowtype, it'd be entirely unclear whether x is
>to receive the row value or the field value.
>

Valid argument. And there is error in my patch now. Semantics is clean I 
think. You can use only declared variables and you know if var. is scalar or 
row/record. If x is scalar, then x will contain first field of y. But in 
this moment, I have to do implicit retyping - which can be wrong. And ROW(x) 
:= y syntax is better.

Oracle syntax don't allow list of variables here. It's argument. I'll change 
patch on ROW() := .. for test.



>I don't think this buys anything that is worth the can of worms we'd
>be opening up.  The extension for FOR might be worth doing, but not
>the assignment change.
>
It's depend. In my practic life, I spend time on code
  p1 := r.p1; p2 := r.p2; ....

>And, to reiterate Andrew's point, this entire discussion should have
>been held before you wrote a line of code.  It is utterly wrong
>to be doing it in pgsql-patches.

I am sorry. I had to use different subject, like EXPERIMENTAL or PROPOSAL 
patch.

Regards
Pavel Stehule

_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. 
http://www.msn.cz/


In response to

pgsql-patches by date

Next:From: Hannu KrosingDate: 2005-12-21 07:50:03
Subject: Re: status of concurrent VACUUM patch ...
Previous:From: Christopher Kings-LynneDate: 2005-12-21 04:09:02
Subject: Re: PLpgSQL: list of scalars as row for assign stmt, fore

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group