Hi,
On 05/10/2011 02:55 PM, Robert Haas wrote:
On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
no - you are little bit confused :). CALL and function execution
shares nothing. There is significant differences between function and
procedure. Function is called
On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
no - you are little bit confused :). CALL and function execution
shares nothing. There is significant differences between function and
procedure. Function is called only from executor - from some plan, and
you have
2011/5/10 Robert Haas robertmh...@gmail.com:
On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
no - you are little bit confused :). CALL and function execution
shares nothing. There is significant differences between function and
procedure. Function is called only
Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
what would be the actual use cases of any of these features?
Let's collect some, so we can think of ways to make them work.
The two things which leap to mind for me are:
(1) All the \d commands in psql should be
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On m??n, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
equivalent to one \d command.
You don't
On 05/09/2011 08:20 PM, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
On Mon, May 9, 2011 at 9:21 PM, Andrew Dunstan and...@dunslane.net wrote:
On 05/09/2011 08:20 PM, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented
Christopher Browne wrote:
Multiple resultsets in one call would be a good thing, though, no?
cheers
I *thought* the purpose of having stored procedures was to allow a
substrate supporting running multiple transactions, so it could do
things like:
- Managing vacuums
- Managing
2011/5/10 Bruce Momjian br...@momjian.us:
Christopher Browne wrote:
Multiple resultsets in one call would be a good thing, though, no?
cheers
I *thought* the purpose of having stored procedures was to allow a
substrate supporting running multiple transactions, so it could do
things
On Apr 26, 2011, at 6:08 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
-- doing a backfill operation for 10GB of computed data, taking 8
hours, where I don't want to hold a transaction open for 8 hours
since this is a high-volume OLTP database.
Been there, done that.
On Tue, Apr 26, 2011 at 10:12 PM, Greg Stark gsst...@mit.edu wrote:
On Tue, Apr 26, 2011 at 11:55 PM, Josh Berkus j...@agliodbs.com wrote:
Here's where I wanted autonomous transactions just last week, and didn't
have them so I had to use a python script outside the database:
-- doing a CREATE
These don't seem like compelling use cases at all to me. You said you
had to fall back to using a python script outside the database, but
what disadvantage does that have? Why is moving your application logic
into the database an improvement?
Since both were part of a code rollout, it
On Wed, Apr 27, 2011 at 6:48 PM, Josh Berkus j...@agliodbs.com wrote:
If you pursue your argument a little further, Greg, why do we have
functions at all? We could do it all in the application.
Autonomous transactions have value on their own. But it's not so that
you can run create index
Greg,
Because we want to be able to manipulate data in queries in
data-type-specific ways. For example we want to do aggregations on the
result of a function or index scans across a user data type, etc.
I don't see how this is different from wanting to capture error output,
which would face
On Apr 27, 2011, at 3:28 PM, Josh Berkus wrote:
Actually, you can already sort of do that using XSLT. So I don't
necessary think that's a prohibitive idea, depending on implementation.
After all, many of the new non-relational databases implement exactly this.
The proposed JSON data type
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
equivalent to one \d command.
You don't need stored procedures with special transaction behavior for
this.
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
equivalent to one \d command.
You don't need stored procedures
Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from any client, through calling one SP
equivalent to one \d command.
You don't need stored procedures
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features? Let's collect
some, so we can think of ways to make them work.
Here's where I wanted autonomous
Tom Lane t...@sss.pgh.pa.us wrote:
No, but what you *would* need is the ability to return multiple
result sets from one call.
At least.
Even then, you could not exactly duplicate the current output of
\d; but you could duplicate the functionality.
I would think that psql could
Josh Berkus j...@agliodbs.com wrote:
-- doing a backfill operation for 10GB of computed data, taking 8
hours, where I don't want to hold a transaction open for 8 hours
since this is a high-volume OLTP database.
Been there, done that. Definitely not a rare use case.
-Kevin
--
Sent via
On Tue, Apr 26, 2011 at 11:55 PM, Josh Berkus j...@agliodbs.com wrote:
Here's where I wanted autonomous transactions just last week, and didn't
have them so I had to use a python script outside the database:
-- doing a CREATE INDEX CONCURRENTLY for 150 partitions on a partitioned
table.
--
On Mon, Apr 25, 2011 at 12:07 PM, Peter Eisentraut pete...@gmx.net wrote:
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features? Let's collect
some, so we can
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.
I would like to collect some specs on
Peter Eisentraut pete...@gmx.net wrote:
what would be the actual use cases of any of these features?
Let's collect some, so we can think of ways to make them work.
The two things which leap to mind for me are:
(1) All the \d commands in psql should be implemented in SPs so
that they are
Peter Eisentraut wrote:
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features?
Looping over hundreds of identical schema executing DDL statements on
each. We
On Mon, Apr 25, 2011 at 2:07 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start
Peter Eisentraut wrote:
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features? Let's collect
some, so we can think of ways to make them work.
An analogy I like to
28 matches
Mail list logo
