libdbi-devel — Discussion about development of the core library and DBD interface

Re: [libdbi-devel] dbi_conn_queryf and using __attribute__((format))

[<mar...@mh...>]

Tom Lane writes:
 > and here's a typical use:
 > 
 > extern int pg_snprintf(char *str, size_t count, const char *fmt,...)
 > /* This extension allows gcc to check the format string */
 > __attribute__((format(PG_PRINTF_ATTRIBUTE, 3, 4)));
 > 


Hi Tom,

thanks for your explanation. I've checked the sources, and
interestingly src/dbi_main.c contains a declaration of dbi_conn_queryf():

dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...) __attribute__ ((format (printf, 2, 3)));

in addition to the declaration in include/dbi/dbi.h:

dbi_result dbi_conn_queryf(dbi_conn Conn, const char *formatstr, ...);

Was that a half-assed attempt to implement what the OP asked for?
Would it be sufficient to move the first declaration to the header
which is visible to the programs that actually call the function?

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-devel] dbi_conn_queryf and using __attribute__((format))

[Tom L. <tg...@ss...>]

mar...@mh... writes:
> could you please clarify with a code snippet (or better yet, a patch)
> what should be changed in the libdbi sources? Also, I take from [1]
> that this is a GNU extension of C. Would other compilers like LLVM
> complain about the suggested change?

It is a GNU extension, but it's not hard to hide it from non-GNU
compilers.  The Postgres project uses this extensively, and it's caught
many a typo for us.  (Of course, you need to have developers using gcc,
or it doesn't help.  But not everyone has to use it, as long as those
who do use it will notice warnings.)

Some relevant bits from the Postgres sources:

#ifndef __GNUC__
#define __attribute__(_arg_)
#endif

/*
 * Set the format style used by gcc to check printf type functions. We really
 * want the "gnu_printf" style set, which includes what glibc uses, such
 * as %m for error strings and %lld for 64 bit long longs. But not all gcc
 * compilers are known to support it, so we just use "printf" which all
 * gcc versions alive are known to support, except on Windows where
 * using "gnu_printf" style makes a dramatic difference. Maybe someday
 * we'll have a configure test for this, if we ever discover use of more
 * variants to be necessary.
 */
#ifdef WIN32
#define PG_PRINTF_ATTRIBUTE gnu_printf
#else
#define PG_PRINTF_ATTRIBUTE printf
#endif

and here's a typical use:

extern int pg_snprintf(char *str, size_t count, const char *fmt,...)
/* This extension allows gcc to check the format string */
__attribute__((format(PG_PRINTF_ATTRIBUTE, 3, 4)));

Depending on your usage, you might not need the gnu_printf dance.

			regards, tom lane

[libdbi-devel] dbi_conn_queryf and using __attribute__((format))

[<mar...@mh...>]

Holger Freyther writes:
 > Hi,
 > 
 > today I used %llu instead of %u and had some runtime error.
 > GCC can warn about such issues but only if the format attribute
 > is used[1].
 > 
 > Could you please use this in future releases to catch errors
 > while compiling the code?
 > 
 > thank you
 >   holger
 > 
 > 
 > [1] http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
 > 

Hi,

could you please clarify with a code snippet (or better yet, a patch)
what should be changed in the libdbi sources? Also, I take from [1]
that this is a GNU extension of C. Would other compilers like LLVM
complain about the suggested change?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38 

[libdbi-devel] dbi_conn_queryf and using __attribute__((format))

[Holger F. <ho...@fr...>]

Hi,

today I used %llu instead of %u and had some runtime error.
GCC can warn about such issues but only if the format attribute
is used[1].

Could you please use this in future releases to catch errors
while compiling the code?

thank you
  holger


[1] http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

[libdbi-devel] [ libdbi-Bugs-3539648 ] dbi_conn_error not reentrant

[SourceForge.net <no...@so...>]

Bugs item #3539648, was opened at 2012-07-03 01:53
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=3539648&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Emmanuel Courrges (ecourreges)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbi_conn_error not reentrant

Initial Comment:
Just thought I would finally file this one which could be fixed for the next release:

The static errmsg in dbi_conn_error prevents the function from being used in a multithreaded context.
It clearly crashes when 2 or more threads (each having their own dbi_conn) try to get the error message simultaneously.

I guess the simplest solution is to allocate it and force the user to free it, but all existing code will have a memory leak...
Another good solution is to add a char * full_err_msg in the dbi_conn_t, so that it becomes thread safe for different connections, and it avoids the memory leak or an api change.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2012-07-03 15:15

Message:
I've implemented your second suggestion, see the current cvs revision. It
passes all tests ok. However, I think this implementation is only
"thread-safe" as long as each thread uses its own connection. Maybe this
should go into the docs somewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=3539648&group_id=23824

[libdbi-devel] [ libdbi-Bugs-3539648 ] dbi_conn_error not reentrant

[SourceForge.net <no...@so...>]

Bugs item #3539648, was opened at 2012-07-03 01:53
Message generated for change (Tracker Item Submitted) made by ecourreges
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=3539648&group_id=23824

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Emmanuel Courrges (ecourreges)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbi_conn_error not reentrant

Initial Comment:
Just thought I would finally file this one which could be fixed for the next release:

The static errmsg in dbi_conn_error prevents the function from being used in a multithreaded context.
It clearly crashes when 2 or more threads (each having their own dbi_conn) try to get the error message simultaneously.

I guess the simplest solution is to allocate it and force the user to free it, but all existing code will have a memory leak...
Another good solution is to add a char * full_err_msg in the dbi_conn_t, so that it becomes thread safe for different connections, and it avoids the memory leak or an api change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=379806&aid=3539648&group_id=23824

Re: [libdbi-devel] Memory leak in dbi_result.c

[Markus H. <mar...@mh...>]

Hi,

I've fiddled a little with your testcase and the suggested fix. My  
results are as follows using the mysql driver (my loop ran only one  
tenth of the suggested cycles, so your values may be even higher):

before fix:

==3410== LEAK SUMMARY:
==3410==    definitely lost: 240,384 bytes in 10,004 blocks
==3410==    indirectly lost: 170,032 bytes in 30,004 blocks
==3410==      possibly lost: 0 bytes in 0 blocks
==3410==    still reachable: 8,594 bytes in 7 blocks
==3410==         suppressed: 0 bytes in 0 blocks


after fix:

==3541== LEAK SUMMARY:
==3541==    definitely lost: 384 bytes in 4 blocks
==3541==    indirectly lost: 32 bytes in 4 blocks
==3541==      possibly lost: 0 bytes in 0 blocks
==3541==    still reachable: 8,594 bytes in 7 blocks
==3541==         suppressed: 0 bytes in 0 blocks

So there is a clear improvement although some memory is still lost.  
Even worse, I've discovered another leak in the sqlite3 driver (or in  
sqlite?) with this testcase, so there is some more work to do.

I've checked in the suggested fix. Thanks for bringing this to my attention.

regards,
Markus

Quoting Tom Lane <tg...@ss...>:

> A loop such as the following leaks memory in libdbi 0.8.3:
>
>
> 	for (n = 0; n < 100000; n++) {
>
> 	res = dbi_conn_query(conn, "SELECT * FROM foo;");
>
> 	if (!dbi_result_first_row(res)) {
> 		fprintf(stderr, "dbi_result_first_row() failed.\n");
> 		exit(1);
> 	}
>
> 	for (i = 0; i < 2; i++) {
> 		do {
> 			val = dbi_result_get_int(res, "val");
> 			if (n == 0)
> 			  printf("val: %d\n", val);
>
> 		} while (dbi_result_next_row(res));
>
> 		/* Rewind for the next iteration of the for() loop */
> 		if (!dbi_result_first_row(res)) {
> 			fprintf(stderr, "dbi_result_first_row() failed.\n");
> 			exit(1);
> 		}
> 	}
>
> 	dbi_result_free(res);
>
> 	}
>
>
> This patch appears to fix it:
>
>
> diff -Naur libdbi-0.8.3.orig/src/dbi_result.c libdbi-0.8.3/src/dbi_result.c
> --- libdbi-0.8.3.orig/src/dbi_result.c	2008-01-23 11:37:36.000000000 -0500
> +++ libdbi-0.8.3/src/dbi_result.c	2011-09-06 20:51:34.610449576 -0400
> @@ -1533,7 +1533,7 @@
>  }
>
>  static int _is_row_fetched(dbi_result_t *result, unsigned long long row) {
> -  if (!result->rows || (row >= result->numrows_matched)) return -1;
> +  if (!result->rows || (row > result->numrows_matched)) return -1;
>    return !(result->rows[row] == NULL);
>  }
>
>
>
> This was discovered by some folks at Bull, who also deserve credit for
> the patch, but I don't have a full name.
>
> 			regards, tom lane
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-devel] Memory leak in dbi_result.c

[Markus H. <mar...@mh...>]

Hi Tom,

thank you for sharing the patch. The patched sources pass the tests  
without problems, but I'd like to set up your test case to make sure  
the patch indeed fixes a problem on my OS as well. I'll take care of  
this shortly.

regards,
Markus

Quoting Tom Lane <tg...@ss...>:

> A loop such as the following leaks memory in libdbi 0.8.3:
>
>
> 	for (n = 0; n < 100000; n++) {
>
> 	res = dbi_conn_query(conn, "SELECT * FROM foo;");
>
> 	if (!dbi_result_first_row(res)) {
> 		fprintf(stderr, "dbi_result_first_row() failed.\n");
> 		exit(1);
> 	}
>
> 	for (i = 0; i < 2; i++) {
> 		do {
> 			val = dbi_result_get_int(res, "val");
> 			if (n == 0)
> 			  printf("val: %d\n", val);
>
> 		} while (dbi_result_next_row(res));
>
> 		/* Rewind for the next iteration of the for() loop */
> 		if (!dbi_result_first_row(res)) {
> 			fprintf(stderr, "dbi_result_first_row() failed.\n");
> 			exit(1);
> 		}
> 	}
>
> 	dbi_result_free(res);
>
> 	}
>
>
> This patch appears to fix it:
>
>
> diff -Naur libdbi-0.8.3.orig/src/dbi_result.c libdbi-0.8.3/src/dbi_result.c
> --- libdbi-0.8.3.orig/src/dbi_result.c	2008-01-23 11:37:36.000000000 -0500
> +++ libdbi-0.8.3/src/dbi_result.c	2011-09-06 20:51:34.610449576 -0400
> @@ -1533,7 +1533,7 @@
>  }
>
>  static int _is_row_fetched(dbi_result_t *result, unsigned long long row) {
> -  if (!result->rows || (row >= result->numrows_matched)) return -1;
> +  if (!result->rows || (row > result->numrows_matched)) return -1;
>    return !(result->rows[row] == NULL);
>  }
>
>
>
> This was discovered by some folks at Bull, who also deserve credit for
> the patch, but I don't have a full name.
>
> 			regards, tom lane
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-devel] Memory leak in dbi_result.c

[Tom L. <tg...@ss...>]

A loop such as the following leaks memory in libdbi 0.8.3:


	for (n = 0; n < 100000; n++) {

	res = dbi_conn_query(conn, "SELECT * FROM foo;");

	if (!dbi_result_first_row(res)) {
		fprintf(stderr, "dbi_result_first_row() failed.\n");
		exit(1);
	}

	for (i = 0; i < 2; i++) {
		do {
			val = dbi_result_get_int(res, "val");
			if (n == 0)
			  printf("val: %d\n", val);

		} while (dbi_result_next_row(res));

		/* Rewind for the next iteration of the for() loop */
		if (!dbi_result_first_row(res)) {
			fprintf(stderr, "dbi_result_first_row() failed.\n");
			exit(1);
		}
	}

	dbi_result_free(res);

	}


This patch appears to fix it:


diff -Naur libdbi-0.8.3.orig/src/dbi_result.c libdbi-0.8.3/src/dbi_result.c
--- libdbi-0.8.3.orig/src/dbi_result.c	2008-01-23 11:37:36.000000000 -0500
+++ libdbi-0.8.3/src/dbi_result.c	2011-09-06 20:51:34.610449576 -0400
@@ -1533,7 +1533,7 @@
 }
 
 static int _is_row_fetched(dbi_result_t *result, unsigned long long row) {
-  if (!result->rows || (row >= result->numrows_matched)) return -1;
+  if (!result->rows || (row > result->numrows_matched)) return -1;
   return !(result->rows[row] == NULL);
 }
 


This was discovered by some folks at Bull, who also deserve credit for
the patch, but I don't have a full name.

			regards, tom lane

[libdbi-devel] Missed case in patch for dbi_result.c

[<mar...@mh...>]

Tom Lane writes:
 > Hi folks,
 >   I package libdbi for Red Hat.  While investigating a user's bug report
 > I found out that 0.8.3's dbi_result.c was fetching the wrong union
 > member when returning result values that are wider than the type
 > returned by the database.  Looking into your CVS, I see that this was
 > fixed back in May 2009 ... for all cases but one.  I believe you still
 > need the attached patch.
 > 

Hi Tom,

thanks for providing the patch. This was indeed an oversight. I've
checked in the patch, see the latest cvs revision.

best regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-devel] Missed case in patch for dbi_result.c

[Tom L. <tg...@ss...>]

Hi folks,
  I package libdbi for Red Hat.  While investigating a user's bug report
I found out that 0.8.3's dbi_result.c was fetching the wrong union
member when returning result values that are wider than the type
returned by the database.  Looking into your CVS, I see that this was
fixed back in May 2009 ... for all cases but one.  I believe you still
need the attached patch.

			regards, tom lane


*** libdbi-0.8.3/src/dbi_result.c~	Fri Aug  5 13:53:18 2011
--- libdbi-0.8.3/src/dbi_result.c	Fri Aug  5 13:54:42 2011
***************
*** 1133,1138 ****
--- 1133,1139 ----
  
    switch (RESULT->field_attribs[fieldidx] & DBI_DECIMAL_SIZEMASK) {
    case DBI_DECIMAL_SIZE4:
+     return RESULT->rows[RESULT->currowidx]->field_values[fieldidx].d_float;
    case DBI_DECIMAL_SIZE8:
      return RESULT->rows[RESULT->currowidx]->field_values[fieldidx].d_double;
    default:

Re: [libdbi-devel] libdbi maintainership needs help

[Angel A. <ang...@ub...>]

Sorry, here is the debdiff attachment.

Regards,

2011/7/13 Angel Abad <ang...@ub...>:
> 2011/7/13 Thomas Goirand <th...@go...>:
>> On 07/13/2011 11:05 PM, Clint Byrum wrote:
>>> Excerpts from Thomas Goirand's message of Wed Jul 13 06:06:36 -0700 2011:
>>>> On 07/13/2011 08:00 PM, Clint Byrum wrote:
>>>>> I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
>>>>> and it built with a couple of extra files (.install files to put the files
>>>>> in the right place). It also uses dh_autoreconf successfully. See attached
>>>>> patch.
>>>>
>>>> Why did you remove my use of a build folder? It was working perfectly!
>>>
>>> Why do you feel a need to use a build folder?
>>
>> Because that's the most easy way to not touch any files of upstream, and
>> because it did work perfectly. Because dh_autoreconf has proven to be
>> failing in many cases, and that my system has no way break. Note that
>> this is the type of build system that many packages in Debian are using.
>> For example: Xen, the kernel, and so on.
>>
>>>> You are also removing the patch that does:
>>>>
>>>> -                CFLAGS="-O20 -ffast-math -D_REENTRANT -fsigned-char
>>>> std=gnu99"
>>>> -                PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
>>>> fsigned-char -std=gnu99";;
>>>> +                CFLAGS="-D_REENTRANT -fsigned-char -std=gnu99"
>>>> +                PROFILE="-pg -g -D_REENTRANT -fsigned-char std=gnu99";;
>>>>
>>>
>>> I renamed it. Its re-added later with .patch instead of .dpatch as it is
>>> no longer a dpatch, but a quilt patch.
>>
>> With all the respect, I don't see why you are wasting your time changing
>> things that worked. If you want to take over the package completely, and
>> rewrite things from scratch, ok, but not now.
>>
>>>> (and same for the configure) Why? It's 100% needed!!!
>>>>
>>>
>>> dh_autoreconf handles the config.sub/config.guess patches that you had
>>> embedded in the debian package.
>>
>> This is a mistake in the Git manipulation, which I didn't have time to
>> fix. As these files are anyway overwritten by the build process which
>> takes them from /usr/share, I thought I would fix that later.
>>
>> You could remove the diff easily. I just had no time to work on that.
>>
>>>    cd $(BUILD_DIR) && CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
>>>
>>> I'm not sure what this does that debhelper does not do. The resulting
>>> .debs are *identical* as far as I can tell.
>>>
>>>> With what I did, dh_autoreconf isn't needed anymore. dh_autoreconf is
>>>> overly complicated, and it's nice to be able to avoid it.
>>>
>>> I disagree whole heartedly. dh_autoreconf is well tested and solves the
>>> exact problem that you are solving by manually patching files in the
>>> upstream portion of the package.
>>
>> Again, if you are talking about the config.{sub,guess}, it's just that I
>> had no time to fix an issue that appeared when not using the build folder.
>>
>>> The idea is to make the package more maintainable.
>>
>> IMHO, you are doing the exact opposite thing here.
>
> Hi! Sorry but I disagree, in my opinion the simplest is the easiest way.
>
> But I will not enter further into this discussion. I will try to fix
> bugs and I will fix them I will send you patches.
>
> I attach a patch debdiff for #633484, I tried it with all versions
> mentioned in bug from snapshot.debian.org and it works fine. Also I
> tried to upgrade from squeeze and it works fine too.
>
> I attach the debdiff to the bug too.
>
> Regards,
>
>>> The excellent
>>> stuff you did in debian/rules has been superseded by debhelper now.
>>
>> What do you mean? Are you talking about dh short style? Eg:
>>
>> %:
>>        dh $@
>>
>> ???
>>
>> If so, *NO*. It's not AT ALL superseded. Read the recent debian-mentor@
>> thread about it (search for Nitpicking). It's a different style, but
>> it's not deprecating the other one.
>>
>>> libdbi doesn't seem to be special in any regard except the patch to the
>>> build flags which is appropriately in debian/patches. So why would you
>>> want to have such a long explicit rules file?
>>
>> It's not simplifying to change something that has proven to be working,
>> especially when things are currently broken and I'm asking help to fix them.
>>
>>> You have stated a few
>>> times that you don't have time for such things. I'm hoping to reduce
>>> the burden is all.
>>
>> Don't. Just fix the RC bugs, nothing more, nothing less. You're not
>> reducing the burden, you are increasing it.
>>
>> If you really want to help, write a minimalistic patch for both #599127
>> (in the Squeeze branch of the Git) and fix and test for #633484. Don't
>> do anything else, and don't write to me about another change. Also, have
>> a look why the postgress test suite doesn't work anymore for
>> libdbi-driver in SID.
>>
>>> Take it or leave it
>>
>> I leave it, because now isn't the time to change things. Now is the time
>> to fix the open RC bugs, and upload a package that works as other are
>> expecting, and also fix the issue in Debian stable. I regret to say it,
>> but having to write back to you about it wastes my (currently quite)
>> limited time. Sorry to be very direct here, I hope you don't take it
>> badly, as I enjoyed a lot the hacking we did together previously on libdbi.
>>
>>> but this would also simplify merges and syncs with
>>> Ubuntu so I'm hoping you'll take it. :)
>>
>> Feel free to do such changes *later*. :)
>> Also, I regret to say it: I wont care about Ubuntu anymore, I'm focusing
>> on Debian. I've learned it the hard way, but Debian isn't Ubuntu, and we
>> shouldn't accept such arguments, it's simply not a valid one.
>>
>> Cheers,
>>
>> Thomas
>>
>
>
>
> --
> Angel Abad
> ang...@gm... | ang...@ub... | ang...@fs...
> http://www.pastelero.net
> FPR: EBF6 080D 59D4 008A DF47  00D4 098D AE47 EE3B C279
>



-- 
Angel Abad
ang...@gm... | ang...@ub... | ang...@fs...
http://www.pastelero.net
FPR: EBF6 080D 59D4 008A DF47  00D4 098D AE47 EE3B C279

Re: [libdbi-devel] libdbi maintainership needs help

[Angel A. <ang...@ub...>]

2011/7/13 Thomas Goirand <th...@go...>:
> On 07/13/2011 11:05 PM, Clint Byrum wrote:
>> Excerpts from Thomas Goirand's message of Wed Jul 13 06:06:36 -0700 2011:
>>> On 07/13/2011 08:00 PM, Clint Byrum wrote:
>>>> I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
>>>> and it built with a couple of extra files (.install files to put the files
>>>> in the right place). It also uses dh_autoreconf successfully. See attached
>>>> patch.
>>>
>>> Why did you remove my use of a build folder? It was working perfectly!
>>
>> Why do you feel a need to use a build folder?
>
> Because that's the most easy way to not touch any files of upstream, and
> because it did work perfectly. Because dh_autoreconf has proven to be
> failing in many cases, and that my system has no way break. Note that
> this is the type of build system that many packages in Debian are using.
> For example: Xen, the kernel, and so on.
>
>>> You are also removing the patch that does:
>>>
>>> -                CFLAGS="-O20 -ffast-math -D_REENTRANT -fsigned-char
>>> std=gnu99"
>>> -                PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
>>> fsigned-char -std=gnu99";;
>>> +                CFLAGS="-D_REENTRANT -fsigned-char -std=gnu99"
>>> +                PROFILE="-pg -g -D_REENTRANT -fsigned-char std=gnu99";;
>>>
>>
>> I renamed it. Its re-added later with .patch instead of .dpatch as it is
>> no longer a dpatch, but a quilt patch.
>
> With all the respect, I don't see why you are wasting your time changing
> things that worked. If you want to take over the package completely, and
> rewrite things from scratch, ok, but not now.
>
>>> (and same for the configure) Why? It's 100% needed!!!
>>>
>>
>> dh_autoreconf handles the config.sub/config.guess patches that you had
>> embedded in the debian package.
>
> This is a mistake in the Git manipulation, which I didn't have time to
> fix. As these files are anyway overwritten by the build process which
> takes them from /usr/share, I thought I would fix that later.
>
> You could remove the diff easily. I just had no time to work on that.
>
>>    cd $(BUILD_DIR) && CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
>>
>> I'm not sure what this does that debhelper does not do. The resulting
>> .debs are *identical* as far as I can tell.
>>
>>> With what I did, dh_autoreconf isn't needed anymore. dh_autoreconf is
>>> overly complicated, and it's nice to be able to avoid it.
>>
>> I disagree whole heartedly. dh_autoreconf is well tested and solves the
>> exact problem that you are solving by manually patching files in the
>> upstream portion of the package.
>
> Again, if you are talking about the config.{sub,guess}, it's just that I
> had no time to fix an issue that appeared when not using the build folder.
>
>> The idea is to make the package more maintainable.
>
> IMHO, you are doing the exact opposite thing here.

Hi! Sorry but I disagree, in my opinion the simplest is the easiest way.

But I will not enter further into this discussion. I will try to fix
bugs and I will fix them I will send you patches.

I attach a patch debdiff for #633484, I tried it with all versions
mentioned in bug from snapshot.debian.org and it works fine. Also I
tried to upgrade from squeeze and it works fine too.

I attach the debdiff to the bug too.

Regards,

>> The excellent
>> stuff you did in debian/rules has been superseded by debhelper now.
>
> What do you mean? Are you talking about dh short style? Eg:
>
> %:
>        dh $@
>
> ???
>
> If so, *NO*. It's not AT ALL superseded. Read the recent debian-mentor@
> thread about it (search for Nitpicking). It's a different style, but
> it's not deprecating the other one.
>
>> libdbi doesn't seem to be special in any regard except the patch to the
>> build flags which is appropriately in debian/patches. So why would you
>> want to have such a long explicit rules file?
>
> It's not simplifying to change something that has proven to be working,
> especially when things are currently broken and I'm asking help to fix them.
>
>> You have stated a few
>> times that you don't have time for such things. I'm hoping to reduce
>> the burden is all.
>
> Don't. Just fix the RC bugs, nothing more, nothing less. You're not
> reducing the burden, you are increasing it.
>
> If you really want to help, write a minimalistic patch for both #599127
> (in the Squeeze branch of the Git) and fix and test for #633484. Don't
> do anything else, and don't write to me about another change. Also, have
> a look why the postgress test suite doesn't work anymore for
> libdbi-driver in SID.
>
>> Take it or leave it
>
> I leave it, because now isn't the time to change things. Now is the time
> to fix the open RC bugs, and upload a package that works as other are
> expecting, and also fix the issue in Debian stable. I regret to say it,
> but having to write back to you about it wastes my (currently quite)
> limited time. Sorry to be very direct here, I hope you don't take it
> badly, as I enjoyed a lot the hacking we did together previously on libdbi.
>
>> but this would also simplify merges and syncs with
>> Ubuntu so I'm hoping you'll take it. :)
>
> Feel free to do such changes *later*. :)
> Also, I regret to say it: I wont care about Ubuntu anymore, I'm focusing
> on Debian. I've learned it the hard way, but Debian isn't Ubuntu, and we
> shouldn't accept such arguments, it's simply not a valid one.
>
> Cheers,
>
> Thomas
>



-- 
Angel Abad
ang...@gm... | ang...@ub... | ang...@fs...
http://www.pastelero.net
FPR: EBF6 080D 59D4 008A DF47  00D4 098D AE47 EE3B C279

Re: [libdbi-devel] libdbi maintainership needs help

[Thomas G. <th...@go...>]

On 07/13/2011 11:05 PM, Clint Byrum wrote:
> Excerpts from Thomas Goirand's message of Wed Jul 13 06:06:36 -0700 2011:
>> On 07/13/2011 08:00 PM, Clint Byrum wrote:
>>> I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
>>> and it built with a couple of extra files (.install files to put the files
>>> in the right place). It also uses dh_autoreconf successfully. See attached
>>> patch.
>>
>> Why did you remove my use of a build folder? It was working perfectly!
> 
> Why do you feel a need to use a build folder?

Because that's the most easy way to not touch any files of upstream, and
because it did work perfectly. Because dh_autoreconf has proven to be
failing in many cases, and that my system has no way break. Note that
this is the type of build system that many packages in Debian are using.
For example: Xen, the kernel, and so on.

>> You are also removing the patch that does:
>>
>> -                CFLAGS="-O20 -ffast-math -D_REENTRANT -fsigned-char
>> std=gnu99"
>> -                PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
>> fsigned-char -std=gnu99";;
>> +                CFLAGS="-D_REENTRANT -fsigned-char -std=gnu99"
>> +                PROFILE="-pg -g -D_REENTRANT -fsigned-char std=gnu99";;
>>
> 
> I renamed it. Its re-added later with .patch instead of .dpatch as it is
> no longer a dpatch, but a quilt patch.

With all the respect, I don't see why you are wasting your time changing
things that worked. If you want to take over the package completely, and
rewrite things from scratch, ok, but not now.

>> (and same for the configure) Why? It's 100% needed!!!
>>
> 
> dh_autoreconf handles the config.sub/config.guess patches that you had
> embedded in the debian package.

This is a mistake in the Git manipulation, which I didn't have time to
fix. As these files are anyway overwritten by the build process which
takes them from /usr/share, I thought I would fix that later.

You could remove the diff easily. I just had no time to work on that.

>    cd $(BUILD_DIR) && CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
> 
> I'm not sure what this does that debhelper does not do. The resulting
> .debs are *identical* as far as I can tell.
> 
>> With what I did, dh_autoreconf isn't needed anymore. dh_autoreconf is
>> overly complicated, and it's nice to be able to avoid it.
> 
> I disagree whole heartedly. dh_autoreconf is well tested and solves the
> exact problem that you are solving by manually patching files in the
> upstream portion of the package.

Again, if you are talking about the config.{sub,guess}, it's just that I
had no time to fix an issue that appeared when not using the build folder.

> The idea is to make the package more maintainable.

IMHO, you are doing the exact opposite thing here.

> The excellent
> stuff you did in debian/rules has been superseded by debhelper now.

What do you mean? Are you talking about dh short style? Eg:

%:
	dh $@

???

If so, *NO*. It's not AT ALL superseded. Read the recent debian-mentor@
thread about it (search for Nitpicking). It's a different style, but
it's not deprecating the other one.

> libdbi doesn't seem to be special in any regard except the patch to the
> build flags which is appropriately in debian/patches. So why would you
> want to have such a long explicit rules file?

It's not simplifying to change something that has proven to be working,
especially when things are currently broken and I'm asking help to fix them.

> You have stated a few
> times that you don't have time for such things. I'm hoping to reduce
> the burden is all.

Don't. Just fix the RC bugs, nothing more, nothing less. You're not
reducing the burden, you are increasing it.

If you really want to help, write a minimalistic patch for both #599127
(in the Squeeze branch of the Git) and fix and test for #633484. Don't
do anything else, and don't write to me about another change. Also, have
a look why the postgress test suite doesn't work anymore for
libdbi-driver in SID.

> Take it or leave it

I leave it, because now isn't the time to change things. Now is the time
to fix the open RC bugs, and upload a package that works as other are
expecting, and also fix the issue in Debian stable. I regret to say it,
but having to write back to you about it wastes my (currently quite)
limited time. Sorry to be very direct here, I hope you don't take it
badly, as I enjoyed a lot the hacking we did together previously on libdbi.

> but this would also simplify merges and syncs with
> Ubuntu so I'm hoping you'll take it. :)

Feel free to do such changes *later*. :)
Also, I regret to say it: I wont care about Ubuntu anymore, I'm focusing
on Debian. I've learned it the hard way, but Debian isn't Ubuntu, and we
shouldn't accept such arguments, it's simply not a valid one.

Cheers,

Thomas

Re: [libdbi-devel] libdbi maintainership needs help

[Clint B. <cl...@ub...>]

Excerpts from Thomas Goirand's message of Wed Jul 13 06:06:36 -0700 2011:
> On 07/13/2011 08:00 PM, Clint Byrum wrote:
> > I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
> > and it built with a couple of extra files (.install files to put the files
> > in the right place). It also uses dh_autoreconf successfully. See attached
> > patch.
> 
> Why did you remove my use of a build folder? It was working perfectly!

Why do you feel a need to use a build folder?

> You are also removing the patch that does:
> 
> -                CFLAGS="-O20 -ffast-math -D_REENTRANT -fsigned-char
> std=gnu99"
> -                PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
> fsigned-char -std=gnu99";;
> +                CFLAGS="-D_REENTRANT -fsigned-char -std=gnu99"
> +                PROFILE="-pg -g -D_REENTRANT -fsigned-char std=gnu99";;
> 

I renamed it. Its re-added later with .patch instead of .dpatch as it is
no longer a dpatch, but a quilt patch.

> (and same for the configure) Why? It's 100% needed!!!
> 

dh_autoreconf handles the config.sub/config.guess patches that you had
embedded in the debian package.

   cd $(BUILD_DIR) && CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info

I'm not sure what this does that debhelper does not do. The resulting
.debs are *identical* as far as I can tell.

> With what I did, dh_autoreconf isn't needed anymore. dh_autoreconf is
> overly complicated, and it's nice to be able to avoid it.

I disagree whole heartedly. dh_autoreconf is well tested and solves the
exact problem that you are solving by manually patching files in the
upstream portion of the package.

> 
> Anyway, that's *not* what is needed for this package. What Debian needs
> is fixing the RC bugs, and here, by removing my patch, you are readding
> an issue that I've fixed!!! :)

The idea is to make the package more maintainable. The excellent
stuff you did in debian/rules has been superseded by debhelper now. As
transitions and changes are made to the toolchain in Debian, changes
will be propagated to debhelper before they make it to individually
built package rules files.

libdbi doesn't seem to be special in any regard except the patch to the
build flags which is appropriately in debian/patches. So why would you
want to have such a long explicit rules file? You have stated a few
times that you don't have time for such things. I'm hoping to reduce
the burden is all.

Take it or leave it, but this would also simplify merges and syncs with
Ubuntu so I'm hoping you'll take it. :)

Re: [libdbi-devel] libdbi maintainership needs help

[Thomas G. <th...@go...>]

On 07/13/2011 08:00 PM, Clint Byrum wrote:
> I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
> and it built with a couple of extra files (.install files to put the files
> in the right place). It also uses dh_autoreconf successfully. See attached
> patch.

Why did you remove my use of a build folder? It was working perfectly!
You are also removing the patch that does:

-                CFLAGS="-O20 -ffast-math -D_REENTRANT -fsigned-char
std=gnu99"
-                PROFILE="-pg -g -O20 -ffast-math -D_REENTRANT
fsigned-char -std=gnu99";;
+                CFLAGS="-D_REENTRANT -fsigned-char -std=gnu99"
+                PROFILE="-pg -g -D_REENTRANT -fsigned-char std=gnu99";;

(and same for the configure) Why? It's 100% needed!!!

With what I did, dh_autoreconf isn't needed anymore. dh_autoreconf is
overly complicated, and it's nice to be able to avoid it.

Anyway, that's *not* what is needed for this package. What Debian needs
is fixing the RC bugs, and here, by removing my patch, you are readding
an issue that I've fixed!!! :)

>> Clint: *never* again ask me to hold on an upload, and especially not
>> because of an Ubuntu reason. I wont do that again. That's a very bad
>> idea, which have bring hate from others.
> 
> I'm not sure what you mean. I asked you to please delay uploading it to
> unstable 2 weeks before the release of 11.04 as there were other bugs
> pending and the upload was not urgent. It was just a courtesy, and you
> agreed experimental was a better place anyway because of the libdbi0-dev
> to libdbi-dev transition.
> 
> I'm sorry if this caused you any trouble, but it sounded like a good plan
> and something we both agreed upon.

It did sound good, but it turned out to be a horrible mistake. I should
have upload to Experimental as well before the release of Squeeze.

> I'd be more than happy to participate in this maintenance if you feel my
> input would be helpful! :)

I do think we did some nice work 8 months ago adding the test suite to
libdbi-drivers.

Thomas

Re: [libdbi-devel] libdbi maintainership needs help

[Clint B. <cl...@ub...>]

Excerpts from Thomas Goirand's message of Tue Jul 12 15:34:05 +0200 2011:
> Cc: Clint Byrum who maintains the package in Ubuntu.
> 
> On 07/12/2011 08:01 PM, Angel Abad wrote:
> > Hi Thomas, Im Angel Abad, Im Debian Maintainer and Ubuntu Developer.
> > 
> > Im not use libdbi, but I think I can help you to improve the package
> > and get it in better shape.
> 
> Basically, we need to close the current bugs, and manage the transition
> in Debian. Also, I disabled the postgress test suite from
> libdbi-drivers, it would be great to re-enable it (but I have no time to
> work on it).
> 
> > I made some probes, and I can help you to run it with dh 7 simplistic
> > (6 lines) debian/rules, switch it to 3.0 (quilt) format, and also make
> > it multi-arch for experimental.
> 
> I don't think you can switch to a simplistic debian/rules style. It will
> simply not work. I tried using the 3.0 (quilt) format, using autreconf
> and other tools, it simply didn't work. I finally ended up making a
> debian/build folder, copy all files there, build, and finally install
> from there. Otherwise, building is modifying so many upstream files,
> which either end up in the diff or in the Git. I think it's very goo
> this way already.
> 

I just tried building the 0.8.4-5 package with minimal rules and 3.0 quilt,
and it built with a couple of extra files (.install files to put the files
in the right place). It also uses dh_autoreconf successfully. See attached
patch.

> As for upstream, I think it would be great if they modified their
> Makefile.am and such so that it would clean things correctly. There's so
> many built files in the original archive ...
> 
> > If you want my help please ping me, and I can send you debdiffs with my changes.
> > 
> > Regards,
> 
> Maybe a git patch would be better.
> 
> On 09/29/2007 07:11 PM, Mario Iseli wrote:
> > On Sat, Sep 29, 2007 at 02:05:09AM +0800, Thomas Goirand wrote:
> >> Hello,
> >
> > Hi Thomas!
> >
> >> Bellow is the mail I received from the upstream of libdbi. The current
> >> maintainer, David Parker, is Cc: to this message, so he can reply if he
> >> is still interested in doing the maintenance.
> >>
> >> If David is not willing to continue maintaining it, I can try to take
> >> over the package.
> >
> > He seems to be inactive for a quite long time. His MIA history is long
> > too. I have orhpaned the package due to this and you can pick up the
> > package if you want to maintain it. :)
> >
> > Regards,
> 
> Exactly! I pinged him multiple times before I took over the
> maintainer-ship, and had no reply. So I took over, because nobody did,
> and it was one of the reverse-dependency of mod_sql. But I don't really
> use libdbi. So I maintained it basically to help others, and finally, I
> didn't do a good job. Mainly, the issue is the time it took to manage
> issues (others complained about it), and this is what I want to avoid in
> the near future, which is why I wrote this email to -release and -devel.
> I didn't even keep him on Cc: to this email...
> 
> Clint: *never* again ask me to hold on an upload, and especially not
> because of an Ubuntu reason. I wont do that again. That's a very bad
> idea, which have bring hate from others.

I'm not sure what you mean. I asked you to please delay uploading it to
unstable 2 weeks before the release of 11.04 as there were other bugs
pending and the upload was not urgent. It was just a courtesy, and you
agreed experimental was a better place anyway because of the libdbi0-dev
to libdbi-dev transition.

I'm sorry if this caused you any trouble, but it sounded like a good plan
and something we both agreed upon.

> 
> Now, at this point, if we have enough volunteer, I think we should build
> a project and a mailing list in Alioth, so that we can maintain
> collectively. At least, it should be moved to colab-maint. Feel free to
> pull from my repository:
> 
> Vcs-Browser: http://git.debian.org/?p=users/zigo/libdbi.git
> Vcs-Git: http://git.debian.org/git/users/zigo/libdbi.git
> 
> and push that in colab-maint. Note that there's currently 4 branches, to
> track upstream code vs the Debian additions in different releases:
> debian-sid, debian-squeeze, upstream-sid, upstream-squeeze.

I'd be more than happy to participate in this maintenance if you feel my
input would be helpful! :)

Re: [libdbi-devel] libdbi maintainership needs help

[Angel A. <ang...@ub...>]

Hi!

2011/7/12 Thomas Goirand <zi...@de...>:
> Cc: Clint Byrum who maintains the package in Ubuntu.
>
> On 07/12/2011 08:01 PM, Angel Abad wrote:
>> Hi Thomas, Im Angel Abad, Im Debian Maintainer and Ubuntu Developer.
>>
>> Im not use libdbi, but I think I can help you to improve the package
>> and get it in better shape.
>
> Basically, we need to close the current bugs, and manage the transition
> in Debian. Also, I disabled the postgress test suite from
> libdbi-drivers, it would be great to re-enable it (but I have no time to
> work on it).

Ok, I'll take a look!

>> I made some probes, and I can help you to run it with dh 7 simplistic
>> (6 lines) debian/rules, switch it to 3.0 (quilt) format, and also make
>> it multi-arch for experimental.
>
> I don't think you can switch to a simplistic debian/rules style. It will
> simply not work. I tried using the 3.0 (quilt) format, using autreconf
> and other tools, it simply didn't work. I finally ended up making a
> debian/build folder, copy all files there, build, and finally install
> from there. Otherwise, building is modifying so many upstream files,
> which either end up in the diff or in the Git. I think it's very goo
> this way already.
>
> As for upstream, I think it would be great if they modified their
> Makefile.am and such so that it would clean things correctly. There's so
> many built files in the original archive ...

I modified it and it works for me, Im preparing git-patch but git
repository is outdated, could you push changes?

Other thing, is necessary make autoreconf? isnt enough updating
config.sub and config.guess?

Regards,

>> If you want my help please ping me, and I can send you debdiffs with my changes.
>>
>> Regards,
>
> Maybe a git patch would be better.
>
> On 09/29/2007 07:11 PM, Mario Iseli wrote:
>> On Sat, Sep 29, 2007 at 02:05:09AM +0800, Thomas Goirand wrote:
>>> Hello,
>>
>> Hi Thomas!
>>
>>> Bellow is the mail I received from the upstream of libdbi. The current
>>> maintainer, David Parker, is Cc: to this message, so he can reply if he
>>> is still interested in doing the maintenance.
>>>
>>> If David is not willing to continue maintaining it, I can try to take
>>> over the package.
>>
>> He seems to be inactive for a quite long time. His MIA history is long
>> too. I have orhpaned the package due to this and you can pick up the
>> package if you want to maintain it. :)
>>
>> Regards,
>
> Exactly! I pinged him multiple times before I took over the
> maintainer-ship, and had no reply. So I took over, because nobody did,
> and it was one of the reverse-dependency of mod_sql. But I don't really
> use libdbi. So I maintained it basically to help others, and finally, I
> didn't do a good job. Mainly, the issue is the time it took to manage
> issues (others complained about it), and this is what I want to avoid in
> the near future, which is why I wrote this email to -release and -devel.
> I didn't even keep him on Cc: to this email...
>
> Clint: *never* again ask me to hold on an upload, and especially not
> because of an Ubuntu reason. I wont do that again. That's a very bad
> idea, which have bring hate from others.
>
> Now, at this point, if we have enough volunteer, I think we should build
> a project and a mailing list in Alioth, so that we can maintain
> collectively. At least, it should be moved to colab-maint. Feel free to
> pull from my repository:
>
> Vcs-Browser: http://git.debian.org/?p=users/zigo/libdbi.git
> Vcs-Git: http://git.debian.org/git/users/zigo/libdbi.git
>
> and push that in colab-maint. Note that there's currently 4 branches, to
> track upstream code vs the Debian additions in different releases:
> debian-sid, debian-squeeze, upstream-sid, upstream-squeeze.
>
> Thomas
>



-- 
Angel Abad
ang...@gm... | ang...@ub... | ang...@fs...
http://www.pastelero.net
FPR: EBF6 080D 59D4 008A DF47  00D4 098D AE47 EE3B C279

Re: [libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Holger H. <oz...@me...>]

Am Mittwoch, den 27.04.2011, 09:20 +0200 schrieb Markus Hoenicka:
> Toby Thain <to...@te...> was heard to say:
> 
> >> I have time pressure on my current project, and getting the milliseconds
> >> is not crucial, so I can forward now with a time_t. After that, I would
> >> like to look deeper at libDBI and create patches to return any value as
> >> a string representation. Would that be a good idea?
> >>
> >> Holger
> >>
> 
> Hi,
> 
> seems I've missed the start of this thread, so please excuse me for  
> jumping in late. Please have a look at the current CVS revision. We do  
> have the following functions here:
> 
> /* get_as* functions */
> long long dbi_result_get_as_longlong(dbi_result Result, const char  
> *fieldname);
> long long dbi_result_get_as_longlong_idx(dbi_result Result, unsigned  
> int fieldidx);
> char *dbi_result_get_as_string_copy(dbi_result Result, const char *fieldname);
> char *dbi_result_get_as_string_copy_idx(dbi_result Result, unsigned  
> int fieldidx);
> 
> They do pretty much of what was asked for. I can't recall the details  
> atm, but the first two functions try hard to return an integer  
> representation of whatever was stored in the column, and the remaining  
> two functions return a string representation. You might give that a  
> try and see if you can get your TIMESTAMP data in a useful form. If  
> not, feel free to submit specific patches that implement the missing  
> functionality.
> 
> Once again, I have to apologize that I won't be able to take care of  
> the release process for another month or two due to time constraints.

Thank you so much, Markus.

I have no time to check the svn code at the moment, but I'll sure do
after the pressure on my project is gone. And yes, it looks like these
are exactly the functions I require. I can, after my milestone, test
these functions for you. Anything else I can help to bring a new libDBI
release forward?

Holger


> 
> regards,
> Markus
> 
> 

Re: [libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Markus H. <mar...@mh...>]

Toby Thain <to...@te...> was heard to say:

>> I have time pressure on my current project, and getting the milliseconds
>> is not crucial, so I can forward now with a time_t. After that, I would
>> like to look deeper at libDBI and create patches to return any value as
>> a string representation. Would that be a good idea?
>>
>> Holger
>>

Hi,

seems I've missed the start of this thread, so please excuse me for  
jumping in late. Please have a look at the current CVS revision. We do  
have the following functions here:

/* get_as* functions */
long long dbi_result_get_as_longlong(dbi_result Result, const char  
*fieldname);
long long dbi_result_get_as_longlong_idx(dbi_result Result, unsigned  
int fieldidx);
char *dbi_result_get_as_string_copy(dbi_result Result, const char *fieldname);
char *dbi_result_get_as_string_copy_idx(dbi_result Result, unsigned  
int fieldidx);

They do pretty much of what was asked for. I can't recall the details  
atm, but the first two functions try hard to return an integer  
representation of whatever was stored in the column, and the remaining  
two functions return a string representation. You might give that a  
try and see if you can get your TIMESTAMP data in a useful form. If  
not, feel free to submit specific patches that implement the missing  
functionality.

Once again, I have to apologize that I won't be able to take care of  
the release process for another month or two due to time constraints.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Toby T. <to...@te...>]

On 26/04/11 3:02 PM, Holger Hetterich wrote:
> Am Montag, den 25.04.2011, 19:50 -0400 schrieb Toby Thain:
>> On 25/04/11 5:47 PM, Holger Hetterich wrote:
>>> Hi,
>>>
>>> In postgresql I store data of type "timestamp" such as:
>>> "2011-04-17 12:58:51.074"
>>>
>>> While the database can handle this format, and for example correctly
>>> sorts while taking care of the milliseconds, it looks to me it's
>>> impossible to retrieve this data via libDBI. What I found was the
>>> get_datetime functions, which return a time_t. Any way to get the
>>> information about the milliseconds, _or_ get a string or binary
>>> representation of what is stored in the DB, so that I can convert it
>>> back to a string on the client side?
>>>
>>
>> Indeed, a function to retrieve this as a string is needed. It's really
>> an error for the library to treat it like a time_t; I think the MySQL
>> DATE/TIME types come back as strings (but don't quote me; it's a long
>> time since I used libdbi).
> 
> libDBI is so cool, I think it's worth to extend libDBI with functions to
> return DB data as a string representation in general.
> 

On this list, I've proposed something similar in the past (a
"type-coercing" interface). It is even more important for integer types,
as you see from your other posting recently on the list. (I think there
should be an additional facility to fetch an integer without knowing the
precise storage type; this facilitates database and schema independence.)

In many cases strings are already returned for data types that have no
natural C representation (DATE/TIME as I mentioned, DECIMAL, ENUM, and
so on), so I consider your specific issue here more of a bug than a
missing function (since the time_t conversion makes no sense - but I
haven't checked the code to see what's going on).

--Toby


> I have time pressure on my current project, and getting the milliseconds
> is not crucial, so I can forward now with a time_t. After that, I would
> like to look deeper at libDBI and create patches to return any value as
> a string representation. Would that be a good idea?
> 
> Holger
> 
> 
> 
>>
>> --Toby
>>
>>
>>> Or maybe I oversee a useful function to get to this information...
>>>
>>> Holger
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> WhatsUp Gold - Download Free Network Management Software
>>> The most intuitive, comprehensive, and cost-effective network 
>>> management toolset available today.  Delivers lowest initial 
>>> acquisition cost and overall TCO of any competing solution.
>>> http://p.sf.net/sfu/whatsupgold-sd
>>> _______________________________________________
>>> libdbi-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network 
>> management toolset available today.  Delivers lowest initial 
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> libdbi-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> 
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> 

Re: [libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Holger H. <oz...@me...>]

Am Montag, den 25.04.2011, 19:50 -0400 schrieb Toby Thain:
> On 25/04/11 5:47 PM, Holger Hetterich wrote:
> > Hi,
> > 
> > In postgresql I store data of type "timestamp" such as:
> > "2011-04-17 12:58:51.074"
> > 
> > While the database can handle this format, and for example correctly
> > sorts while taking care of the milliseconds, it looks to me it's
> > impossible to retrieve this data via libDBI. What I found was the
> > get_datetime functions, which return a time_t. Any way to get the
> > information about the milliseconds, _or_ get a string or binary
> > representation of what is stored in the DB, so that I can convert it
> > back to a string on the client side?
> > 
> 
> Indeed, a function to retrieve this as a string is needed. It's really
> an error for the library to treat it like a time_t; I think the MySQL
> DATE/TIME types come back as strings (but don't quote me; it's a long
> time since I used libdbi).

libDBI is so cool, I think it's worth to extend libDBI with functions to
return DB data as a string representation in general.

I have time pressure on my current project, and getting the milliseconds
is not crucial, so I can forward now with a time_t. After that, I would
like to look deeper at libDBI and create patches to return any value as
a string representation. Would that be a good idea?

Holger



> 
> --Toby
> 
> 
> > Or maybe I oversee a useful function to get to this information...
> > 
> > Holger
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > WhatsUp Gold - Download Free Network Management Software
> > The most intuitive, comprehensive, and cost-effective network 
> > management toolset available today.  Delivers lowest initial 
> > acquisition cost and overall TCO of any competing solution.
> > http://p.sf.net/sfu/whatsupgold-sd
> > _______________________________________________
> > libdbi-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> > 
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel

Re: [libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Toby T. <to...@te...>]

On 25/04/11 5:47 PM, Holger Hetterich wrote:
> Hi,
> 
> In postgresql I store data of type "timestamp" such as:
> "2011-04-17 12:58:51.074"
> 
> While the database can handle this format, and for example correctly
> sorts while taking care of the milliseconds, it looks to me it's
> impossible to retrieve this data via libDBI. What I found was the
> get_datetime functions, which return a time_t. Any way to get the
> information about the milliseconds, _or_ get a string or binary
> representation of what is stored in the DB, so that I can convert it
> back to a string on the client side?
> 

Indeed, a function to retrieve this as a string is needed. It's really
an error for the library to treat it like a time_t; I think the MySQL
DATE/TIME types come back as strings (but don't quote me; it's a long
time since I used libdbi).

--Toby


> Or maybe I oversee a useful function to get to this information...
> 
> Holger
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> 

[libdbi-devel] libDBI (or ) pgsql driver: question on "timestamp"

[Holger H. <oz...@me...>]

Hi,

In postgresql I store data of type "timestamp" such as:
"2011-04-17 12:58:51.074"

While the database can handle this format, and for example correctly
sorts while taking care of the milliseconds, it looks to me it's
impossible to retrieve this data via libDBI. What I found was the
get_datetime functions, which return a time_t. Any way to get the
information about the milliseconds, _or_ get a string or binary
representation of what is stored in the DB, so that I can convert it
back to a string on the client side?

Or maybe I oversee a useful function to get to this information...

Holger

Re: [libdbi-devel] dbi_result_get_int_idx

[Holger H. <oz...@me...>]

Am Freitag, den 15.04.2011, 23:10 +0200 schrieb
mar...@mh...:
> unsigned int attribs;
> attribs = dbi_result_get_field_attribs_idx(data, 1);
> 
> 

Yeah this works. It's a 64bit long long type. Thank you so much Markus.

BTW, big thanks to you and the other developers involved, libdbi is
absolutely great!

Holger