Quoting Alex Dubov [EMAIL PROTECTED]:
However, with CLIENT_FOUND_ROWS I would prefer the
changed rows behavior, not the matched rows one.
May be additional parameter to connection string will
do.
OK. MySQL seems to be the odd one out here - Oracle seems to do what
PostgreSQL/SQLite3 do.
Quoting Bojan Smojver [EMAIL PROTECTED]:
flags = CLIENT_FOUND_ROWS,MAX_FIELD_SIZE_24MB
Or probably even:
flags = CLIENT_FOUND_ROWS/MAX_FIELD_SIZE_24MB
In order to avoid complications with valid keyword delimiters (which
comma belongs to).
--
Bojan
Quoting Alex Dubov [EMAIL PROTECTED]:
What the oracle does if BEFORE UPDATE trigger prevents
updating of matched rows? I believe that matched rows
will only differ from updated ones in the presence
of suitable trigger.
No idea. I just tried a simple update with identical data. I reported
Quoting Bojan Smojver [EMAIL PROTECTED]:
I reported that the row changed.
I meant to say: It reported...
--
Bojan
On Fri, 2006-05-19 at 01:25 -0700, koszi wrote:
In apache error log: [notice] child pid Segmentation Fault (11)
There are several known segfaults in MySQL driver. I can send you a
patch for some of them, if you like. I'm hoping this will eventually be
committed to Nick's SVN (some
On Fri, 2006-05-19 at 01:01 -0700, Alex Dubov wrote:
Now, before the error reporting problems evolves into
discussion, here is my view of things:
1. Any db error kills the request (404 || 500)
I'm not sure how/why APU DBD relates directly to Apache error codes. DBD
can be used elsewhere as
On Fri, 2006-05-19 at 13:11 +0200, Graham Leggett wrote:
This problem was solved by returning a simple APR error code, along with a
structure containing the LDAP error code, and the human readable error
string for logging.
Yep. All we need to do is return consistent APR error codes from DBD
On Fri, 2006-05-19 at 13:33 +0200, Graham Leggett wrote:
As the code string lookups were cheap, and only done on the error case, it
meant that a programmer was more likely to make the info available rather
than just writing out the (useless) APR code to the end user.
I think we are confusing
On Thu, 2006-05-18 at 01:27 -0700, Alex Dubov wrote:
Attached patch makes apr_dbd_mysql to always return
internal xxx_errno codes of mysql instead of arbitrary
integers.
We should be returning APR error codes throughout DBD drivers, IMHO. The
API user may not have access to interpretation of
Quoting Alex Dubov [EMAIL PROTECTED]:
So, to do anything
useful you must do something like:
if(apr_dbd_pvselect(...)) {
err_code = apr_dbd_error();
... backend specific stuff for err_code
}
Now, explain me how it is different from my way:
if((err_code = apr_dbd_pvselect(...)) {
...
On Tue, 2006-05-16 at 09:32 +0100, Nick Kew wrote:
At a guess, because noone knew about them at the time we
hacked the M4. I certainly didn't.
OK. I'll have a look then.
--
Bojan
Is there a particular reason we aren't using mysql_config script to
figure out various settings required to compile/link against MySQL?
Version 4.1 and above (what the driver is designed for) ship the script.
It could save a lot of guessing in the M4 script...
PS. We can do similar things
On Fri, 2006-05-12 at 13:44 -0700, Garrett Rooney wrote:
The repository is back, so you should be able to commit now ;-)
Cool. Thanks for your efforts on this one.
--
Bojan
Given that I cannot commit this right now, here is a patch for the bug
(introduced by yours truly) which causes SQLite3 transactions to go
haywire if prepared statements are used and _pselect/_pquery encounter
BUSY more than RETRY times.
Once ASF machines come back online, I'll commit
On Fri, 2006-05-05 at 13:47 +0100, Nick Kew wrote:
On apr_dbd_open, your remarks about specific drivers don't really
belong there, IMHO. The connection string documentation is already
in the manual:
http://httpd.apache.org/docs/2.2/mod/mod_dbd.html#dbdparams
Hmm, not sure why APR/APU users
Quoting koszi [EMAIL PROTECTED]:
Well actually, there's nothing. 2 object names with mysql
apr_dbd_mysql.o:
lt1-apr_dbd_mysql.o:
both have no symbols listed whatsoever.
Try nm -D.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Darn! I was hoping you won't say that. Now I have to do all those
savepoints... ;-)
Compile this one if you can! ;-)
Seriously, just some more ground work along the same lines...
--
Bojan
Index: include/apr_dbd.h
Quoting koszi [EMAIL PROTECTED]:
DBDParams dbname=vizsga user=root password=
DBDParams param1=value1[,param2=value2
Maybe?
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
DBDParams dbname=vizsga user=root password=
DBDParams param1=value1[,param2=value2
Maybe?
Nah, scrap that! Both forms should work for MySQL (delimiters are
defined as \r\n\t;|,).
BTW, documentation for mod_dbd appears to be misleading
Before I commit this, I would like to make sure that additional
explanations are useful and based on real behaviour of DBD. There is
some simplification in relation to apr_dbd_prepare() syntax, but
that's on purpose.
--
Bojan
Index: include/apr_dbd.h
On Wed, 2006-05-03 at 08:01 -0700, koszi wrote:
Any ideas, similar experiences, a workaround?
Quick and dirty - edit the Makefile located in apr-util directory (look
for APRUTIL_LDFLAGS) and correct the bogus stuff. Then run make/make
install.
This may be a bug after all. Maybe we should be
Quoting Garrett Rooney [EMAIL PROTECTED]:
I mean it's certainly no worse than it
was before ;-)
He, he, you would think so... Before you would get an APR_ENOTIMPL
back. Now you get a brand new segfault ;-)
--
Bojan
Quoting Joe Orton [EMAIL PROTECTED]:
... or OOM checking again.
A question in relation to this. I'm guessing there is not much use in
checking for APR pool allocation errors because the program is going
to blow up eventually, so these tests are mostly meaningless (at least
that's how I
Quoting Tyler MacDonald [EMAIL PROTECTED]:
Well if there's no statement handle to clean up, we shouldn't try to
register a cleanup event for it. The APR pool may have some memory available
that we can still use.
OK, thanks.
As for the return value (CR_OUT_OF_MEMORY), if that's
not
Quoting Bojan Smojver [EMAIL PROTECTED]:
By setting IGNORE_ERRORS, we can insert SAVEPOINTS before every
query/select inside PGSQL driver automatically (i.e. the caller
doesn't have to do it).
Something like this. Note that this is just to show the concept - I'm
sure none of it would
I've seen some segfaults in this code (*statement is passed to cleanup
instead of (*statement)-stmt), so here is the fix that addresses the
issue. Also, a possible segfault if (*statement)-stmt is NULL is
avoided as well.
--
Bojan
--- apr_dbd_mysql.c.orig 2006-05-02 19:55:55.0 +1000
+++
On Tue, 2006-05-02 at 10:15 -0400, Chris Darroch wrote:
This is sounding good to me!
Darn! I was hoping you won't say that. Now I have to do all those
savepoints... ;-)
I've promised I'll hustle up on
my httpd work so I apologize for my relative absence of help on
this thread, but by all
On Tue, 2006-05-02 at 13:51 -0700, koszi wrote:
please note the difference:
1)gcc -o conftest -g -O2 -pthread -I/usr/local/include/mysql/include
conftest.c -lmysqlclient_r -L/usr/local/include/mysql/lib*this
is the generated original, won't work
2) gcc -o config -g -O2
On Mon, 2006-05-01 at 14:11 -0400, Chris Darroch wrote:
Sounds good -- if you see an error you can handle, you clear
the transaction's error state back to ok, and apr_dbd lets you
proceed. Seems very reasonable to me; thanks!
Perhaps. However, it would seem that not all databases behave
On Mon, 2006-05-01 at 12:41 -0700, Tyler MacDonald wrote:
Maybe if MySQL is detected APR should refuse to support
transactions and tell the end user to find a non-broken database engine. :-)
He, he... Something like this:
#define APR_EGOFINDOTHERDB 9
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Not sure what Oracle does - I can check when I get
to work later on (but I'm guessing it would be similar to PostgreSQL).
Actually, Oracle will commit even if there were errors. So, the
situation is that for PostgreSQL, resetting the transaction
Quoting Nick Kew [EMAIL PROTECTED]:
static int dbd_foo_transaction_mode(apr_dbd_transaction_t *trans,
int flags)
{
int ret = 0
int mode = flags APR_DBD_TRANSACTION_MODEBITS;
switch (flags) {
^
Quoting Nick Kew [EMAIL PROTECTED]:
Erm, no. It it doesn't exist, that reduces to resetting trans-errnum.
Ah, yes. Sorry. I meant we return APR_ENOTIMPL if the database cannot
possibly support resetting of trans-errnum correctly (such as PGSQL).
Otherwise, we just reset (i.e. SQLite,
Quoting Bojan Smojver [EMAIL PROTECTED]:
Databases that don't support such functionality (e.g. PostgreSQL)
would simply return APR_ENOTIMPL.
Actually, I take this bit back. We *always* reset trans-errnum, just
like Nick said (even when there is no foo_clearerr()). And this to be
able
Quoting Bojan Smojver [EMAIL PROTECTED]:
Something like this:
Attached example patches.
--
Bojan
Index: include/apr_dbd.h
===
--- include/apr_dbd.h (revision 398759)
+++ include/apr_dbd.h (working copy)
@@ -153,6 +153,38
So, we know by now that some databases will fail the whole transaction
if any kind of error occurs, while some others won't. We also know
that sometimes one option is the desired behaviour, while at other
times the other option is what the caller wants - regardless of the
underlying
Quoting Chris Darroch [EMAIL PROTECTED]:
So, like this:
switch (trans-mode) {
case APR_DBD_TRANSACTION_COMMIT:
res = PQexec(trans-handle-conn, COMMIT);
break;
case APR_DBD_TRANSACTION_COMMIT_ON_SUCCESS:
if (trans-errnum) {
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
Jut a small comment, if you do go ahead with the flag and not add a
rollback funciton (which I think is much cleaner) then please be aware
that the caller will need to know if the result was successful commit,
successful rollback, or some other failure.
Here is the patch along the lines of setting the modes of the
transaction. It doesn't have force commit, but if the list decides
that it's the right thing to do, I'll rework. I didn't test this -
it's just a prototype. A patch for folks using MySQL is included as
well.
--
Bojan
Index:
Quoting Bojan Smojver [EMAIL PROTECTED]:
A patch for folks using MySQL is included as well.
Sorry about the traling comma after dbd_mysql_transaction_mode_set -
lazy cut/paste :-(
--
Bojan
On Sat, 2006-04-29 at 10:02 -0400, Chris Darroch wrote:
Otherwise, a nested function that wants to force a rollback
has to either do so, and then signal to all the callers that
the transaction is dead (and they then have to handle that
condition), or it has to set some internal application
I reworked the prepared statement support for SQLite3 a little bit (the
linking of statements to the handle didn't really work in the original
patches and there was some unnecessary memory allocation as well). If
nobody objects, I would like to commit this to the trunk in the next few
days.
Not
On Sat, 2006-04-29 at 10:02 -0400, Chris Darroch wrote:
#define APR_DBD_TRANS_COMMIT_ON_SUCCESS 0
#define APR_DBD_TRANS_COMMIT 1
#define APR_DBD_TRANS_ROLLBACK2
#define APR_DBD_TRANS_DEFAULT APR_DBD_TRANS_COMMIT_ON_SUCCESS
OK, I started working on this
Quoting ISF - Hassan Shabbir [EMAIL PROTECTED]:
gcc -o test test.o $(LIB)
Have you tried with -lapr-0 -laprutil-0 (or similar) at the end of
the above?
--
Bojan
On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote:
What's missing is the option to rollback even when successful.
In principle, a rollback argument to transaction_end would be
a better way to accomplish this. What level of version bump would
we need to introduce that?
Given that this would
On Fri, 2006-04-28 at 10:41 +0100, Nick Kew wrote:
Which reminds me: what's the function of the numeric suffix?
Probably to be able to have multiple binary incompatible major versions
installed in parallel.
--
Bojan
On Fri, 2006-04-28 at 09:41 -0400, Chris Darroch wrote:
Now I'm partly assuming that there can't be zillions of users
yet relying on it in a 1.3 environment who really also need a
forceable rollback feature, and that those who do can upgrade to
2.x. (After all, isn't it good to provide
Quoting Garrett Rooney [EMAIL PROTECTED]:
On 4/27/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Is there something I missed here or does that look like a real bug in
SQLite DBD driver?
Sounds problematic to me. Perhaps one of the users of the sqlite
drivers (we have a few on this list, IIRC
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
I do not have a fix for this (or else I would have sent a patch) since
I decided to use apr_dbd_query() directly to begin and commit/rollback
a transaction, this was necessary apr_dbd api did not have a rollback
function, which is an issue I mentioned as
Here is a quick patch that should get rid of the commit twice code.
I also removed explicit rollback, as it is not required (SQLite3 rolls
back by itself when things aren't good).
Note also that the default return code was changed to -1 in this
patch. It is normally an error to end a
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
--
Bojan
Index: include/apr_dbd.h
===
--- include/apr_dbd.h (revision 397754)
+++ include/apr_dbd.h (working copy)
@@ -153,6 +153,18 @@
Quoting Bojan Smojver [EMAIL PROTECTED]:
Here is a quick patch that should get rid of the commit twice code.
A variant with a more conservative approach.
This one also returns success if rollback was successful. I'm not sure
what semantics is supposed to be here, but other drivers appear
Quoting Bojan Smojver [EMAIL PROTECTED]:
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
OOPS! Before rollback in SQLite2/3, we need to make sure we blow away
error codes, or the query won't run. Hopefully better patch attached.
--
Bojan
Index
Quoting Bojan Smojver [EMAIL PROTECTED]:
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
For folks using MySQL...
--
Bojan
--- apr_dbd_mysql.c.orig 2006-04-28 15:24:56.0 +1000
+++ apr_dbd_mysql.c 2006-04-28 15:24:37.0 +1000
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
Looks good to me
I think we should go with the second version of the patch, in order to
keep in line with other drivers that return 0 if rollback was a
success. Does that work for you?
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
I'll test this and wait for the feedback before I commit.
This patch would not in fact work at all. Function dbd_sqlite_query()
checks the error code of the transaction before it does anything and
bails of the status is bad. Therefore, bad
On Tue, 2006-04-25 at 07:58 -0700, Garrett Rooney wrote:
Bojan, if you're merging a revision from trunk to a branch (or
vice-versa for that matter) please mention that in the commit log, so
people know that's what's happening. If you don't mention that it's a
merge, my immediate response to
On Tue, 2006-04-25 at 07:58 -0700, Garrett Rooney wrote:
if you're merging a revision from trunk to a branch (or
vice-versa for that matter)
Just occurred to me - if there is a backport from the trunk to a branch
that isn't a straight merge (i.e. the patch needs adjusting in order to
work), do
On Mon, 2006-04-24 at 16:13 -0400, Tom Bradford wrote:
Sorry, but Doxygen and a slideshow with little to no actual
information (both of which I've already seen) do not a suite of
documentation make.Doxygen is as valuable in the grand scheme of
things as is Javadoc, and that's not much
On Mon, 2006-04-24 at 17:07 -0400, Tom Bradford wrote:
By DBM-style, I mean you're effectively talking about the storage of
key/value pairs where the atom representation of a value is
effectively a void pointer, rather than tuples, which is how SQLite
and other RDBMS' inherently
Quoting [EMAIL PROTECTED]:
Retry SQLite3 query on BUSY
This is in trunk now, but if nobody objects, I would like to backport
it to 1.2.x as well.
--
Bojan
These two patches enable prepared statements in SQLite3, for both the
trunk and 1.2.x. Surprisingly :-), I actually did test this code to
some extent, so the basics should be OK. However, please hammer it and
let me know.
--
Bojan
Index: dbd/apr_dbd_sqlite3.c
Quoting Bojan Smojver [EMAIL PROTECTED]:
These two patches
In the patch for the trunk, every apr_dbd_mutex_[un]lock(sql-mutex)
should not have sql-mutex argument, of course. Sorry about that -
I'll blame this one on early morning/lack of caffeine ;-)
--
Bojan
I tested this patch with 1.2.x, but I'd like people to check if all is
cool before it gets committed to any branch/trunk. Essentially, we're
not assuming any more that the sqlite3_step() call is always going to be
successful - this call can return SQLITE_BUSY just the same as the one
inside the
On Mon, 2006-04-17 at 16:11 +1000, Bojan Smojver wrote:
I tested this patch with 1.2.x,
Yeah, and I also applied it to trunk as if it were for 1.2.x - sorry.
The mutex calls should be different. Here is a better version.
--
Bojan
Index: apr_dbd_sqlite3.c
In fact, this can be done even simpler. Reworked patch attached.
--
Bojan
Index: apr_dbd_sqlite3.c
===
--- apr_dbd_sqlite3.c (revision 394781)
+++ apr_dbd_sqlite3.c (working copy)
@@ -253,11 +253,24 @@
apr_dbd_mutex_lock();
On Sun, 2006-04-16 at 21:20 +, [EMAIL PROTECTED] wrote:
--- apr/apr-util/branches/1.2.x/dbd/apr_dbd_pgsql.c (original)
+++ apr/apr-util/branches/1.2.x/dbd/apr_dbd_pgsql.c Sun Apr 16 14:19:59 2006
@@ -221,7 +221,7 @@
apr_dbd_t *sql)
{
size_t len
On Wed, 2006-04-12 at 15:50 -0700, William A. Rowe, Jr. wrote:
[ ] [ ] [ ] apr-util-1.2.7
There is a bug in apr_dbd_pgsql.c, in function dbd_pgsql_pquery(). Just
before the PQclear() call, there should be:
*nrows = atoi(PQcmdTuples(res));
This applies to both the trunk and 1.2.7.
Without
On Thu, 2006-04-13 at 07:58 -0700, William A. Rowe, Jr. wrote:
Is this a regression?
I don't think so, actually. I think it's always been like this (although
not 100% sure on this).
Thanks for catching this Bojan!
Fixed in trunk, r394013 (my first commit - go easy :-). I believe this
should
On Thu, 2006-04-13 at 05:16 -0400, Craig Rodrigues wrote:
I'm trying to update the FreeBSD port of apr to use this.
Can the following patch go in? Older FreeBSD versions
like to have apr compiled with no thread support.
I didn't actually compile this, but it looks OK to me.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Any chance of a backport of this to 1.2.7?
Just another ping...
--
Bojan
On Sun, 2006-04-09 at 03:14 -0500, William A. Rowe, Jr. wrote:
I'm rolling 5pm UT, and I'm sorry but no cycles and too little understanding
of the dbd API for me to take this on :( Maybe another committer in the
next
9 hours can take a peek?
No worries.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Any chance of a backport of this to 1.2.7?
Thanks (r392812 AFAICS)!
--
Bojan
I'm not overly familiar with test specifics in APU, but it would seem
that LIBS doesn't gets set at all, which then causes AC_CHECK_FUNCS to
return false even if the function is actually available. So, the test
is a bit more manual: check for the function inside the library
using
This patch is just a request for comment, to see if I'm on the right
track here. The thing does compile, but I didn't actually test it.
You will note that I have hardcoded OIDs in several places, because if
we want to pick them up from pg_type.h, the detection code in dbd.m4
will have to
Quoting Nick Kew [EMAIL PROTECTED]:
[ Please don't Cc: me when you post to the list. One copy
of your messages is enough ]
Ah, sorry :-(
If you want to take that on, feel free. Does it gain us anything?
Not much. Maybe a few CPU cycles that get used for building the string
PREPARE ...
On Fri, 2006-03-31 at 11:00 +0100, Nick Kew wrote:
--- apr_dbd.c (revision 390371)
+++ apr_dbd.c (working copy)
@@ -63,17 +63,32 @@
}
#endif
+static apr_status_t apr_dbd_term(void *ptr)
+{
+/* set drivers to NULL so init can work again */
+drivers = NULL;
+
+/*
On Fri, 2006-04-07 at 23:49 +0100, Nick Kew wrote:
It's also possible that it did exist
but that the code was written with insufficient reference to TFM.
Do you know when PQprepare first appeared?
If PostgreSQL manuals are accurate (and there is no reason why they
shouldn't be), the first
Quoting Bojan Smojver [EMAIL PROTECTED]:
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
Don't worry about
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
--
Bojan
Quoting Nick Kew [EMAIL PROTECTED]:
In case you don't follow APR svn commits, I committed patches
including yours to apr_dbd yesterday.
Thanks! Awesome.
--
Bojan
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
When did we drift back to this naming convention?
I thought we were trying to move twords lib_object_subobject_verb?
E.g. apr_dbd_name_get?
It's really aggrivating to use an api that's pulling in both directions
at once :(
Sorry about that. I
Quoting Nick Kew [EMAIL PROTECTED]:
Proposed patch below.
[...snip...]
--- apr_dbd.c (revision 390371)
+++ apr_dbd.c (working copy)
@@ -63,17 +63,32 @@
}
#endif
+static apr_status_t apr_dbd_term(void *ptr)
+{
+/* set drivers to NULL so init can work again */
+drivers =
Quoting Nick Kew [EMAIL PROTECTED]:
Proposed patch below.
One more thing I've forgotten in my previous e-mail. Unless there is
some kind of binary compatibility problem (I don't see it), this would
be a good candidate for backporting to 1.2.x.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
There's no reason for compat macros, this code has not been released
in any version of APR, so compat is not an issue.
I was referring to renaming all DBD functions actually (including the
new ones), so that they follow the naming proper convention
Quoting Garrett Rooney [EMAIL PROTECTED]:
Well, it can be done for 1.3.x, but it would need to be by adding
macros for the NEW names, so the old symbols still exist at link time.
We can't backport such a change to 1.2.x, since it involves adding
new symbols.
I wasn't thinking any of this
Quoting Garrett Rooney [EMAIL PROTECTED]:
1.3.x is compatible with 1.2.x in the sense that programs compiled
against 1.2.x must continue to run against 1.3.x. The reverse is not
true, which is why in minor version number bumps we can add new
functions. To remove functions (or macros for that
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
Right - I wasn't being critical of your specific new fn, but just a general
observation. In the past, we created renames_proposed to collect a list for
review and comment before committing the changes; if you agree with the
syntax _get _set etc,
Quoting Bojan Smojver [EMAIL PROTECTED]:
Hopefully, this should be the correct lot of patches [...snip...]
Just being a pest... Anyone had a chance to take a look?
PS. The e-mail with patches is from 24 Feb 2006, in case you can't
find it (like I couldn't :-). The Oracle patch (not done
I asked a while back about having a test in this function to this effect:
if (drivers)
return APR_SUCCESS;
This was to make sure that more than one Apache module can call the
function without any ill effect. Obviously, calling this function from
more than one thread would still be unsafe,
Quoting Nick Kew [EMAIL PROTECTED]:
I don't think your suggestion is quite enough, as the lifetime
of drivers is tied to the pool. But if we add a pool cleanup
that resets drivers to NULL, it should be fine AFAICS.
I'll put that in if noone shouts.
Excellent! Thanks.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
Just committed the column names patch to trunk, and will look at the
bounds checking stuff when I get a chance.
I've forgotten to ask... Any objections to having these two fixes in 1.2.x?
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
Will try to get to it tonight.
Legend! Thanks heaps.
--
Bojan
On Tue, 2006-03-14 at 22:18 -0800, Garrett Rooney wrote:
And it turns out I actually did do it, see r385977 and r385976.
Apologies for wasting your time :-(
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
On 2/23/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Browsing through the code of DBD, I noticed that SQLite2/3 don't quite
do the advertised bounds checking for get_entry functions. The
following patch should be good for both 1.2.2 and the trunk
Quoting Garrett Rooney [EMAIL PROTECTED]:
Just committed the column names patch to trunk, and will look at the
bounds checking stuff when I get a chance.
Thanks.
BTW, does the column names
stuff need to be fixed in the sqlite2 implementation as well?
It shouldn't need fixing, because
Quoting Bojan Smojver [EMAIL PROTECTED]:
This patch fixes memory allocation problems with column names in both
1.2.2 and trunk. It compiled fine on FC4.
Just being a pest... What are the chances of this patch and the bounds
checking patch for SQLite2/3 being applied to 1.2.x and trunk
On Wed, 2006-02-22 at 05:51 +, Nick Kew wrote:
If a pool is needed, it should be simple enough to make it a member of the
apr_dbd_results_t struct. But since get_row at the same level of the API
has a pool argument, I agree your proposal looks like the best solution.
Actually, when I
Browsing through the code of DBD, I noticed that SQLite2/3 don't quite
do the advertised bounds checking for get_entry functions. The
following patch should be good for both 1.2.2 and the trunk.
--
Bojan
diff -rauN apr-util-1.2.2-vanilla/dbd/apr_dbd_sqlite2.c
Quoting Bojan Smojver [EMAIL PROTECTED]:
What should happen instead for SQLite3 is
apr_pstrdup of column names inside dbd_sqlite3_select (i.e. at present,
this part of the code in the driver is buggy, but since it doesn't get
used, nobody noticed yet).
More on this point - the new code should
801 - 900 of 930 matches
Mail list logo
