On Oct 14, 2004, at 6:50 PM, Abhijit Menon-Sen wrote:
I thought about that for a while, but I couldn't find anything that is
actually broken or confused by the patch. I could be missing something
obvious, though, so I'd appreciate another set of eyes looking at it.
Does anyone have any ideas?
Not
It was just added to CVS!
---
David Wheeler wrote:
On Oct 14, 2004, at 6:50 PM, Abhijit Menon-Sen wrote:
I thought about that for a while, but I couldn't find anything that is
actually broken or confused by the
On Oct 18, 2004, at 3:12 PM, Bruce Momjian wrote:
It was just added to CVS!
Awesome!
Abhijit++
Bruce++
Tom++
Regards,
David
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Mon, Oct 18, 2004 at 06:12:29PM -0400, Bruce Momjian wrote:
It was just added to CVS!
Woohooo!
Big, BIG kudos to all involved :) :)
Cheers,
D(BD::Pg)
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Dann Corbit wrote:
Create a 64 bit hash (e.g. UMAC) of the prepared statement (removing
hardwired parameters as needed so that SELECT Col1, col2 FROM
Some_Table
where FOO = 'BAR' becomes SELECT COL1, COL2 FROM SOME_TABLE WHERE
FOO =
?, form consistent capitalization of the statement by
(I apologise for the delayed response.)
At 2004-10-07 01:23:56 -0400, [EMAIL PROTECTED] wrote:
So why is this part of the patch ok? Isn't it going to make libpq get
confused every time a PQExecPrepared sends a v3.0 prepare message?
I thought about that for a while, but I couldn't find
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
--- fe-protocol3.c.1~ 2004-10-05 18:59:55.293092244 +0530
+++ fe-protocol3.c2004-10-05 19:17:48.154807848 +0530
@@ -220,6 +220,11 @@ pqParseInput3(PGconn *conn)
conn-asyncStatus = PGASYNC_READY;
On Oct 5, 2004, at 9:59 AM, Abhijit Menon-Sen wrote:
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained way.
Also attached is a test program à la testlibpq3.c that I used to test
the change. This should be all
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Wheeler
Sent: Tuesday, October 05, 2004 10:32 AM
To: Abhijit Menon-Sen
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
On Oct 5, 2004, at 9:59 AM
On Oct 5, 2004, at 10:47 AM, Dann Corbit wrote:
Create a 64 bit hash (e.g. UMAC) of the prepared statement (removing
hardwired parameters as needed so that SELECT Col1, col2 FROM
Some_Table where FOO = 'BAR' becomes SELECT COL1, COL2 FROM
SOME_TABLE WHERE FOO = ?, form consistent capitalization
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained way.
Any thoughts? Does this look good enough for 8.0?
Seems OK as far as it goes, but a complete patch would
At 2004-10-05 17:48:27 -0400, [EMAIL PROTECTED] wrote:
Searching for all references to one of the existing entry points such
as PQexecPrepared will probably help you identify what you need to do.
OK. I've attached two additional patches below.
I don't really understand how the *.def files
At 2004-09-20 13:24:47 -0400, [EMAIL PROTECTED] wrote:
It depends on whether you think that PQprepare should bundle the
Describe Statement operation or not.
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
Personally I find it annoying that you can't call describe on a
statement, only a portal, but that's the way it is now.
No, it isn't. Describe accepts both prepared statement and portal names.
In the former case, it returns
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
David Wheeler [EMAIL PROTECTED] writes:
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
Harald Fuchs wrote:
The first problem with this approach is that it requires libpq to be all
things to all people. We've already had some discussion in this thread
about the tension between supporting application programs written in C,
which want one set of features, and drivers, which need some
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
That means you also need to add a new Execute method that takes a
portalName instead of a command.
Oh, it occurs to me I missed a step in my earlier logic. I assumed we would
want a separate
There was some previous discussion of whether DBD:pg should continue
using libpq or implement the wire protocol in Perl, and whether ODBC
should move to using libpq.
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
I assumed we would want a separate Bind and execute call. Do we?
Yes, we do. (See below.)
Personally I find it annoying
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
I assumed we would want a separate Bind and execute call. Do we?
I
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
Execute can be told to return no more than n rows of results. If there
are more rows available, the server returns PortalSuspended and awaits
another Execute message. The default of 0 imposes no limit.
Because it's sometimes required to call Execute
At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote:
What you should be concerned with right now is providing an API for
Parse + Describe Statement, to substitute for the existing approach
of setting up statement objects via PQexec(PREPARE foo ...).
Fair enough. That's why my original
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes);
Should I go ahead and do that?
(1) What about preparing an unnamed statement ... will you
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
(1) What about preparing an unnamed statement ...
stmtName == will work.
(2) What about discovering the actually resolved parameter types?
I'm not sure what to do about that.
I could extend PGresult to hold ParameterDescription
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I think having all interfaces take advantage of libpq improvements and
features is a major win. If we need
David Wheeler [EMAIL PROTECTED] writes:
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I don't normally post me too posts, but I think that what Bruce
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
(2) What about discovering the actually resolved parameter types?
Do you have any suggestions?
It depends on whether you think that PQprepare should bundle the
Describe Statement operation or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another point is that since the ODBC driver is C anyway, there are no
cross-language issues for it in relying on libpq. This is quite
different IMHO from the situation for JDBC, or DBD::Pg, where there are
advantages in having a
At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote:
Assuming that anyone steps up and does the work, that is.
So...any volunteers?
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
On Sep 19, 2004, at 9:13 PM, Abhijit Menon-Sen wrote:
OK, how about adding a PQprepare (PQcreatePrepared?) function like
this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
That means you also need to add a new Execute method that takes a
portalName instead of a command.
Yes, thanks. How about these functions, then?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
On Wed, 15 Sep 2004 13:50:43 -0400, [EMAIL PROTECTED] (Tom Lane)
wrote:
Well, (a) I ran out of time, and (b) I wasn't sure what the most
convenient API would be. Should we create something that packages
together a Parse and a Describe Statement, or expose those as
separate things?
There's
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1= prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1= execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Regards,
David
---(end of
David Wheeler wrote:
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1= prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1= execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Well, obviously. I haven't
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the 'unknown' case to make use of
David Wheeler wrote:
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the
Oliver Jowett [EMAIL PROTECTED] writes:
Tom reckons that PREPARE (at the SQL level) taking unknown types is not
useful as there is no feedback mechanism along the lines of the V3
protocol Describe messages to let the client find out what types were
inferred by the PREPARE.
I am saying
The odbc driver must be doing the same thing, as well I suspect pgadmin
has a protocol stack built into it as well?
There is a jdbc driver for postgresql on sourceforge that does use
libpq. The fact that it is not widely used should be educational.
Dave
On Thu, 2004-09-16 at 01:11, Greg Stark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Cramer
Sent: 17 September 2004 14:32
To: Greg Stark
Cc: Oliver Jowett; Tom Lane; Merlin Moncure;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Cramer
Sent: 17 September 2004 14:32
To: Greg Stark
Cc: Oliver Jowett; Tom Lane; Merlin Moncure;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
The odbc driver must
-Original Message-
From: Dave Cramer [mailto:[EMAIL PROTECTED]
Sent: 17 September 2004 14:52
To: Dave Page
Cc: Greg Stark; Oliver Jowett; Tom Lane; Merlin Moncure;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
Interesting,
I'd
Dave Page [EMAIL PROTECTED] writes:
From: Dave Cramer [mailto:[EMAIL PROTECTED]
I'd like to know more about the issues you are trying to
solve? Seems counter productive for all of us to attempt this
independently
Mainly lack of time :-)
SSL and v3+ protocol support are the primary
On Wed, 15 Sep 2004 13:50:43 -0400, Tom Lane wrote:
The describe statement part could be much trickier but DBD::Pg
doesn't really
need that for basic functionality.
Doesn't it? I thought the problem was that they couldn't find out what
datatypes the parameters got resolved as. That may not
David Wheeler [EMAIL PROTECTED] writes:
To get initial PREPARE support, I don't think that the other DBD::Pg
developers mind sending strings to the PostgreSQL server in a SQL
PREPARE statement.
The question, in my mind, is it currently possible to do this without
specifying the type of
On Sep 17, 2004, at 1:32 PM, Tom Lane wrote:
Well, that's the problem: you can't. The SQL PREPARE command doesn't
have any provision for dealing with unspecified parameters. I think
this is reasonable since if it could, it would still have no way to
tell
you what it resolved the parameter types
David Wheeler [EMAIL PROTECTED] writes:
if I understand a previous post from you, this functionality should be
added to libpq, but you haven't had time and aren't sure what the API
should look like, anyway, is that correct?
Right. Proposals welcome.
Is this the task labeled llow libpq to
On Sep 17, 2004, at 1:54 PM, Tom Lane wrote:
David Wheeler [EMAIL PROTECTED] writes:
if I understand a previous post from you, this functionality should be
added to libpq, but you haven't had time and aren't sure what the API
should look like, anyway, is that correct?
Right. Proposals welcome.
David Wheeler [EMAIL PROTECTED] writes:
Is this the task labeled allow libpq to check parameterized data
types here?:
http://candle.pha.pa.us/cgi-bin/pgopenitems
I think that was something else, but memory is fuzzy.
I'm less sure, since I was the one who asked Jan Wieck about this at
On Sep 17, 2004, at 2:21 PM, Tom Lane wrote:
Okay, here we have Bruce saying he'll add it to open items:
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00147.php
so I guess it is the same thing. Good, that will give us some
political
cover for squeezing it into 8.0 ;-).
Ah, okay, so Jan
Tom Lane wrote:
David Wheeler [EMAIL PROTECTED] writes:
if I understand a previous post from you, this functionality should be
added to libpq, but you haven't had time and aren't sure what the API
should look like, anyway, is that correct?
Right. Proposals welcome.
Is this the
Tom Lane wrote:
David Wheeler [EMAIL PROTECTED] writes:
To get initial PREPARE support, I don't think that the other DBD::Pg
developers mind sending strings to the PostgreSQL server in a SQL
PREPARE statement.
The question, in my mind, is it currently possible to do this without
specifying the
Oliver Jowett wrote:
template1= prepare s1(int) as select $1;
PREPARE
template1= execute s1('12');
?column?
--
12
(1 row)
(now replace int with unknown..)
Ok, bad example since the backend probably can't infer a type for the
PREPARE in this case. A better example:
template1=
A bit of context here. The perl DBD::Pg developers are trying to
figure
out
how to implement prepared queries sanely. As it stands now they're
basically
writing off both binary prepared queries and SQL based prepared
queries as
basically useless. It would be a shame to have a brand new
Merlin Moncure [EMAIL PROTECTED] writes:
Question: what is the relevance of the binary protocol, are you trying
to send/fetch binary data via the command interface?
My understanding of the original post is that DBD::Pg is sitting atop
libpq and wants to keep doing so. So they're going to need
Tom Lane [EMAIL PROTECTED] writes:
Merlin Moncure [EMAIL PROTECTED] writes:
Question: what is the relevance of the binary protocol, are you trying
to send/fetch binary data via the command interface?
My understanding of the original post is that DBD::Pg is sitting atop
libpq and wants
Greg Stark [EMAIL PROTECTED] writes:
Is there anything technically hard in adding this functionality to libpq? It
looks like it's just mechanically adding more entry points to existing code.
Well, (a) I ran out of time, and (b) I wasn't sure what the most
convenient API would be. Should we
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Wednesday, September 15, 2004 10:51 AM
To: Greg Stark
Cc: Merlin Moncure; [EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
Greg Stark [EMAIL
Dann Corbit [EMAIL PROTECTED] writes:
What about using ECPG as an interface for drivers?
What for? It's not a substitute for libpq --- it sits on top of libpq,
or did last I checked anyway. And it's designed around a preprocessor
that seems fairly useless for a driver.
Tom Lane [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] writes:
What about using ECPG as an interface for drivers?
What for? It's not a substitute for libpq --- it sits on top of libpq,
or did last I checked anyway. And it's designed around a preprocessor
that seems fairly
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Is there anything technically hard in adding this functionality to libpq? It
looks like it's just mechanically adding more entry points to existing code.
Well, (a) I ran out of time, and (b) I wasn't sure what the
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 11:34 AM
To: Tom Lane
Cc: Dann Corbit; Greg Stark; Merlin Moncure;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
Tom Lane
Greg Stark wrote:
I was pretty shocked when I heard that JDBC implements the low level protocol
itself. It seems like a dead-end strategy to me. Any new protocol innovations
need to be implemented in every driver. Every implementation gets the chance
to reimplement the same bugs and same
Oliver Jowett [EMAIL PROTECTED] writes:
Greg Stark wrote:
I was pretty shocked when I heard that JDBC implements the low level protocol
itself. It seems like a dead-end strategy to me. Any new protocol innovations
need to be implemented in every driver. Every implementation gets the
Greg Stark wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
There *are* benefits to implementing the protocol directly. First on my
personal list is that our Java application would not be able to use postgresql
at all if the driver required JNI/libpq.
Well benefits that boil down to Java sucks
Oliver Jowett [EMAIL PROTECTED] writes:
Well benefits that boil down to Java sucks aren't very convincing. Perl
suffers from no such handicap.
Arguing that Java-specific benefits are not convincing benefits for a JDBC
driver because you don't get them in Perl seems a bit odd to me.
Anyone working on the libpq interface to prepared statements?
We could really use that for DBD::Pg. Alternatively, if someone
knows a trick to prepare an INSERT statement without knowing
the data types, that would be neat too. For example:
CREATE TABLE foobar(a INTEGER);
These don't
PREPARE st(unknown) AS INSERT INTO foobar(a) VALUES ($1);
Using PQExecParams is completely out of the question? How are you
executing your statements...PQExec?
A bit of context here. The perl DBD::Pg developers are trying to figure out
how to implement prepared queries sanely. As it
Greg Stark [EMAIL PROTECTED] writes:
A bit of context here. The perl DBD::Pg developers are trying to figure out
how to implement prepared queries sanely. As it stands now they're basically
writing off both binary prepared queries and SQL based prepared queries as
basically useless.
Really?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone working on the libpq interface to prepared statements?
We could really use that for DBD::Pg. Alternatively, if someone
knows a trick to prepare an INSERT statement without knowing
the data types, that would be neat too. For example:
70 matches
Mail list logo
