2009/11/18 Konstantin Izmailov :
> Ok, I accept reasoning that DB agnostic development is propbably a bad idea.
>
> The question should probably be re-introduced as "Stored Procedures against
> multiple statements in Postgres".
>
> Here is my client opinion:
> "SP’s have their place, as with any de
Ok, I accept reasoning that DB agnostic development is propbably a bad idea.
The question should probably be re-introduced as "Stored Procedures against
multiple statements in Postgres".
Here is my client opinion:
"SP’s have their place, as with any development, there’s many reasons for
and again
Konstantin Izmailov wrote:
> Some companies have policy to stay DB agnostic, i.e. use standard SQL only.
Good luck with that. For example, querying the lastval of a sequence, as your
sample code does, already falls outside of standard SQL, AFAIK.
> If PQexecParams does not support multip
Konstantin Izmailov, 17.11.2009 17:33:
This is why they want to use multiple statements
Which is not portable as well.
Actually the only database I know which permits sending more than one statement in
"one string" is SQL Server...
Thomas
--
Sent via pgsql-general mailing list (pgsql-gener
2009/11/18 Ivan Sergio Borgonovo :
> On Wed, 18 Nov 2009 11:38:46 +0100
> Pavel Stehule wrote:
>
>> 2009/11/18 Ivan Sergio Borgonovo :
>> > On Tue, 17 Nov 2009 20:16:36 -0800
>> > David Fetter wrote:
>> >
>> >> On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov
>> >> wrote:
>> >> > Som
On Wed, 18 Nov 2009 11:38:46 +0100
Pavel Stehule wrote:
> 2009/11/18 Ivan Sergio Borgonovo :
> > On Tue, 17 Nov 2009 20:16:36 -0800
> > David Fetter wrote:
> >
> >> On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov
> >> wrote:
> >> > Some companies have policy to stay DB agnostic, i.
2009/11/18 Ivan Sergio Borgonovo :
> On Tue, 17 Nov 2009 20:16:36 -0800
> David Fetter wrote:
>
>> On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov
>> wrote:
>> > Some companies have policy to stay DB agnostic, i.e. use standard
>> > SQL only.
>
>> That's called shooting yourself in t
On Tue, 17 Nov 2009 20:16:36 -0800
David Fetter wrote:
> On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov
> wrote:
> > Some companies have policy to stay DB agnostic, i.e. use standard
> > SQL only.
> That's called shooting yourself in the head.
I'm a small fish. I use just Free so
On Tue, Nov 17, 2009 at 09:33:05AM -0700, Konstantin Izmailov wrote:
> Some companies have policy to stay DB agnostic, i.e. use standard
> SQL only.
That's called shooting yourself in the head.
Unless you have a very, very specific, business-critical reason to pay
this huge cost, you should never
Some companies have policy to stay DB agnostic, i.e. use standard SQL only.
This is why they want to use multiple statements, not stored procedures.
I'm not familiar with RETURNING. Is this SQL standard? Can it be used for
inserting a row and returning back primary key for the inserted row in one
Konstantin Izmailov wrote:
> I'm planning to use multiple statements via libpq. Before starting coding
> I'm trying to understand are there any limitations on passing parameters.
> E.g. would the following work:
> PQexecParams(conn, "BEGIN;INSERT INTO tbl VALUES($1,$2);SELECT
> lastval()
Hello
2009/11/16 Konstantin Izmailov :
> I'm planning to use multiple statements via libpq. Before starting coding
> I'm trying to understand are there any limitations on passing parameters.
> E.g. would the following work:
> PQexecParams(conn, "BEGIN;INSERT INTO tbl VALUES($1,$2);SELECT
> lastv
I'm planning to use multiple statements via libpq. Before starting coding
I'm trying to understand are there any limitations on passing parameters.
E.g. would the following work:
PQexecParams(conn, "BEGIN;INSERT INTO tbl VALUES($1,$2);SELECT
lastval();SELECT * INTO AUDIT FROM (SELECT $3, 'tbl act
13 matches
Mail list logo
