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!
---
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
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 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 I
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 anyth
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;
>
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 w
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
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 capitalizat
> -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, 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 tha
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-containe
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 ParameterDesc
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 o
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 f
-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 single-lan
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
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
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 to
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 inf
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 .
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:
> 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 Ex
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 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
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 jdbc/
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
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,
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 Oi
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 *paramT
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,
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 sayi
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 'unknown'
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 t
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 modifi
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 broad
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'
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=
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 th
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
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
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 a
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.
W
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 lib
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:
> 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
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
"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
> -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
iginal 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] lib
> -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
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 wro
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
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" a
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 get
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 inefficien
> -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 f
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 wh
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 seem
"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.
> -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
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
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
> libp
"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
> 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
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.
Real
> > 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 s
> 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
69 matches
Mail list logo
