Hello
2013/4/16 aasat
> Is "stored procedures" planned in future? I think is a "most missing"
> future
> today in Postgres.
>
It is in ToDo, but nobody working on this feature in this moment, probably.
>
> Using a dblink to emulate commit in transaction is very complicated
>
>
probably auton
Is "stored procedures" planned in future? I think is a "most missing" future
today in Postgres.
Using a dblink to emulate commit in transaction is very complicated
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/stored-procedures-tp4331060p5752274.html
Sent from the P
On Thu, Sep 1, 2011 at 12:18 PM, Josh Berkus wrote:
> On 8/31/11 12:15 PM, Merlin Moncure wrote:
>> An out of process, autonomous transaction type implementation should
>> probably not sit under stored procedures for a number of reasons --
>> mainly that it's going to expose too many implementatio
On Thu, Sep 1, 2011 at 1:18 PM, Josh Berkus wrote:
> On 8/31/11 12:15 PM, Merlin Moncure wrote:
>> An out of process, autonomous transaction type implementation should
>> probably not sit under stored procedures for a number of reasons --
>> mainly that it's going to expose too many implementation
On 8/31/11 12:15 PM, Merlin Moncure wrote:
> An out of process, autonomous transaction type implementation should
> probably not sit under stored procedures for a number of reasons --
> mainly that it's going to expose too many implementation details to
> the user. For example, does a SP heavy app
On Wed, Aug 31, 2011 at 9:00 AM, Thom Brown wrote:
> On 9 May 2011 20:52, Merlin Moncure wrote:
>> On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian wrote:
>>> Josh Berkus wrote:
Peter,
> I would like to collect some specs on this feature. So does anyone have
> links to document
On 9 May 2011 20:52, Merlin Moncure wrote:
> On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian wrote:
>> Josh Berkus wrote:
>>> Peter,
>>>
>>> > I would like to collect some specs on this feature. So does anyone have
>>> > links to documentation of existing implementations, or their own spec
>>> > w
Hi,
On 05/10/2011 02:55 PM, Robert Haas wrote:
> On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule
> 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 executo
2011/5/10 Robert Haas :
> On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule
> 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
On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule 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 to know a structure o
2011/5/10 Bruce Momjian :
> 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 lik
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
> - Managi
On Mon, May 9, 2011 at 9:21 PM, Andrew Dunstan wrote:
>
>
> On 05/09/2011 08:20 PM, Bruce Momjian wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut 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
On 05/09/2011 08:20 PM, Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut 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 \
Tom Lane wrote:
> Peter Eisentraut 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 ne
Kevin Grittner wrote:
> Peter Eisentraut 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
On Mon, May 9, 2011 at 1:41 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Peter,
>>
>> > I would like to collect some specs on this feature. So does anyone have
>> > links to documentation of existing implementations, or their own spec
>> > writeup? A lot of people appear to have a very clear
Josh Berkus wrote:
> Peter,
>
> > I would like to collect some specs on this feature. So does anyone have
> > links to documentation of existing implementations, or their own spec
> > writeup? A lot of people appear to have a very clear idea of this
> > concept in their own head, so let's start
On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
> On fre, 2011-04-22 at 08:37 -0500, Merlin Moncure wrote:
>> It wouldn't bother me in the lest that if in plpgsql procedures if you
>> had to set up and tear down a transaction on every line.
>
> It would probably be more reasonable and fea
On Apr 26, 2011, at 6:08 PM, Kevin Grittner wrote:
> Josh Berkus 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
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
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 fac
On Wed, Apr 27, 2011 at 6:48 PM, Josh Berkus 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 ocncurrently o
> 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 com
On Tue, Apr 26, 2011 at 10:12 PM, Greg Stark wrote:
> On Tue, Apr 26, 2011 at 11:55 PM, Josh Berkus 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
On Mon, Apr 25, 2011 at 12:07 PM, 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 t
On Tue, Apr 26, 2011 at 11:55 PM, Josh Berkus 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.
>
> -- doing a bac
Josh Berkus 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 pgsql-hackers ma
Tom Lane 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 duplicate the output pr
> 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 transa
Peter Eisentraut 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 with spec
Peter Eisentraut 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 with spec
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 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
On Mon, Apr 25, 2011 at 2:07 PM, Peter Eisentraut 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 and sto
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 can'
Peter Eisentraut 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 available from
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 sp
On mån, 2011-04-25 at 13:34 -0500, Merlin Moncure wrote:
> hm. does the sql standard prohibit the use of extra transactional
> features?
It doesn't prohibit anything. It just kindly requests that standard
syntax has standard behavior.
> are you sure it's not implied that any sql (including
> STA
On Mon, Apr 25, 2011 at 1:18 PM, Peter Eisentraut 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 and sto
On 04/25/2011 02:18 PM, Peter Eisentraut 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 and stop SQL transactio
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 add a note about th
On Mon, Apr 25, 2011 at 9:18 AM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> Procedures unlike functions however can no longer rely that
>> catalogs remain static visibility wise through execution for
>> functions.
>
> If you start from the perspective that stored procedures are in many
>
Merlin Moncure wrote:
> Procedures unlike functions however can no longer rely that
> catalogs remain static visibility wise through execution for
> functions.
If you start from the perspective that stored procedures are in many
respects more like psql scripts than functions, this shouldn't be
On Fri, Apr 22, 2011 at 11:46 PM, David Christensen wrote:
>
> On Apr 22, 2011, at 3:50 PM, Tom Lane wrote:
>
>> Merlin Moncure writes:
>>> On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
It would probably be more reasonable and feasible to have a setup where
you can end a tra
On 21.04.2011 17:24, Peter Eisentraut wrote:
I would like to collect some specs on this feature. So does anyone have
links to documentation of existing implementations, or their own spec
writeup? A lot of people appear to have a very clear idea of this
concept in their own head, so let's start
On Apr 22, 2011, at 3:50 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
>>> It would probably be more reasonable and feasible to have a setup where
>>> you can end a transaction in plpgsql but a new one would start right
>>> away.
>
>>
Merlin Moncure wrote:
> hm, another neat thing about this is that it skirts the
> unfortunate confusion between sql 'begin' and plpgsql 'begin'...
I hadn't thought about that. There is the SQL-standard START
TRANSACTION synonym, so there is a way to deal with it -- but since
BEGIN seems to be
On Fri, Apr 22, 2011 at 3:50 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
>>> It would probably be more reasonable and feasible to have a setup where
>>> you can end a transaction in plpgsql but a new one would start right
>>> away.
>
>
Merlin Moncure writes:
> On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
>> It would probably be more reasonable and feasible to have a setup where
>> you can end a transaction in plpgsql but a new one would start right
>> away.
> ya, that's an idea.
Yeah, that's a good thought. Then
On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut wrote:
> On fre, 2011-04-22 at 08:37 -0500, Merlin Moncure wrote:
>> It wouldn't bother me in the lest that if in plpgsql procedures if you
>> had to set up and tear down a transaction on every line.
>
> It would probably be more reasonable and fea
On fre, 2011-04-22 at 08:37 -0500, Merlin Moncure wrote:
> It wouldn't bother me in the lest that if in plpgsql procedures if you
> had to set up and tear down a transaction on every line.
It would probably be more reasonable and feasible to have a setup where
you can end a transaction in plpgsql
On 04/22/2011 12:06 PM, Tom Lane wrote:
You could possibly lobotomize plpgsql down to a small number of
datatypes and operators that are known not to ever do anything more
interesting than palloc() and elog(), but IMO the usefulness would be
low and the fragility high. It'd be better to give t
On Fri, Apr 22, 2011 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Apr 22, 2011, at 11:10 AM, Tom Lane wrote:
>>> I'd like a pony, too. Let's be perfectly clear about this: there is no
>>> part of plpgsql that can run outside a transaction today, and probably
>>> no part of the other
Tom,
> >> I'd like a pony, too. Let's be perfectly clear about this: there is
> >> no
> >> part of plpgsql that can run outside a transaction today, and
> >> probably
> >> no part of the other PLs either, and changing that "without major
> >> changes" is wishful thinking of the first order.
I alw
Robert Haas writes:
> On Apr 22, 2011, at 11:10 AM, Tom Lane wrote:
>> I'd like a pony, too. Let's be perfectly clear about this: there is no
>> part of plpgsql that can run outside a transaction today, and probably
>> no part of the other PLs either, and changing that "without major
>> changes"
Robert Haas wrote:
> On Apr 22, 2011, at 11:10 AM, Tom Lane wrote:
>> I'd like a pony, too.
No ponies for me; make mine an Arabian stallion.
>> Let's be perfectly clear about this: there is no part of plpgsql
>> that can run outside a transaction today, and probably no part of
>> the other
On Apr 22, 2011, at 11:10 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Merlin Moncure wrote:
>>> wouldn't it be better if the current crop of language handlers
>>> could run procedures without major changes? C functions with SPI?
>>> However it's internally implemented, the more userland m
On Fri, Apr 22, 2011 at 10:10 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Merlin Moncure wrote:
>>> wouldn't it be better if the current crop of language handlers
>>> could run procedures without major changes? C functions with SPI?
>>> However it's internally implemented, the more userla
"Kevin Grittner" writes:
> Merlin Moncure wrote:
>> wouldn't it be better if the current crop of language handlers
>> could run procedures without major changes? C functions with SPI?
>> However it's internally implemented, the more userland mindspace
>> recovered for use of writing procedures t
Merlin Moncure wrote:
> Tom Lane wrote:
>> You can't have arithmetic, comparisons, or much of anything
>> outside a transaction with plpgsql. That model just plain
>> doesn't work for this purpose, I think. You really want a
>> control language that's independent of the SQL engine, and for
>>
On Fri, Apr 22, 2011 at 9:29 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> It wouldn't bother me in the lest that if in plpgsql procedures if you
>> had to set up and tear down a transaction on every line.
>
> It would once you noticed the performance impact ...
I'm aware of the impact. It wo
Merlin Moncure writes:
> It wouldn't bother me in the lest that if in plpgsql procedures if you
> had to set up and tear down a transaction on every line.
It would once you noticed the performance impact ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
On Thu, Apr 21, 2011 at 5:07 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane wrote:
>>> 3. What sort of primitive operations do you expect the SP to be
>>> able to execute "outside a transaction"? The plpgsql model where
>>> all the primitive operations
On Thu, Apr 21, 2011 at 8:34 PM, Robert Haas wrote:
> On Apr 21, 2011, at 3:51 PM, Merlin Moncure wrote:
>> If you do it that (base it on AT) way, then you can't:
>> 1) call any utility command (vacuum, etc)
>> 2) run for an arbitrary amount of time
>> 3) discard any locks (except advisory)
>> 4)
>> What about cancelling? Cancel the current running query, or the whole
>> procedure (I'm assuming the latter? How would that work?
>
> Good question. If you're imagining that the SP could decide to cancel a
> database request partway through, it seems even further afield from what
> could reaso
On Apr 21, 2011, at 3:51 PM, Merlin Moncure wrote:
> If you do it that (base it on AT) way, then you can't:
> 1) call any utility command (vacuum, etc)
> 2) run for an arbitrary amount of time
> 3) discard any locks (except advisory)
> 4) deal with serialization isolation/mvcc snapshot issues that
Josh Berkus writes:
> On 4/21/11 3:07 PM, Tom Lane wrote:
>> Maybe we should think about the SP controlling a second backend (or even
>> multiple backends?) that's executing the "transactional" operations.
>> dblink on steroids, as it were.
> This is how people are doing this now (using dblink I
On 4/21/11 3:07 PM, Tom Lane wrote:
> Maybe we should think about the SP controlling a second backend (or even
> multiple backends?) that's executing the "transactional" operations.
> dblink on steroids, as it were.
This is how people are doing this now (using dblink I mean).
--
Josh Berkus
Post
> Robert Haas writes:
>> EDB has an implementation of this in Advanced Server. A stored
>> procedure can issue a COMMIT, which commits the current transaction
>> and begins a new one. This might or might not be what people are
>> imagining for this feature. If we end up doing something else, on
Merlin Moncure writes:
> On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane wrote:
>> 3. What sort of primitive operations do you expect the SP to be
>> able to execute "outside a transaction"? The plpgsql model where
>> all the primitive operations are really SQL ain't gonna work.
> Does this mean you
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 this feature. So does anyone have
l
On Thu, Apr 21, 2011 at 3:51 PM, Merlin Moncure wrote:
> On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas wrote:
>> On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote:
>>> "Kevin Grittner" writes:
Josh Berkus wrote:
> ** question: if an SP is called by another SP, what is its
> transacti
On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas wrote:
> On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Josh Berkus wrote:
** question: if an SP is called by another SP, what is its
transaction context?
>>
>>> Entering or leaving an SP should not start o
On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Josh Berkus wrote:
>>> ** question: if an SP is called by another SP, what is its
>>> transaction context?
>
>> Entering or leaving an SP should not start or end a transaction.
>
> That all sounds mighty hand-wavy and
2011/4/21 Tom Lane :
> "Kevin Grittner" writes:
>> Josh Berkus wrote:
>>> ** question: if an SP is called by another SP, what is its
>>> transaction context?
>
>> Entering or leaving an SP should not start or end a transaction.
>
> That all sounds mighty hand-wavy and at serious risk of tripping
On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane wrote:
> 3. What sort of primitive operations do you expect the SP to be
> able to execute "outside a transaction"? The plpgsql model where
> all the primitive operations are really SQL ain't gonna work.
> I'm less sure what to do about #3. The most attr
"Kevin Grittner" writes:
> Josh Berkus wrote:
>> ** question: if an SP is called by another SP, what is its
>> transaction context?
> Entering or leaving an SP should not start or end a transaction.
That all sounds mighty hand-wavy and at serious risk of tripping over
implementation details.
I'm pretty close to agreement with Josh, I think.
Josh Berkus wrote:
> Delta between SPs and Functions for PostgreSQL:
>
> * SPs are executed using CALL or EXECUTE, and not SELECT.
Agreed, although some products will search for a matching procedure
name if the start of a statement doesn't ma
Hello
2011/4/21 Josh Berkus :
> Peter,
>
>> I would like to collect some specs on this feature. So does anyone have
>> links to documentation of existing implementations, or their own spec
>> writeup? A lot of people appear to have a very clear idea of this
>> concept in their own head, so let's
Peter,
> I would like to collect some specs on this feature. So does anyone have
> links to documentation of existing implementations, or their own spec
> writeup? A lot of people appear to have a very clear idea of this
> concept in their own head, so let's start collecting those.
Delta betwee
On Thu, Apr 21, 2011 at 12:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> EDB has an implementation of this in Advanced Server. A stored
>> procedure can issue a COMMIT, which commits the current transaction
>> and begins a new one. This might or might not be what people are
>> imagining for t
Robert Haas writes:
> EDB has an implementation of this in Advanced Server. A stored
> procedure can issue a COMMIT, which commits the current transaction
> and begins a new one. This might or might not be what people are
> imagining for this feature. If we end up doing something else, one
> th
On Thu, Apr 21, 2011 at 11:24 AM, 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 spe
Hi Peter
2011/4/21 Peter Eisentraut :
> 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 this feature.
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 this feature. So does anyone have
links to documentation of e
Hello Josh,
the XML and XLST are data presentation only?
the idea is provide some like one Http request where I can post data for a
Stored procedure and receive one Http response using WSDL description and
SOAP transport to implement the web service.
Where can I find more info about this new fe
Hey, Ivo,
> I' m work on a software to create automatic webservices for stored
> procedure in any language.
Seems like the new XML and XLST support should fit in here somewhere.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
Hi everybody,
I' m work on a software to create automatic webservices for stored
procedure in any language.
It's almost like the explain above:
have one table pg_plwebservice
Have one sp hello, develope in any languages like sql, plpgsql(trusted or
untrusted)like for example.
The DBA chec
Suresh Tri wrote:
Hi all,
I am currently trying to estimate the effort required
to implement Oracle type stored procedure in
PostgreSQL. As I understood Oracle supports both
functions and procedures, but postgres only functions.
ALso there are no OUT parameter in postgres.
I got some info from
htt
Hi all,
I am currently trying to estimate the effort required
to implement Oracle type stored procedure in
PostgreSQL. As I understood Oracle supports both
functions and procedures, but postgres only functions.
ALso there are no OUT parameter in postgres.
I got some info from
http://www.compiere.
91 matches
Mail list logo
