Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
Shoot! Feels like you always miss something.
The patch uses
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide a function to get
Gregory Stark wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide
Andrew Chernow [EMAIL PROTECTED] writes:
How would the caller of getvalues know whether the error was generated by a
libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
behave exactely as PQgetvalue does, in regards to errors.
Hm. Well I was thinking of errors from
On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
How would the caller of getvalues know whether the error was generated by a
libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
behave exactely as
Andrew Chernow wrote:
/* Only for results returned by PQresultDup. This
* will append a new tuple to res. A PGresAttValue
* is allocated and put at index 'res-ntups'. This
* is similar to pqAddTuple except that the tuples
* table has been pre-allocated. In our case, ntups
* and
Andrew Chernow [EMAIL PROTECTED] writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's internals ---
in
Andrew Chernow [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Surely you would just provide a function to get pqtypes errors separate from
libpq errors?
That's extremely akward. Consider the below.
I'm just as suspicious of this as Greg is. In particular, I really
disagree with PQgetf
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's
Tom Lane wrote:
PQresultErrorMessage at this point --- if you haven't already
checked the PGresult to be okay, you should certainly not be
trying to extract fields from it. So I don't see that you
are saving any steps here.
Correct, I agree. Our thinking was flawed. The issue we face is
Andrew Chernow [EMAIL PROTECTED] writes:
PGresult *PQresultDup(
PGconn *conn,
PGresult *res,
int ntups,
int numAttributes,
PGresAttDesc *attDescs);
I don't understand why this is a dup operation. How can you dup
if you are specifying a new tuple descriptor? I'd have
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
PGresult *PQresultDup(
PGconn *conn,
PGresult *res,
int ntups,
int numAttributes,
PGresAttDesc *attDescs);
I don't understand why this is a dup operation. How can you dup
if you are specifying a new tuple descriptor?
Andrew Chernow wrote:
For client_encoding and noticeHooks, the conn can be NULL. Previously,
we copied this info from the source result when conn was NULL.
Looks like we don't need client_encoding. My guess is, in our use case
noticeHooks can probably be NULL for the created result,
Andrew Chernow wrote:
res = paramexec(conn, param, ...
if(!res)
// check pgconn or pgparam?
// can conn have an old error (false-pos)
We will just always dump the error message into the param. If
PQexecParams fails with a NULL result, we will copy PQerrorMessage over
to param-errMsg.
Jeff Davis [EMAIL PROTECTED] writes:
* Binary formatting
The exclusive use of binary formats is worrisome to me. This circumvents
one level of indirection that we have (i.e. that everything moves
through in/out functions), and will impose a backwards-compatibility
requirement on the
On Wed, Apr 9, 2008 at 6:13 AM, Gregory Stark [EMAIL PROTECTED] wrote:
The exclusive use of binary formats is worrisome to me. This circumvents
one level of indirection that we have (i.e. that everything moves
through in/out functions), and will impose a backwards-compatibility
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return 'void'. So, at
present, to use PQgetf, you result set must be binary.
I'm surprised you
On Wed, Apr 9, 2008 at 8:04 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
\ Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return 'void'. So, at
Andrew Dunstan wrote:
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
I'm surprised you didn't try to address that limitation.
That would change the existing behavior of resultFormat,
Andrew Chernow wrote:
Andrew Dunstan wrote:
Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
I'm surprised you didn't try to address that limitation.
That would change the existing
Merlin Moncure wrote:
On Wed, Apr 9, 2008 at 8:04 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
\ Merlin Moncure wrote:
However, due to libpq limitations, if any datatype must
return text the entire result must be text (resultFormat)...this is
also interestingly true for functions that return
On Tue, Apr 08, 2008 at 07:18:31PM -0400, Tom Lane wrote:
sure that there's much potential commonality. The thing that's most
problematic about ecpg is that it wants to offer client-side equivalents
of some server datatype-manipulation functions; and I don't actually see
much of any of that
Andrew Chernow wrote:
Yeah, currently composites and arrays only support binary results in
libpqtypes. This forces any array elementType or any member of a
composite to have a send/recv routine. Using the fallback to text
output approach, this limitation on array elements and composite
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually don't
need very much in libpq. Although, making it somehow generic enough
to be useful to other extensions is a bit tricky. Please, suggestions
would be helpful.
Quick question on the hook concept
Andrew Chernow wrote:
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually
don't need very much in libpq. Although, making it somehow generic
enough to be useful to other extensions is a bit tricky. Please,
suggestions would be helpful.
Quick
Andrew Chernow wrote:
Andrew Chernow wrote:
Well, I can get it working with a very small patch. We actually
don't need very much in libpq. Although, making it somehow generic
enough to be useful to other extensions is a bit tricky. Please,
suggestions would be helpful.
Quick
Andrew Chernow wrote:
The core of what I am trying to ask is, there doesn't appear to be an
advantage to separating libpqtypes from libpq in terms of space. If
redhat follows their normal policy of include all (probably to make
their distro as feature rich out-of-the-box as possible),
Andrew Dunstan wrote:
I don't get what you're not seeing about this.
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
I am still not convinced there is merit to a separate library. But
Andrew Chernow [EMAIL PROTECTED] writes:
There is no need to pass hookData to the hook function. libpqtypes already
accesses PGconn and PGresult directly so it can just access the hookData
member.
That's a habit you'd really be best advised to stop, if you're going to
be a separate library.
Andrew Chernow wrote:
Andrew Dunstan wrote:
I don't get what you're not seeing about this.
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
There are plenty of modules that they don't
Andrew Dunstan wrote:
All I am trying to say is, redhat's core packages are normally very
inclusive. Like apache, which includes many/most modules in the core
package.
There are plenty of modules that they don't include, e.g. mod_fastcgi.
If you want that you download and build it
Bruce Momjian wrote:
I think Andrew Chernow is fundamentally confused about dynamic linking,
which apache has to use because it doesn't know what type of file it has
to handle, with linking, which is bound to the application code.
pgtypes is bound to the application code so it is not like
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
There is no need to pass hookData to the hook function. libpqtypes already
accesses PGconn and PGresult directly so it can just access the hookData member.
That's a habit you'd really be best advised to stop, if you're going to
be a
Andrew Chernow wrote:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
result:
null_field
tupArrSize
client_encoding (need a PGconn for this which might be dead)
pqSetResultError
pqResultAlloc
pqResultStrdup
Also, we
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Chernow wrote:
The core of what I am trying to ask is, there doesn't appear to be an
advantage to separating libpqtypes from libpq in terms of space.
My guess is that if we provide an useful library, Redhat will distribute
it some way or
On Wed, Apr 9, 2008 at 11:17 AM, Andrew Chernow [EMAIL PROTECTED] wrote:
We can read args-get.result properties using PQfuncs with no problem. But
we have no way of assign these values to our result 'r'.
By the way, our decision to 'create the result' when exposing arrays
and composites saved
Tom Lane wrote:
The key phrase in that being some way or another. Red Hat works with
a concept of core vs extras (or another way to look at it being what
comes on the CDs vs what you have to download from someplace). I think
it's highly likely that libpgtypes would end up in extras. If you
Andrew Chernow [EMAIL PROTECTED] writes:
If you are suggesting that libpqtypes should not access internal libpq,
than this idea won't work. We can pull all the code out and hook in, as
you suggested, but we had no plans of abstracting from internal libpq.
That's exactly what I'm strongly
On Tue, 2008-04-08 at 21:49 -0400, Merlin Moncure wrote:
* an escapeIdent function.
not sure what this is...
Similar to the quote_ident() function in postgresql:
= select quote_ident('foo');
quote_ident
-
foo
(1 row)
It could be called something like PQquoteIdent or
Tom Lane wrote:
That's exactly what I'm strongly suggesting. If you need to include
libpq-int.h at all, then your library will be forever fragile, and could
very well end up classified as don't ship this at all, it's too likely
to break.
regards, tom lane
I see
Andrew Chernow [EMAIL PROTECTED] writes:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
Also, we basically need write access to every member inside a result
object ...
Tom Lane wrote:
Hmm. I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API. We haven't changed it
often, and it's hard to imagine a change that wouldn't be associated
with a major-version change anyhow. We could do some things to make
Tom Lane wrote:
But I'll agree that cross-version hazards are a much more clear and
present danger. We've already broken binary compatibility at least
once since the current binary-I/O system was instituted (intervals
now have three fields not two) and there are obvious candidates for
future
Florian Pflug [EMAIL PROTECTED] writes:
But isn't that an argument *for* having support for the binary format in
libpq in a form similar to what this patch offers? Then at least you'd
be safe as long as your libpq-version is = your server version.
Currently, there seems to be no safe way to
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm. I guess it wouldn't be completely out of the question to expose
the contents of PGresult as part of libpq's API.
How about a proxy header (if such an animal exists).
A separate header might be a good idea to discourage
Tom Lane wrote:
Perhaps we could do a partial exposure, where the exported struct
declaration contains public fields and there are some private ones
after that.
I have another idea. It would remove a boat load of members that would need to
be exposed (may remove them all).
Can we
Andrew Chernow wrote:
Tom Lane wrote:
Perhaps we could do a partial exposure, where the exported struct
declaration contains public fields and there are some private ones
after that.
I have another idea. It would remove a boat load of members that would
need to be exposed (may remove
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I recommend you place it on pgfoundry and see if you
can get a
Bruce Momjian wrote:
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I recommend you place it on pgfoundry
Andrew Dunstan wrote:
Bruce Momjian wrote:
I know there has been lots of versions and technical feedback related to
this proposed feature. However, I have talked to Tom and neither of us
see sufficient user request for this capability to add this code into
the core server. I
Andrew Dunstan [EMAIL PROTECTED] writes:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
Well, the survey's already been taken, pretty much:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state that there would be almost
On Tue, Apr 8, 2008 at 12:59 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Sorry for the bad news. I think we all hoped that enough interest would
be generated for this to be accepted.
I think that's really unfortunate. Personally, I think that anyone
who did any amount of C coding against
On Tue, Apr 8, 2008 at 1:51 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state
Merlin Moncure escribió:
I attributed the silence to general lack of interest and anticipated
this response. However I think that those involved should step back
and take a look at what they are walking away from here.
I suggest you take a survey on a more widely read forum, like
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I can state
Merlin Moncure [EMAIL PROTECTED] writes:
On Tue, Apr 8, 2008 at 1:51 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
I can state that there would be almost zero chance this would ever be
used by DBD::Pg, as it would seem to add overhead with no additional
functionality over what we already
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte added is a byte maintained (or not).
Joshua D. Drake
--
The
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
I could see adding four functions to libpq that create and
On Tue, Apr 8, 2008 at 2:49 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
regards, tom lane
What
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte added is a byte
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 08 Apr 2008 14:34:51 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
I am not sure why Tom is worried about source code size, normally the
concern is linked size. Code comments were never finished, as the
Every byte
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a number of other decisions that they don't necessarily
want.
What decisions
On Tue, Apr 8, 2008 at 3:10 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Actually I was thinking more about disk footprint. Andrew's comment is
correct if you work with statically linked code where the compiler pulls
out only the needed .o files from a .a library, but that's pretty out of
Merlin Moncure wrote:
I attributed the silence to general lack of interest and anticipated
this response. However I think that those involved should step back
and take a look at what they are walking away from here.
Agreed. There are technical issues, but they can be addressed with
work. The
On Tue, Apr 8, 2008 at 3:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Better support for arrays and composites is certainly something that
people might want, but the problem with this design is that it forces
them to buy into a
On Tue, Apr 08, 2008 at 02:34:51PM -0400, Andrew Chernow wrote:
This idea is for the libpq user, although driver writers could find it
handy as well. Really, anyone who uses libpq directly. That's the real
audience.
Quite, I'm writing array parsing code right now and this would make my
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Tue, Apr 08, 2008 at 02:34:51PM -0400, Andrew Chernow wrote:
This idea is for the libpq user, although driver writers could find it
handy as well. Really, anyone who uses libpq directly. That's the real
audience.
Quite,
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
Add
Andrew Chernow wrote:
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
I gave this a lot of thought and I do think we could abstract this. The
idea is to
Merlin Moncure [EMAIL PROTECTED] writes:
Actually I was thinking more about disk footprint. Andrew's comment is
correct if you work with statically linked code where the compiler pulls
out only the needed .o files from a .a library, but that's pretty out of
fashion these days. Most people
Andrew Chernow [EMAIL PROTECTED] writes:
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
[shrug...] So the packagers will compile it out, and you're still hosed,
or at least any users who'd like to use it are.
Forgot to say: There is
Bruce Momjian wrote:
Martijn van Oosterhout wrote:
How tight is the link to libpq? Could it exist as a seperate library:
libpqbin or something? Still in core, just only used by the people who
want it.
The idea of pgfoundry was that it would be an independent library and
could be used
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I gave this a lot of thought and I do think we could abstract this. The
idea is to complie it in or out.
[shrug...] So the packagers will compile it out, and you're still hosed,
or at least any users who'd like to use it are.
Forgot
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
or some such, and it gets picked
Alvaro Herrera wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
or some
Andrew Chernow wrote:
Alvaro Herrera wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear,
PQfinish (maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks. So libpqtypes registers its
Andrew Dunstan wrote:
Please make sure that any scheme you have along these lines will work on
Windows DLLs too.
Ofcourse: LoadLibrary(), GetProcAddress(), __declspec(dllexport).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list
On Tue, Apr 8, 2008 at 6:09 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Andrew Chernow wrote:
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
Maybe there's a way we can have libpqtypes adding calls into some
hypothetical libpq hooks.
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The idea of pgfoundry was that it would be an independent library and
could be used by people who need it.
I don't think phasing it out to pgfoundry is a good idea, because it has
some dependency on the OIDs of datatypes.
Well,
Andrew Chernow [EMAIL PROTECTED] writes:
Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
but very little. I was thinking PQtypesEnable(bool) which would dlopen
libpqtypes and map all functions needed. This would leave the function
bodies
of PQputf, PQgetf,
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
but very little. I was thinking PQtypesEnable(bool) which would dlopen
libpqtypes and map all functions needed. This would leave the function bodies
of
Tom Lane wrote:
This is still 100% backwards. My idea of a libpq hook is something that
could be used by libpgtypes *and other things*. What you are proposing
is something where the entire API of the supposed add-on is hard-wired
into libpq. That's just bad design, especially when the
Andrew Chernow wrote:
My idea was not a response to your hook idea. It was different
altogether.
My idea is trying to create one interface where some parts need to be
enabled (nothing wrong with that design, this is a plugin-like model).
Your idea creates two interfaces where one of
Andrew Chernow wrote:
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to mostly need is the ability
Andrew Chernow wrote:
Andrew Chernow wrote:
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to
Andrew Chernow wrote:
Your method would work as well. The only issue is you still have the
same issue of binary distributed libpqs. Would redhat distribute a
binary linked with libpqtypes? If not, you have the same issue of the
end-user having to compile libpq ... passing -lpqtypes to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Andrew states:
What about user-defined type registration, sub-classing user or built-in
type handlers, handling of all data types in binary. There is a lot
of new functionality added by this patch to the existing libpq.
All of which may be
Bruce Momjian wrote:
I don't see requiring users to add -lpqtypes to use these functions as a
problem. The idea is that the default libpq would have enough hooks
that you could use it without modification.
You are correct, brain fart on my part. Not sure where my mind was at
but I
I think a wise thing would be for the patch submitters to give a _basic_
outline of what PQparam is trying to accomplish --- I mean like 10-20
lines with a code snippet, or code snippet with/withouth PQparam.
I found this posting from August, 2007 but
it isn't short/clear enough:
That is
On Tue, 2008-04-08 at 13:08 -0400, Andrew Dunstan wrote:
I think you should conduct a wider survey before you make that decision.
In particular, I'd like to hear from driver writers like Greg Sabino
Mullane and Jeff Davis, as well as regular libpq users.
I looked into this today.
*
This patch has an identity crisis. We initially called it PGparam (possibly
mispelled several times as PQparam) and then changed it to libpq type system
(typesys).
Several on patches started to call it libpqtypes, even I did. Any objections to
fixing the name to libpqtypes?
Any thoughts
On Tue, 2008-04-08 at 12:59 -0400, Bruce Momjian wrote:
If you need something exposed by
libpq that is not there already, please let us know.
The things that I found missing in libpq so far are:
* The ability to choose some result columns to be binary-formatted and
others to be
On Tue, Apr 8, 2008 at 8:06 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I think a wise thing would be for the patch submitters to give a _basic_
outline of what PQparam is trying to accomplish --- I mean like 10-20
lines with a code snippet, or code snippet with/withouth PQparam. Right
now
On Tue, Apr 8, 2008 at 9:28 PM, Jeff Davis [EMAIL PROTECTED] wrote:
with proposed changes, (I think) all your suggestions are addressed/moot. see:
* The ability to choose some result columns to be binary-formatted and
others to be text-formatted. I haven't thought of a reasonable API for
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that may not be
Jeff Davis wrote:
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks for
benefits that
On Tue, Apr 8, 2008 at 9:21 PM, Jeff Davis [EMAIL PROTECTED] wrote:
I looked into this today.
* Arrays and composites
Better ability in libpq to parse and construct arrays and composites
would be helpful. I think this is worthwhile to consider, and I would
expose the functionality (at
Jeff Davis [EMAIL PROTECTED] writes:
On Tue, 2008-04-08 at 15:22 -0400, Tom Lane wrote:
Well, for starters, using binary format. It is undeniable that that
creates more portability risks (cross-architecture and cross-PG-version
issues) than text format. Not everyone wants to take those risks
1 - 100 of 106 matches
Mail list logo
