Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/30/2013 12:04 AM, Pavel Stehule wrote: > > > > 2013/8/29 David E. Wheeler > > > On Aug 29, 2013, at 2:48 PM, Andres Freund > wrote: > > >> You have yet to supply any arguments which support this position. > > >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Andres Freund > On 2013-08-29 23:54:28 +0200, Pavel Stehule wrote: > > > No think so PERFORM is a significant problem. A mayor problem for > > > beginners is usually a fact, so PL/pgSQL is ALGOL like languages - and > they > > > don't know with these languages. Second problem is missing

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 05:31 PM, David E. Wheeler wrote: On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: Still I don't think so correct solution is enabling a unbound SELECTs, but correct is a fix a PERFORM and remove a necessity to use a PERFORM for call of VOID functions. Well, in this thread,

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 2:48 PM, Andres Freund wrote: > > >> You have yet to supply any arguments which support this position. > > > > I am not convinced that's enough of a reason, but the requirement to use > > PERFORM for SELECTs that aren't stored anywhere actually ha

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 23:54:28 +0200, Pavel Stehule wrote: > > No think so PERFORM is a significant problem. A mayor problem for > > beginners is usually a fact, so PL/pgSQL is ALGOL like languages - and they > > don't know with these languages. Second problem is missing a more dynamic > > data structures.

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Pavel Stehule > > > > 2013/8/29 Josh Berkus > >> On 08/29/2013 02:22 PM, Pavel Stehule wrote: >> > Still I don't think so correct solution is enabling a unbound SELECTs, >> but >> > correct is a fix a PERFORM and remove a necessity to use a PERFORM for >> call >> > of VOID functions. >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:48 PM, Andres Freund wrote: >> You have yet to supply any arguments which support this position. > > I am not convinced that's enough of a reason, but the requirement to use > PERFORM for SELECTs that aren't stored anywhere actually has prevented > bugs for me. I am not con

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Josh Berkus > On 08/29/2013 02:22 PM, Pavel Stehule wrote: > > Still I don't think so correct solution is enabling a unbound SELECTs, > but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for > call > > of VOID functions. > > You have yet to supply any arguments w

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 14:40:24 -0700, Josh Berkus wrote: > On 08/29/2013 02:22 PM, Pavel Stehule wrote: > > Still I don't think so correct solution is enabling a unbound SELECTs, but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > > of VOID functions. > > You have yet to

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 11:01 PM, David E. Wheeler wrote: > On Aug 29, 2013, at 1:11 PM, Pavel Stehule wrote: > >> I cannot to say what is good design for PL/pgSQL - only I feel so some >> variant of RETURN statement is not good, because semantic is significantly >> different. And I see a increasing incon

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:41 PM, Pavel Stehule wrote: > I am thinking, so I propose a enough solution for you - when you use CTE for > execution of VOID function, then result vill be VOID set, what we can accept > as undefined result, and in this case a PERFORM should not be required. If > CTE wil

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 2:22 PM, Pavel Stehule > wrote: > > > Still I don't think so correct solution is enabling a unbound SELECTs, > but correct is a fix a PERFORM and remove a necessity to use a PERFORM for > call of VOID functions. > > Well, in this thread, I believe

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 02:22 PM, Pavel Stehule wrote: > Still I don't think so correct solution is enabling a unbound SELECTs, but > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > of VOID functions. You have yet to supply any arguments which support this position. Several pe

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 14:31:55 -0700, David E. Wheeler wrote: > On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: > > > Still I don't think so correct solution is enabling a unbound SELECTs, but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > > of VOID functions. > >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: > Still I don't think so correct solution is enabling a unbound SELECTs, but > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > of VOID functions. Well, in this thread, I believe you are the only person who feels th

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 1:11 PM, Pavel Stehule > wrote: > > > I cannot to say what is good design for PL/pgSQL - only I feel so some > variant of RETURN statement is not good, because semantic is significantly > different. And I see a increasing inconsistency between a o

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 1:11 PM, Pavel Stehule wrote: > I cannot to say what is good design for PL/pgSQL - only I feel so some > variant of RETURN statement is not good, because semantic is significantly > different. And I see a increasing inconsistency between a original ADA and > PL/pgSQL. So

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/28 Robert Haas > On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule > wrote: > > what is magical? > > > > Stored procedures - we talk about this technology was a originally simple > > script moved from client side to server side. > > > > so if I write on client side > > > > BEGIN; > > SELEC

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/28 Hannu Krosing > On 08/28/2013 12:10 AM, Pavel Stehule wrote: > > > > > > so if I write on client side > > > > BEGIN; > > SELECT 1,2; > > SELECT 2; > > SELECT 3,4; > > END; > > > > then I expect results > > > > 1,2 > > 2 > > 3,4 > And you are perfectly ok to discard the results > A

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/28/2013 09:59 PM, Robert Haas wrote: > On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule > wrote: >> what is magical? >> >> Stored procedures - we talk about this technology was a originally simple >> script moved from client side to server side. >> >> so if I write on client side >> >> BEGIN;

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Wed, Aug 28, 2013 at 2:59 PM, Robert Haas wrote: > On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule > wrote: >> what is magical? >> >> Stored procedures - we talk about this technology was a originally simple >> script moved from client side to server side. >> >> so if I write on client side >>

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule wrote: > what is magical? > > Stored procedures - we talk about this technology was a originally simple > script moved from client side to server side. > > so if I write on client side > > BEGIN; > SELECT 1,2; > SELECT 2; > SELECT 3,4; > END; >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/28/2013 12:10 AM, Pavel Stehule wrote: > > > so if I write on client side > > BEGIN; > SELECT 1,2; > SELECT 2; > SELECT 3,4; > END; > > then I expect results > > 1,2 > 2 > 3,4 And you are perfectly ok to discard the results Actually it would be much more helpful to have "discard the res

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 3:10 PM, Pavel Stehule wrote: > CREATE PROCEDURE foo() > BEGIN > SELECT 1,2; > SELECT 2; > SELECT 3,4 > END; > > And is not strange expect a result > > CALL foo() > > 1,2 > 2 > 3,4 > > Procedure is a script (batch) moved to server side for better performance and > b

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/27 David E. Wheeler > On Aug 27, 2013, at 1:36 PM, Pavel Stehule > wrote: > > > I agree with David that we should use some new syntax to specify > > return-results-directly-to-client, assuming we ever get any such > > functionality. It seems like a pretty bad choice of default behavior,

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 1:36 PM, Pavel Stehule wrote: > I agree with David that we should use some new syntax to specify > return-results-directly-to-client, assuming we ever get any such > functionality. It seems like a pretty bad choice of default behavior, > which is essentially what you're sayin

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/27 Tom Lane > Pavel Stehule writes: > > 2013/8/27 David E. Wheeler > >> But whatever the keyword, I think it makes sense to require one to > return > >> results to the caller. Any query that does not return, yield, or capture > >> (select into) values should just have its results discard

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Pavel Stehule writes: > 2013/8/27 David E. Wheeler >> But whatever the keyword, I think it makes sense to require one to return >> results to the caller. Any query that does not return, yield, or capture >> (select into) values should just have its results discarded. > A usual and first solution

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/27 David E. Wheeler > On Aug 27, 2013, at 12:30 AM, Pavel Stehule > wrote: > > > I disagree - Tom K. speaking about what he likes or dislikes (and about > what he didn't use) He forgot about strong points of implicit result or > interesting points. Clients usually has no problem with dyna

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/27/2013 08:32 PM, David E. Wheeler wrote: > On Aug 27, 2013, at 12:30 AM, Pavel Stehule wrote: > >> I disagree - Tom K. speaking about what he likes or dislikes (and about what >> he didn't use) He forgot about strong points of implicit result or >> interesting points. Clients usually has

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 27, 2013, at 12:30 AM, Pavel Stehule wrote: > I disagree - Tom K. speaking about what he likes or dislikes (and about what > he didn't use) He forgot about strong points of implicit result or > interesting points. Clients usually has no problem with dynamic datasets - > PHP, DBI, Llibpq

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/24 Tom Lane > Pavel Stehule writes: > > Oracle has a special function for returning sets from procedures - see a > > new functionality "Implicit Result Sets" > > http://tkyte.blogspot.cz/2013/07/12c-implicit-result-sets.html > > That article is worth reading, because Tom K. points out exa

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Pavel Stehule writes: > Oracle has a special function for returning sets from procedures - see a > new functionality "Implicit Result Sets" > http://tkyte.blogspot.cz/2013/07/12c-implicit-result-sets.html That article is worth reading, because Tom K. points out exactly why T-SQL's approach is a b

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/24 Merlin Moncure > On Fri, Aug 23, 2013 at 5:07 PM, Tom Lane wrote: > > Josh Berkus writes: > >> Currently the only way to return query results to the caller is to use > >> some form of RETURN. It is 100% consistent. > > > > I don't find it consistent at all, because what that means is

[HACKERS] PL/pgSQL PERFORM with CTE

On Fri, Aug 23, 2013 at 5:07 PM, Tom Lane wrote: > Josh Berkus writes: >> Currently the only way to return query results to the caller is to use >> some form of RETURN. It is 100% consistent. > > I don't find it consistent at all, because what that means is that the > data is to be returned to t

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Josh Berkus writes: > On 08/23/2013 01:06 PM, Marko Tiikkaja wrote: >>> Is there some reason we wouldn't use RETURN QUERY in that case, instead >>> of SELECT? As I said above, it would be more consistent with existing >>> PL/pgSQL. >> How would using the same syntax to do an entirely different t

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Josh Berkus > On 08/23/2013 11:30 AM, Pavel Stehule wrote: > > 2013/8/23 Josh Berkus > > > >> Pavel, > >> > >>> But it can have a different reason. In T-SQL (Microsoft or Sybase) or > >> MySQL > >>> a unbound query is used to direct transfer data to client side. > >> > >> Are you plann

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/23/2013 01:06 PM, Marko Tiikkaja wrote: >> Is there some reason we wouldn't use RETURN QUERY in that case, instead >> of SELECT? As I said above, it would be more consistent with existing >> PL/pgSQL. > > How would using the same syntax to do an entirely different thing be > consistent? Cu

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-23 22:02, Josh Berkus wrote: On 08/23/2013 11:30 AM, Pavel Stehule wrote: 2013/8/23 Josh Berkus Pavel, But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL a unbound query is used to direct transfer data to client side. Are you planning to implement tha

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/23/2013 11:30 AM, Pavel Stehule wrote: > 2013/8/23 Josh Berkus > >> Pavel, >> >>> But it can have a different reason. In T-SQL (Microsoft or Sybase) or >> MySQL >>> a unbound query is used to direct transfer data to client side. >> >> Are you planning to implement that in PL/pgSQL? >> >> >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 David E. Wheeler > On Aug 23, 2013, at 8:51 PM, Pavel Stehule > wrote: > > > it is about a personal taste - if you prefer more verbose or less > verbose languages. > > > > I feeling a PERFORM usage as something special and you example is nice > case, where I am think so PERFORM is good

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 23, 2013, at 8:51 PM, Pavel Stehule wrote: > it is about a personal taste - if you prefer more verbose or less verbose > languages. > > I feeling a PERFORM usage as something special and you example is nice case, > where I am think so PERFORM is good for verbosity. I really do not see

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Merlin Moncure > On Fri, Aug 23, 2013 at 1:38 PM, Pavel Stehule > wrote: > > > > > > > > 2013/8/23 Merlin Moncure > > I think so is not good if some programming language functionality does > one > > in one context (functions) and does something else in second context > > (procedures).

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Fri, Aug 23, 2013 at 1:38 PM, Pavel Stehule wrote: > > > > 2013/8/23 Merlin Moncure > I think so is not good if some programming language functionality does one > in one context (functions) and does something else in second context > (procedures). It's not really different -- it means 'return

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Merlin Moncure > On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus wrote: > > Pavel, > > > >> But it can have a different reason. In T-SQL (Microsoft or Sybase) or > MySQL > >> a unbound query is used to direct transfer data to client side. > > > > Are you planning to implement that in PL/

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Josh Berkus > Pavel, > > > But it can have a different reason. In T-SQL (Microsoft or Sybase) or > MySQL > > a unbound query is used to direct transfer data to client side. > > Are you planning to implement that in PL/pgSQL? > > yes. I would to see a stored procedures with this function

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus wrote: > Pavel, > >> But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL >> a unbound query is used to direct transfer data to client side. > > Are you planning to implement that in PL/pgSQL? > > Currently, PL/pgSQL requires RET

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Pavel, > But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL > a unbound query is used to direct transfer data to client side. Are you planning to implement that in PL/pgSQL? Currently, PL/pgSQL requires RETURN in order to return a query result to the caller. Is the

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Josh Berkus > Tom, > > > > Jan might remember more about his thought process here, but I'm thinking > > that he copied the SELECT-must-have-INTO rule and then chose to invent > > a new statement for the case of wanting to discard the result. I think > > you could make an argument for t

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Tom, > Jan might remember more about his thought process here, but I'm thinking > that he copied the SELECT-must-have-INTO rule and then chose to invent > a new statement for the case of wanting to discard the result. I think > you could make an argument for that being good from an oversight-det

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Josh Berkus writes: > I have to agree with Merlin. I've always thought the PERFORM thing was > a wart we'd get around to removing eventually. In what way is it a feature? I'd always assumed it was a PL/SQL compatibility thing, but a look in a PL/SQL reference doesn't turn up any such statement.

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/20/2013 05:48 AM, Merlin Moncure wrote: > On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule > wrote: >> >> >> >> 2013/8/20 Merlin Moncure >>> >>> On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund >>> I think the way forward is to remove the restriction such that data >>> returning queries must

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 3:38 PM, Pavel Stehule > wrote: > > > pg_notify returns void, so there are no necessary casting to void > > > > so enhanced check - so all returned columns are void should be enough > > What if I call another function I wrote myself that returns a

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:38 PM, Pavel Stehule wrote: > pg_notify returns void, so there are no necessary casting to void > > so enhanced check - so all returned columns are void should be enough What if I call another function I wrote myself that returns an INT, but I do not care about the INT? M

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 3:18 PM, Pavel Stehule > wrote: > > > can you show some examples, please > > This is not dissimilar to what I am actually doing: > > CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT); > > CREATE OR REPLACE FUNCTION shipit ( > VAR

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:18 PM, Pavel Stehule wrote: > can you show some examples, please This is not dissimilar to what I am actually doing: CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT); CREATE OR REPLACE FUNCTION shipit ( VARIADIC things TEXT[] ) RETURNS BOOL LANGUAGE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 3:05 PM, Pavel Stehule > wrote: > > > When you would to ignore result, then you should to use a PERFORM - > actually, it is limited now and should be fixed. Have no problem with it. > > Glad to have you on board. :-) > > > I don't would to enable

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 3:05 PM, Pavel Stehule wrote: > When you would to ignore result, then you should to use a PERFORM - actually, > it is limited now and should be fixed. Have no problem with it. Glad to have you on board. :-) > I don't would to enable a free unbound statement that returns res

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 2:53 PM, Pavel Stehule > wrote: > > >> I am passing the values returned from a CTE to a call to pg_notify(). I > do not care to collect the output of pg_notify(), which returns VOID. > > > > it is little bit different issue - PL/pgSQL doesn't chec

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:53 PM, Pavel Stehule wrote: >> I am passing the values returned from a CTE to a call to pg_notify(). I do >> not care to collect the output of pg_notify(), which returns VOID. > > it is little bit different issue - PL/pgSQL doesn't check if returned type is > VOID - it ca

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 8/20/13 2:53 PM, Pavel Stehule wrote: 2013/8/20 David E. Wheeler I am passing the values returned from a CTE to a call to pg_notify(). I do not care to collect the output of pg_notify(), which returns VOID. it is little bit different issue - PL/pgSQL doesn't check if returned type is VOID

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 2:41 PM, Pavel Stehule > wrote: > > > yes, in this context you should not use a PERFORM > > > > PL/pgSQL protect you before useless queries - so you can use a CTE > without returned result directly or CTE with result via PERFORM statement > (and i

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule wrote: > > > > 2013/8/20 Merlin Moncure >> >> On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund >> wrote: >> > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote: >> >> Hi Pavel, >> >> >> >> On Aug 20, 2013, at 2:11 PM, Pavel Stehule >> >> wrote: >>

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:44 PM, Pavel Stehule wrote: > I think the way forward is to remove the restriction such that data > returning queries must be PERFORM'd > > I disagree, current rule has sense. Perhaps a DECLARE FUNCTION attribute that turns off the functionality, then? Best, David --

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013-08-20 14:35 keltezéssel, David E. Wheeler írta: On Aug 20, 2013, at 2:31 PM, Pavel Stehule wrote: but it works postgres=# do $$begin with x as (select 10) insert into omega select * from x; end;$$; DO But this does not: david=# DO $$ david$# BEGIN david$# PERFORM * FROM ( david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:41 PM, Pavel Stehule wrote: > yes, in this context you should not use a PERFORM > > PL/pgSQL protect you before useless queries - so you can use a CTE without > returned result directly or CTE with result via PERFORM statement (and in > this case it must be unmodifing CTE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 Merlin Moncure > On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund > wrote: > > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote: > >> Hi Pavel, > >> > >> On Aug 20, 2013, at 2:11 PM, Pavel Stehule > wrote: > >> > >> >> david=# DO $$ > >> >> david$# BEGIN > >> >> david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 2:31 PM, Pavel Stehule > wrote: > > > but it works > > > > postgres=# do $$begin with x as (select 10) insert into omega select * > from x; end;$$; > > DO > > But this does not: > > david=# DO $$ > david$# BEGIN > david$# PERFORM * FROM ( > da

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund wrote: > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote: >> Hi Pavel, >> >> On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote: >> >> >> david=# DO $$ >> >> david$# BEGIN >> >> david$# WITH now AS (SELECT now()) >> >> david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:31 PM, Pavel Stehule wrote: > but it works > > postgres=# do $$begin with x as (select 10) insert into omega select * from > x; end;$$; > DO But this does not: david=# DO $$ david$# BEGIN david$# PERFORM * FROM ( david$# WITH inserted AS ( david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja wrote: > > >> postgres=# DO $$ > >> BEGIN > >>PERFORM * FROM (WITH now AS (SELECT now()) > >> SELECT * from now) x; > >> END; > >> $$; > >> DO > > > > .. which doesn't work if you want to use table-modifying CTEs. >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja wrote: >> postgres=# DO $$ >> BEGIN >>PERFORM * FROM (WITH now AS (SELECT now()) >> SELECT * from now) x; >> END; >> $$; >> DO > > .. which doesn't work if you want to use table-modifying CTEs. Which, in fact, is exactly my use case (though no

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 Andres Freund > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote: > > Hi Pavel, > > > > On Aug 20, 2013, at 2:11 PM, Pavel Stehule > wrote: > > > > >> david=# DO $$ > > >> david$# BEGIN > > >> david$# WITH now AS (SELECT now()) > > >> david$# PERFORM * from

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 8/20/13 2:21 PM, Pavel Stehule wrote: 2013/8/20 David E. Wheeler Well, there ought to be *some* way to tell PL/pgSQL to discard the result. Right now I am adding a variable to select into but never otherwise use. Inelegant, IMHO. Perhaps I’m missing some other way to do it? If so, it would

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote: > Hi Pavel, > > On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote: > > >> david=# DO $$ > >> david$# BEGIN > >> david$# WITH now AS (SELECT now()) > >> david$# PERFORM * from now; > >> david$# END; > >> david$#

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/20 David E. Wheeler > Hi Pavel, > > On Aug 20, 2013, at 2:11 PM, Pavel Stehule > wrote: > > >> david=# DO $$ > >> david$# BEGIN > >> david$# WITH now AS (SELECT now()) > >> david$# PERFORM * from now; > >> david$# END; > >> david$# $$; > >> ERROR: synt

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Hi Pavel, On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote: >> david=# DO $$ >> david$# BEGIN >> david$# WITH now AS (SELECT now()) >> david$# PERFORM * from now; >> david$# END; >> david$# $$; >> ERROR: syntax error at or near "PERFORM" >> LINE 4: PE

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Hello 2013/8/20 David E. Wheeler > Hackers, > > This seems reasonable: > > david=# DO $$ > david$# BEGIN > david$# WITH now AS (SELECT now()) > david$# SELECT * from now; > david$# END; > david$# $$; > ERROR: query has no destination for result data > HI

[HACKERS] PL/pgSQL PERFORM with CTE

Hackers, This seems reasonable: david=# DO $$ david$# BEGIN david$# WITH now AS (SELECT now()) david$# SELECT * from now; david$# END; david$# $$; ERROR: query has no destination for result data HINT: If you want to discard the results of a SELECT, use PE