Re: DO ... RETURNING

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DO ... RETURNING
Date: 2013-06-11 09:16:46
Message-ID: m2r4g93t35.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-06-11 09:30:01 Re: DO ... RETURNING
Previous Message Andres Freund 2013-06-11 08:47:17 Re: JSON and unicode surrogate pairs