Pavel Stehule wrote:
2010/9/9 Tom Lane t...@sss.pgh.pa.us:
Darren Duncan dar...@darrenduncan.net 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
OK, how much are we talking about?
From: Josh Berkus j...@agliodbs.com
To: John Adams john_adams_m...@yahoo.com
Cc: PostgreSQL-development pgsql-hackers@postgreSQL.org
Sent: Fri, September 3, 2010 1:07:03 PM
Subject: Re: [HACKERS] returning multiple result sets
To: John Adams john_adams_m...@yahoo.com
Cc: PostgreSQL-development pgsql-hackers@postgreSQL.org
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
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
2010/9/9 David E. Wheeler da...@kineticode.com:
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
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/9 David E. Wheeler da...@kineticode.com:
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
2010/9/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/9 David E. Wheeler da...@kineticode.com:
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?
2010/9/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/9 David E. Wheeler da...@kineticode.com:
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?
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 Alvaro Herrera alvhe...@commandprompt.com:
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
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
Darren Duncan dar...@darrenduncan.net 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
2010/9/9 Darren Duncan dar...@darrenduncan.net:
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
On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/9/9 Darren Duncan dar...@darrenduncan.net:
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
2010/9/9 Tom Lane t...@sss.pgh.pa.us:
Darren Duncan dar...@darrenduncan.net 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
Tom Lane t...@sss.pgh.pa.us 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
2010/9/9 Robert Haas robertmh...@gmail.com:
On Thu, Sep 9, 2010 at 4:17 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/9/9 Darren Duncan dar...@darrenduncan.net:
Pavel Stehule wrote:
there are lot of questions - and I am not sure if procedures
implementation can be done in one release
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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
2010/9/9 Darren Duncan dar...@darrenduncan.net:
Tom Lane wrote:
Darren Duncan dar...@darrenduncan.net 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
On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule pavel.steh...@gmail.com 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)
That seems like a
2010/9/9 Robert Haas robertmh...@gmail.com:
On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule pavel.steh...@gmail.com 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 kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
2010/9/9 Robert Haas robertmh...@gmail.com:
On Thu, Sep 9, 2010 at 4:29 PM, Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us 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
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/9 Robert Haas robertmh...@gmail.com:
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
Tom Lane t...@sss.pgh.pa.us 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
2010/9/9 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/9/9 Robert Haas robertmh...@gmail.com:
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
2010/9/9 Kevin Grittner kevin.gritt...@wicourts.gov:
Tom Lane t...@sss.pgh.pa.us 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
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
2010/9/9 Darren Duncan dar...@darrenduncan.net:
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us 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
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
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, so
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
On Sun, Sep 5, 2010 at 2:26 PM, Peter Eisentraut pete...@gmx.net 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
From: Josh Berkus j...@agliodbs.com
To: John Adams john_adams_m...@yahoo.com
Cc: PostgreSQL-development pgsql-hackers@postgreSQL.org
Sent: Fri, September 3, 2010 1:07:03 PM
Subject: Re: [HACKERS] returning multiple result sets from a stored procedure
I noticed
] 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 a very good dbms).
That feature has been on the TODO list for years. However, nobody has
stepped forward to either write
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 -
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 person
On Fri, Sep 3, 2010 at 4:40 PM, John Adams john_adams_m...@yahoo.com 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,
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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 Fri, Sep 3, 2010 at 4:07 PM, Josh Berkus j...@agliodbs.com 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
2010/9/4 Merlin Moncure mmonc...@gmail.com:
On Fri, Sep 3, 2010 at 4:07 PM, Josh Berkus j...@agliodbs.com 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
On Sat, Sep 4, 2010 at 10:10 AM, Pavel Stehule pavel.steh...@gmail.com 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
2010/9/4 Merlin Moncure mmonc...@gmail.com:
On Sat, Sep 4, 2010 at 10:10 AM, Pavel Stehule pavel.steh...@gmail.com
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)
On Thu, Sep 2, 2010 at 7:17 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
Josh Berkus j...@agliodbs.com 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
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.
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 this:
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
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
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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,
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 one
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 tables
but SQL2003
Martijn van Oosterhout kleptog@svana.org 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
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
On Sun, Nov 20, 2005 at 11:29:39AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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
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
(+/-) ==
Martijn van Oosterhout kleptog@svana.org 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
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 not? The main
On Sun, Nov 20, 2005 at 03:41:36PM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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
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
Martijn van Oosterhout kleptog@svana.org 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
On Sat, Nov 19, 2005 at 12:43:15PM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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
73 matches
Mail list logo
