From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | John <johnf(at)jfcomputer(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: understanding select into |
Date: | 2010-04-09 17:32:51 |
Message-ID: | k2z162867791004091032r401ee913r3531742cb8c2871@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Hello
2010/4/9 John <johnf(at)jfcomputer(dot)com>:
> Hi,
> I am reviewing a function written by some xTuple guys. What is interesting
> about it is it uses the "INTO" statement like
>
> select something into _p from sometable where somecriteria.
>
> The function contiunes and uses the data retreived
> _p.somefield_name
>
> And then the function ends.
>
>
> Ok my question:
>
> I also thought the select "into" created a real table. But after running the
> function the table does not exist. I see no where that a 'drop' is issued.
> In fact the function uses lot's of select into's like (_test, _r, etc..). So
> would some kind soul explain what is happening.
>
_p is record variable. See some lines before. There will be DECLARE part
DECLARE p RECORD;
There is plpgsql's SELECT INTO and SQL's SELECT INTO with little bit
different syntax. First - target is list of variables or record
variable, second - target is table.
> Could it be that "_p" is drop automaticly when the function ends? Something
> to do with scope.
>
_p is just variable
regards
Pavel Stehule
> Could it have something to do with the fact the function returns only an
> integer? And that causes the table to be drop.
>
> As you can see I'm lost here!
>
>
> Johnf
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql
>
From | Date | Subject | |
---|---|---|---|
Next Message | John | 2010-04-09 17:53:48 | Re: understanding select into |
Previous Message | Plugge, Joe R. | 2010-04-09 17:31:13 | Re: understanding select into |