On 06/11/2013 06:17 AM, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
2013/6/10 David Fetter da...@fetter.org:
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
Hello
The current situation is akin to not being able to use queries
directly but always requiring you to create a view first and
then do select ... from myview
ok
probably we can allow using DO in CTE without impact on other SQL
statements, and for this purpose we need to know returned
On Tue, Jun 11, 2013 at 09:30:32AM +0200, Pavel Stehule wrote:
Hello
The current situation is akin to not being able to use queries
directly but always requiring you to create a view first and
then do select ... from myview
ok
probably we can allow using DO in CTE without impact
2013/6/11 David Fetter da...@fetter.org:
On Tue, Jun 11, 2013 at 09:30:32AM +0200, Pavel Stehule wrote:
Hello
The current situation is akin to not being able to use queries
directly but always requiring you to create a view first and
then do select ... from myview
ok
probably we
Hi,
That topic apparently raises each year and rehash the same points.
Pavel Stehule pavel.steh...@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
2013/6/11 Dimitri Fontaine dimi...@2ndquadrant.fr:
Hi,
That topic apparently raises each year and rehash the same points.
Pavel Stehule pavel.steh...@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
Pavel Stehule pavel.steh...@gmail.com writes:
FOR r IN pg_databases
LOOP
CONNECT r.dbname;
Do you mean that you want to run this DO block on the client side?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers
On 06/11/2013 11:30 AM, Pavel Stehule wrote:
2013/6/11 Dimitri Fontaine dimi...@2ndquadrant.fr:
Hi,
That topic apparently raises each year and rehash the same points.
Pavel Stehule pavel.steh...@gmail.com writes:
probably we can allow using DO in CTE without impact on other SQL
statements,
2013/6/11 Dimitri Fontaine dimi...@2ndquadrant.fr:
Pavel Stehule pavel.steh...@gmail.com writes:
FOR r IN pg_databases
LOOP
CONNECT r.dbname;
Do you mean that you want to run this DO block on the client side?
no, really no.
I am thinking about some outer server side process, where
On Tue, Jun 11, 2013 at 6:07 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/6/11 Dimitri Fontaine dimi...@2ndquadrant.fr:
Pavel Stehule pavel.steh...@gmail.com writes:
FOR r IN pg_databases
LOOP
CONNECT r.dbname;
Do you mean that you want to run this DO block on the client
* Merlin Moncure (mmonc...@gmail.com) wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and multiple sets that
utilizes background worker (we have example spi worker that gives some
hints about how pl/pgsql could be made to
2013/6/11 Stephen Frost sfr...@snowman.net:
* Merlin Moncure (mmonc...@gmail.com) wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and multiple sets that
utilizes background worker (we have example spi worker that gives some
2013/6/11 Pavel Stehule pavel.steh...@gmail.com:
2013/6/11 Stephen Frost sfr...@snowman.net:
* Merlin Moncure (mmonc...@gmail.com) wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and multiple sets that
utilizes background
On Tue, Jun 11, 2013 at 9:45 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and multiple sets that
utilizes background worker (we have example
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/11 Stephen Frost sfr...@snowman.net:
And this still has next-to-nothing to do with the specific proposal that
was put forward.
I'd like actual procedures too, but it's a completely different and
distinct thing from making DO blocks
2013/6/11 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/11 Stephen Frost sfr...@snowman.net:
And this still has next-to-nothing to do with the specific proposal that
was put forward.
I'd like actual procedures too, but it's a completely
On Tue, Jun 11, 2013 at 11:00 AM, Stephen Frost sfr...@snowman.net wrote:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/11 Stephen Frost sfr...@snowman.net:
And this still has next-to-nothing to do with the specific proposal that
was put forward.
I'd like actual procedures too,
On Tue, Jun 11, 2013 at 11:26 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/6/11 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/11 Stephen Frost sfr...@snowman.net:
And this still has next-to-nothing to do with the specific proposal that
On Tuesday, June 11, 2013, Pavel Stehule wrote:
I don't believe there's any intent to ever have DO used for stored
procedures. Not only are stored procedures deserving of their own
top-level command (eg: CALL, as has been discussed before..), but I
believe they would necessairly have
On 06/11/2013 05:27 PM, Merlin Moncure wrote:
On Tue, Jun 11, 2013 at 9:45 AM, Stephen Frost sfr...@snowman.net wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and multiple sets
On Tue, Jun 11, 2013 at 12:01 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
Could you point to the ISO/ANSI SQL CALL definition ?
I can't: no one can because the SQL standard is not available online.
But you can look at various proxies, for example here:
On 2013-06-11 19:01 CEST, Hannu Krosing wrote:
On 06/11/2013 05:27 PM, Merlin Moncure wrote:
On Tue, Jun 11, 2013 at 9:45 AM, Stephen Frost ... wrote:
* Merlin Moncure ... wrote:
I agree with all your comments pretty much down the line. Need top
level CALL that supports parameterization and
2013/6/10 Hannu Krosing ha...@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 =
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
If there was then what were the arguments against doing this ?
I don't recall offhand, but it would be *extremely* useful to have.
Or was this just that it was not thought important at that time
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@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
2013/6/10 David Fetter da...@fetter.org:
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@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
On 06/10/2013 09:34 PM, David Fetter wrote:
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?
Yes.
Of course we could default it to RETURNS SETOF RECORD :)
2. If I did, does this
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
2013/6/10 David Fetter da...@fetter.org:
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
Hallo Everybody
As far as I can see, currently you can not return
anything out of a DO
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
not too much. Two different concepts in one statement is not good
idea.
What are the different concepts..? We already have set returning
functions, why would set returning anonymous functions be any different?
What using a cursors as temporary
2013/6/10 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
not too much. Two different concepts in one statement is not good
idea.
What are the different concepts..? We already have set returning
functions, why would set returning anonymous functions be any
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
2013/6/10 David Fetter da...@fetter.org:
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing ha...@2ndquadrant.com:
Hallo Everybody
As far as I can see, currently
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
2013/6/10 Stephen Frost sfr...@snowman.net:
What are the different concepts..? We already have set returning
functions, why would set returning anonymous functions be any different?
1. DO as function
2. DO as batch
We already have
32 matches
Mail list logo
