Re: DO ... RETURNING

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: DO ... RETURNING
Дата
Msg-id 51B6352F.6030306@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
> 2013/6/10 David Fetter <david@fetter.org>:
>> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
>>> 2013/6/10 Hannu Krosing <hannu@2ndquadrant.com>:
>>>> Hallo Everybody
>>>>
>>>> As far as I can see, currently you can not return
>>>> anything out of a DO (anonymous code) block.
>>>>
>>>> Something like
>>>>
>>>> DO LANGUAGE plpythonu RETURNS TABLE (name text, uid int, gid int) $$
>>>> with open('/etc/passwd') as f:
>>>>     fields = f.readline().split(':')
>>>>     while fields:
>>>>         name, uid, gid = fields[0], int(fields[2]),int(fields[3])
>>>>         yield name, uid, gid
>>>>         fields = f.readline().split(':')
>>>> $$;
>>>>
>>>> As I did not pay attention when DO was introduced,
>>>> I thought it is faster to ask here than read all possibly
>>>> relevant mails in archives
>>>>
>>>> So: has there been a discussion on extending the DO
>>>> construct with ability to rturn data out of it, similar
>>>> to what named functions do.
>>>>
>>>> If there was then what were the arguments against doing this ?
>>>>
>>>> Or was this just that it was not thought important at that time ?
>>> I don't like this idea. I know so DO is +/- function, but it is too
>>> restrict. I hope so we will have a procedures with possibility unbound
>>> queries.
>>>
>>> and then you can do
>>>
>>> DO $$
>>>   SELECT * FROM pg_class;
>>>   SELECT * FROM pg_proc;
>>>   ...
>>> $$ LANGUAGE SQL;
>>>
>>> and you don't need to define output structure - what is much more user friendly.
>> If I understand the proposal correctly, the idea is only to try to
>> return something when DO is invoked with RETURNING.
>>
>> 1.  Did I understand correctly, Hannu?
>> 2.  If I did, does this alleviate your concerns, Pavel?
> not too much. Two different concepts in one statement is not good
> idea. 
What two different concepts do you mean ?
> What using a cursors as temporary solution?
>
> BEGIN;
> DO $$
> BEGIN
>  OPEN mycursor AS SELECT * FROM blablabla;
> END $$
> FETCH FROM mycursor;
>
> COMMIT;
How would this work in an SQL query ?

SELECT * FROM (FETCH FROM mycursor ) mc;

?
>
> Still I don't like this idea, because you should to support DO
> RETURNING in other statements - like INSERT INTO DO RETURNING ???
Yes, I really would like DO to be full "set returning construct"similar to SELECT or I/U/D RETURNING.


The syntax should be either RETURNS (as in function definition) or
RETURNING as for I/U/D.

I actually like the RETURNING better as it really does immediate returnand not just defines a function returning
something.

>
> What about local temporary functions ??
>
> CREATE TEMPORARY FUNCTION xx(a int)
> RETURNES TABLE (xxx)
>
> SELECT * FROM xxx;
You mean that we define and use it in the same statement and after ';'
ends the statement it disappears from scope ?

This would probably still bloat pg_function table ?


-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ




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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: DO ... RETURNING
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: DO ... RETURNING