Pavel Stehule wrote:
> 2010/9/9 Tom Lane :
> > Darren Duncan writes:
> >> Since Pg's FUNCTION already seems to take on both roles, so overloading the
> >> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
> >> where returning VOID means procedure, then what is being added
Peter Eisentraut wrote:
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
Since Pg's FUNCTION already seems to take on both roles, so
overloading the meaning of the FUNCTION keyword, like what a C
function or a Perl sub does, where returning VOID means procedure,
then what is being added b
On tor, 2010-09-09 at 16:16 -0400, Tom Lane wrote:
> You might care to go back and re-read some of the extensive prior
> threads about this, but to my mind the main thing that would justify
> inventing a separate PROCEDURE facility is if procedures were to
> execute outside the transaction system,
On tor, 2010-09-09 at 13:08 -0700, Darren Duncan wrote:
> Since Pg's FUNCTION already seems to take on both roles, so
> overloading the meaning of the FUNCTION keyword, like what a C
> function or a Perl sub does, where returning VOID means procedure,
> then what is being added by a distinct PROCED
2010/9/9 Darren Duncan :
> Kevin Grittner wrote:
>>
>> Tom Lane wrote:
>>>
>>> to my mind the main thing that would justify inventing a separate
>>> PROCEDURE facility is if procedures were to execute outside the
>>> transaction system, so that they could start and stop transactions
>>> for themse
Tom Lane wrote:
One point that has to be made is that returning multiple result sets
as if they were successive queries restricts the client to reading the
result sets serially; that is, you must read all of result A before you
can look at result B, etc.
One aspect that I don't really like abou
2010/9/9 Kevin Grittner :
> Tom Lane wrote:
>
>> I'm with Robert: this would be a huge extra complication for a
>> remarkably small amount of benefit.
>
> This is probably heresy, but unless it's required by the standard or
> drop-dead simple to allow, I'd be fine with *not* supporting
> overloadi
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 Robert Haas :
>>> That seems like a lot of complexity for no real benefit, to me.
>
>> no, you can to specify a expected result type - it's very for some
>> convert or import functions. So we expect so out procedures will
>> supports to OUT
Tom Lane wrote:
> I'm with Robert: this would be a huge extra complication for a
> remarkably small amount of benefit.
This is probably heresy, but unless it's required by the standard or
drop-dead simple to allow, I'd be fine with *not* supporting
overloading of stored procedure names based o
Pavel Stehule writes:
> 2010/9/9 Robert Haas :
>> That seems like a lot of complexity for no real benefit, to me.
> no, you can to specify a expected result type - it's very for some
> convert or import functions. So we expect so out procedures will
> supports to OUT parameters, then implementat
Kevin Grittner wrote:
Tom Lane wrote:
to my mind the main thing that would justify inventing a separate
PROCEDURE facility is if procedures were to execute outside the
transaction system, so that they could start and stop transactions
for themselves.
That is the biggest distinction in my mind
Tom Lane wrote:
> I don't understand the point of a RETURN value when there can be
> no caller to return a value to.
The version of the draft standard I last saw allowed something like:
SET x = CALL sp(param_a, param_b);
I seem to remember Sybase supported a return value as well as OUT
par
Robert Haas writes:
> To be honest, I am already pretty unhappy with
> the changes that make it impossible to redefined foo(a int) as
> foo(anteater int), which is a perfectly reasonable thing to want to do
> but which is now forbidden because someone MIGHT have called the
> function as foo(a := 3
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
so I can to write
CREATE PROCEDURE foo(OUT a int)
...
and
CREATE PROCEDURE foo(OUT a varchar)
...
and then when I use a statement CALL is correct procedure selected
"Kevin Grittner" writes:
> Tom Lane wrote:
>> to my mind the main thing that would justify inventing a separate
>> PROCEDURE facility is if procedures were to execute outside the
>> transaction system, so that they could start and stop transactions
>> for themselves.
> That is the biggest disti
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
so I can to write
CREATE PROCEDURE foo(OUT a int)
...
and
CREATE PROCEDURE foo(OUT a varchar)
...
and then when I use a statement CALL is correct procedure selected
On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule wrote:
>>> so I can to write
>>>
>>> CREATE PROCEDURE foo(OUT a int)
>>> ...
>>>
>>> and
>>> CREATE PROCEDURE foo(OUT a varchar)
>>> ...
>>>
>>> and then when I use a statement CALL is correct procedure selected
>>>
>>> CALL foo(textvariable)
>>
>> Tha
2010/9/9 Darren Duncan :
> Tom Lane wrote:
>>
>> Darren Duncan writes:
>>>
>>> Since Pg's FUNCTION already seems to take on both roles, so overloading
>>> the meaning of the FUNCTION keyword, like what a C function or a Perl sub
>>> does, where returning VOID means procedure, then what is being ad
Tom Lane wrote:
Darren Duncan writes:
Since Pg's FUNCTION already seems to take on both roles, so overloading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE?
You might car
2010/9/9 Robert Haas :
> On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule wrote:
>> 2010/9/9 Darren Duncan :
>>> Pavel Stehule wrote:
there are lot of questions - and I am not sure if procedures
implementation can be done in one release cycle. The basic questions:
* should be
Tom Lane wrote:
> to my mind the main thing that would justify inventing a separate
> PROCEDURE facility is if procedures were to execute outside the
> transaction system, so that they could start and stop transactions
> for themselves.
That is the biggest distinction in my mind, too. Support
2010/9/9 Tom Lane :
> Darren Duncan writes:
>> Since Pg's FUNCTION already seems to take on both roles, so overloading the
>> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
>> where returning VOID means procedure, then what is being added by a distinct
>> PROCEDURE?
>
On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule wrote:
> 2010/9/9 Darren Duncan :
>> Pavel Stehule wrote:
>>>
>>> there are lot of questions - and I am not sure if procedures
>>> implementation can be done in one release cycle. The basic questions:
>>>
>>> * should be special catalog for procedures
2010/9/9 Darren Duncan :
> Pavel Stehule wrote:
>>
>> there are lot of questions - and I am not sure if procedures
>> implementation can be done in one release cycle. The basic questions:
>>
>> * should be special catalog for procedures or we will use pg_proc?
>> * how can be implemented OUT variab
Darren Duncan writes:
> Since Pg's FUNCTION already seems to take on both roles, so overloading the
> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
> where returning VOID means procedure, then what is being added by a distinct
> PROCEDURE?
You might care to go bac
Pavel Stehule wrote:
there are lot of questions - and I am not sure if procedures
implementation can be done in one release cycle. The basic questions:
* should be special catalog for procedures or we will use pg_proc?
* how can be implemented OUT variables - the original implementation
is simpl
2010/9/9 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue sep 09 14:29:57 -0400 2010:
>
>> * how can be implemented OUT variables - the original implementation
>> is simple - it's just pointer, but it's not directly possible inside
>> postgres, because we use a MemoryContexts?
>
> Wh
Excerpts from Pavel Stehule's message of jue sep 09 14:29:57 -0400 2010:
> * how can be implemented OUT variables - the original implementation
> is simple - it's just pointer, but it's not directly possible inside
> postgres, because we use a MemoryContexts?
Why is this a problem? Just return a
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 David E. Wheeler :
>>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
about 2 months for full time and 2 months for partial time - is my tip
>>>
>>> Two months full or two months partial? I'll take the latter, please!
>
>> 2 months -
2010/9/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/9 David E. Wheeler :
>>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
about 2 months for full time and 2 months for partial time - is my tip
>>>
>>> Two months full or two months partial? I'll take the latter, please!
>
>> 2 months -
Pavel Stehule writes:
> 2010/9/9 David E. Wheeler :
>> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
>>> about 2 months for full time and 2 months for partial time - is my tip
>>
>> Two months full or two months partial? I'll take the latter, please!
> 2 months - basic implementation
> 1 mon
2010/9/9 David E. Wheeler :
> On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
>
>> about 2 months for full time and 2 months for partial time - is my tip
>
> Two months full or two months partial? I'll take the latter, please!
2 months - basic implementation
1 months - cleaning and work on commi
On Sep 9, 2010, at 12:12 AM, Pavel Stehule wrote:
> about 2 months for full time and 2 months for partial time - is my tip
Two months full or two months partial? I'll take the latter, please!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Cc: PostgreSQL-development
> Sent: Fri, September 3, 2010 1:07:03 PM
> Subject: Re: [HACKERS] returning multiple result sets from a stored procedure
>
>
>> I noticed in postgres you cannot return multiple result sets from a
>> stored procedure (surprisingly as it looks like
OK, how much are we talking about?
From: Josh Berkus
To: John Adams
Cc: PostgreSQL-development
Sent: Fri, September 3, 2010 1:07:03 PM
Subject: Re: [HACKERS] returning multiple result sets from a stored procedure
> I noticed in postgres you cannot ret
On Sun, Sep 5, 2010 at 2:26 PM, Peter Eisentraut wrote:
> On fre, 2010-09-03 at 16:18 -0400, Tom Lane wrote:
>> Part of the reason it's sat on TODO is lack of consensus about how
>> such a feature ought to look/work; particularly since most of the
>> discussion about it has considered that it'd go
On Fri, Sep 3, 2010 at 4:40 PM, John Adams wrote:
> If you guys care about money and time why would you spend the best years of
> your life basically copying commercial products for free?
I don't work for free. :-)
There was a point at which this was just a hobby for me, but as it has
since tur
On Fri, Sep 03, 2010 at 01:40:56PM -0700, John Adams wrote:
> OT:
>
> OFF TOPIC:
> I honestly do not mean any offence, just out of curiosity.
> If you guys care about money and time why would you spend the best
> years of your life basically copying commercial products for free?
> Because for a
On Sep 6, 2010, at 12:07 AM, Pavel Stehule wrote:
> The work on PostgreSQL is adventure, and very good experience, very
> good school for me. It's job only for people who like programming, who
> like hacking, it isn't job for people, who go to office on 8 hours.
> Next I use PostgreSQL for my job
one, and money is important, but not on top
for me - life have to be adventure!
Regards
Pavel Stehule
>
> John
>
>
> From: Josh Berkus
> To: John Adams
> Cc: PostgreSQL-development
> Sent: Fri, September 3, 2010 1:07:03 PM
> Subject:
John
From: Josh Berkus
To: John Adams
Cc: PostgreSQL-development
Sent: Fri, September 3, 2010 1:07:03 PM
Subject: Re: [HACKERS] returning multiple result sets from a stored procedure
> I noticed in postgres you cannot return multiple result sets from a
On 9/5/2010 2:05 PM, Heikki Linnakangas wrote:
On 04/09/10 17:16, Merlin Moncure wrote:
Curious: is mulitset handling as you see it supported by the current
v3 protocol?
The manual says:
The response to a SELECT query (or other queries that return row sets, such as
EXPLAIN or SHOW) normally
On fre, 2010-09-03 at 16:18 -0400, Tom Lane wrote:
> Part of the reason it's sat on TODO is lack of consensus about how
> such a feature ought to look/work; particularly since most of the
> discussion about it has considered that it'd go along with stored
> procedures executing outside of transacti
Heikki Linnakangas writes:
> On 04/09/10 17:16, Merlin Moncure wrote:
>> Curious: is mulitset handling as you see it supported by the current
>> v3 protocol?
> If a multiple return sets from a procedure are returned just like
> multiple return sets from multiple queries, that's already covered b
On 04/09/10 17:16, Merlin Moncure wrote:
Curious: is mulitset handling as you see it supported by the current
v3 protocol?
The manual says:
The response to a SELECT query (or other queries that return row sets, such as
EXPLAIN or SHOW) normally consists of RowDescription, zero or more DataR
2010/9/4 Merlin Moncure :
> On Sat, Sep 4, 2010 at 10:10 AM, Pavel Stehule
> wrote:
>>> Also as mentioned upthread there are effective workarounds if you poke
>>> around a bit. This is a FAQ, and there are about 3-4 solid methods
>>> (if you search the archives) that cover most problems you woul
On Sat, Sep 4, 2010 at 10:10 AM, Pavel Stehule wrote:
>> Also as mentioned upthread there are effective workarounds if you poke
>> around a bit. This is a FAQ, and there are about 3-4 solid methods
>> (if you search the archives) that cover most problems you would be
>> looking at multiple result
2010/9/4 Merlin Moncure :
> On Fri, Sep 3, 2010 at 4:07 PM, Josh Berkus wrote:
>>
>>> I noticed in postgres you cannot return multiple result sets from a
>>> stored procedure (surprisingly as it looks like a very good dbms).
>>
>> That feature has been on the TODO list for years. However, nobody
On Fri, Sep 3, 2010 at 4:07 PM, Josh Berkus wrote:
>
>> I noticed in postgres you cannot return multiple result sets from a
>> stored procedure (surprisingly as it looks like a very good dbms).
>
> That feature has been on the TODO list for years. However, nobody has
> stepped forward to either w
On 9/3/10 2:20 PM, Josh Berkus wrote:
> However, if you look at any mature, large open
> source project you will find that at least 1/4 of its code contributors
> are paid to work on the project by *someone*, and that those paid
> developers account for 70% to 95% of the code.
Relevant link for th
John,
> I honestly do not mean any offence, just out of curiosity.
>
> If you guys care about money and time why would you spend the best years
> of your life basically copying commercial products for free?
We don't do it to copy commercial products. We do it to build something
better than them
Josh Berkus writes:
>> I noticed in postgres you cannot return multiple result sets from a
>> stored procedure (surprisingly as it looks like a very good dbms).
> That feature has been on the TODO list for years. However, nobody has
> stepped forward to either write it, or to fund working on it.
> I noticed in postgres you cannot return multiple result sets from a
> stored procedure (surprisingly as it looks like a very good dbms).
That feature has been on the TODO list for years. However, nobody has
stepped forward to either write it, or to fund working on it. If your
company has prog
On Thu, Sep 2, 2010 at 7:17 PM, Alvaro Herrera
wrote:
> Excerpts from John Adams's message of jue sep 02 18:25:45 -0400 2010:
>> I noticed in postgres you cannot return multiple result sets from a stored
>> procedure (surprisingly as it looks like a very good dbms).
>
> If you're really intent abo
Excerpts from John Adams's message of jue sep 02 18:25:45 -0400 2010:
> I noticed in postgres you cannot return multiple result sets from a stored
> procedure (surprisingly as it looks like a very good dbms).
If you're really intent about doing this, you can emulate it by
returning a set of refc
I noticed in postgres you cannot return multiple result sets from a stored
procedure (surprisingly as it looks like a very good dbms).
I would like to suggest adding this feature.
- It is very usefull
- It is supported by all other dbmss I have worked with.
- makes porting applications to postg
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > libpq supports it just fine. You do a PQsendQuery() and then as many
> > PQgetResult()s as it takes to get back the results. This worked for a
> > while AFAIK.
>
> That only works if the caller is prepared to read each result serially,
> and no
On Sun, Nov 20, 2005 at 10:01:24PM +0100, Magnus Hagander wrote:
> FWIW, MSSQL used to do only multiple sequential resultsets (from stored
> procs, or semicolon separated statements). With SQL 2005, they added
> interleaved ones - see
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
On Sun, Nov 20, 2005 at 03:41:36PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Urk! I don't think anyone is suggesting that resultsets can be
> > interleaved.
>
> No? If not, why not? The main reason why this is being pushed, IIRC,
> is the claim that "you can do this easily in
> > On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
> >> That only works if the caller is prepared to read each result
> >> serially, and not (say) a row at a time in parallel.
>
> > Urk! I don't think anyone is suggesting that resultsets can be
> > interleaved.
>
> No? If not, why n
Martijn van Oosterhout writes:
> On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
>> That only works if the caller is prepared to read each result serially,
>> and not (say) a row at a time in parallel.
> Urk! I don't think anyone is suggesting that resultsets can be
> interleaved.
No?
Hello
I thinking about solution based on setof cursors. This solustion has three
big minus:
1. I can "unpack" cursors after finish of called procedure. If I get
exception, or long query, I can show nothing.
2. Old clients don't understand and don't unpack cursor. Statement call is
(+/-) == sta
On Sun, Nov 20, 2005 at 06:05:36PM +0100, Pavel Stehule wrote:
> what is difference between rows with different structures and tables?
> Tables are more logic. But I unlike function which returns setof tables.
> This need data type table. I prefere normal clasic solution.
You're confusing syntax
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > libpq supports it just fine. You do a PQsendQuery() and then as many
> > PQgetResult()s as it takes to get back the results. This worked for a
> > while AFAIK.
>
> That only works if the caller is prepa
> for my task I need little different form :-(
>
> create function a(..) returns setof tables
>
> but SQL2003 needs type table, and this can be solution
You want a function return entire tables at a time? Why bother when you
can just return rows and signal when the next table starts?
what is d
Martijn van Oosterhout writes:
> libpq supports it just fine. You do a PQsendQuery() and then as many
> PQgetResult()s as it takes to get back the results. This worked for a
> while AFAIK.
That only works if the caller is prepared to read each result serially,
and not (say) a row at a time in par
On Sun, Nov 20, 2005 at 08:43:05AM +0100, Pavel Stehule wrote:
> >Consider:
> >
> >create function a(anyrecord) returns anyrecord;
> >create function b(int4) returns anyrecord;
> >
> >select a(b(2));
> >
>
> for my task I need little different form :-(
>
> create function a(..) returns setof tabl
On Sat, Nov 19, 2005 at 08:02:08PM -0300, Alvaro Herrera wrote:
> Hmm -- probably we could declare that the current libpq API will not
> support multiple result sets from one query, and return only the first
> one to the application discarding the rest. (It just occured to me --
> what happens if
Consider:
create function a(anyrecord) returns anyrecord;
create function b(int4) returns anyrecord;
select a(b(2));
for my task I need little different form :-(
create function a(..) returns setof tables
but SQL2003 needs type table, and this can be solution
___
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > So, kill a few birds with one stone. Any thoughts?
>
> I don't think any of this will actually work :-(. There's too much code
> that assumes that all the tuples returned by a query are alike, and I
> for one don't feel like trying to find and
On Sat, Nov 19, 2005 at 12:43:15PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > So, kill a few birds with one stone. Any thoughts?
>
> I don't think any of this will actually work :-(. There's too much code
> that assumes that all the tuples returned by a query are alike, and I
>
Martijn van Oosterhout writes:
> So, kill a few birds with one stone. Any thoughts?
I don't think any of this will actually work :-(. There's too much code
that assumes that all the tuples returned by a query are alike, and I
for one don't feel like trying to find and fix it all. (Not all of it
I've been thinking about this and wondered if this is a way to get it
done without too much work.
1. Create an "anyrecord" type to which any record type can be cast.
It's essentially a heaptuple with a tupledesc.
2. "anyrecord" is opaque to the parser, you cannot dereference it, only
output it or
73 matches
Mail list logo
