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

From Pavel Stehule
Subject Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm
Date
Msg-id BAY20-F6D6D4F2A8A4CA06C57EADF9310@phx.gbl
Whole thread Raw
In response to Re: PLpgSQL: list of scalars as row for assign stmt, fore and fors stm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
>
>"Pavel Stehule" <pavel.stehule@hotmail.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/


pgsql-patches by date:

Previous
From: "Serge A. Ribalchenko"
Date:
Subject: new uk_UA i18n file
Next
From: Bruce Momjian
Date:
Subject: Re: COPY LOCK for WAL bypass