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 m
On Tue, Jun 11, 2013 at 12:01 PM, Hannu Krosing 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:
http://farrago.sourceforge.net/design/UserDefinedTypesAndRout
On 06/11/2013 05:27 PM, Merlin Moncure wrote:
> On Tue, Jun 11, 2013 at 9:45 AM, Stephen Frost 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
>>> uti
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
On Tue, Jun 11, 2013 at 11:26 AM, Pavel Stehule wrote:
> 2013/6/11 Stephen Frost :
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> 2013/6/11 Stephen Frost :
>>> > And this still has next-to-nothing to do with the specific proposal that
>>> > was put forward.
>>> >
>>> > I'd like actual pro
On Tue, Jun 11, 2013 at 11:00 AM, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2013/6/11 Stephen Frost :
>> > 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
2013/6/11 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2013/6/11 Stephen Frost :
>> > 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 t
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/6/11 Stephen Frost :
> > 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 able to
On Tue, Jun 11, 2013 at 9:45 AM, Stephen Frost 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 spi worker
2013/6/11 Pavel Stehule :
> 2013/6/11 Stephen Frost :
>> * 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 work
2013/6/11 Stephen Frost :
> * 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 abou
* 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
On Tue, Jun 11, 2013 at 6:07 AM, Pavel Stehule wrote:
> 2013/6/11 Dimitri Fontaine :
>> Pavel Stehule 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 o
2013/6/11 Dimitri Fontaine :
> Pavel Stehule 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 these
scripts will be executed. Maybe
On 06/11/2013 11:30 AM, Pavel Stehule wrote:
> 2013/6/11 Dimitri Fontaine :
>> Hi,
>>
>> That topic apparently raises each year and rehash the same points.
>>
>> Pavel Stehule writes:
>>> probably we can allow using DO in CTE without impact on other SQL
>>> statements, and for this purpose we need
Pavel Stehule 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 mailing list (pgsql-hackers
2013/6/11 Dimitri Fontaine :
> Hi,
>
> That topic apparently raises each year and rehash the same points.
>
> Pavel Stehule 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 stil
Hi,
That topic apparently raises each year and rehash the same points.
Pavel Stehule 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,
2013/6/11 David Fetter :
> 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
>>
>> pro
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
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 return
On 06/11/2013 06:17 AM, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
>> On 06/10/2013 09:45 PM, Pavel Stehule wrote:
>>> 2013/6/10 David Fetter :
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
>> Hallo Everybody
>>
>> As far as I
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/6/10 Stephen Frost :
> > 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 set return
2013/6/10 Hannu Krosing :
> On 06/10/2013 09:45 PM, Pavel Stehule wrote:
>> 2013/6/10 David Fetter :
>>> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing :
> Hallo Everybody
>
> As far as I can see, currently you can not return
> anything o
2013/6/10 Stephen Frost :
> * 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?
* 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 tempora
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
> 2013/6/10 David Fetter :
>> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
>>> 2013/6/10 Hannu Krosing :
Hallo Everybody
As far as I can see, currently you can not return
anything out of a DO (anonymous code) block.
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 thi
2013/6/10 David Fetter :
> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
>> 2013/6/10 Hannu Krosing :
>> > 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 pl
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
> > 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, ui
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/6/10 Hannu Krosing :
> > 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 ?
For my part, w
2013/6/10 Hannu Krosing :
> 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().s
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, u
33 matches
Mail list logo
