Re: DO ... RETURNING - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: DO ... RETURNING
Date
Msg-id m2r4g93t35.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Hi,

That topic apparently raises each year and rehash the same points.

Pavel Stehule <pavel.stehule@gmail.com> writes:
> probably we can allow using DO in CTE without impact on other SQL
> statements, and for this purpose we need to know returned
> TupleDescriptor early.

I still think that DO being a utility statement, having it take
parameters and return data is going to be a wart in a part of the system
that has only too many of them already.

My thinking revolves around CTE support for functions:
 WITH FUNCTION name(param, ...)       RETURNS type      LANGUAGE plpgsql AS (   $$ function body here $$ ) SELECT
name(x,...) FROM ...;
 

> so I am able accept it, although I am thinking so we are going in
> strange direction. We are not able do simply tasks simply (we cannot
> execute SQL script on server side simply) :(. But it is not problem of
> Hannu design.

With the DO utility command you can already execute SQL script on the
server quite simply. After all your proposals it's still unclear to me
where you want to process which data? (I admit this time I didn't pay
much attention, sorry about that)

> other question - can we find some readable and intuitive syntax for DO
> parametrization?

See above.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: JSON and unicode surrogate pairs
Next
From: Pavel Stehule
Date:
Subject: Re: DO ... RETURNING