[PATCHES] MD5 support for ODBC

Bruce Momjian wrote:

The attached patch should add MD5 support to ODBC. I don't have ODBC
here so I would appreciate if someone would test it and let me know. I
am not considering applying the patch to CVS.

I checked it under Windows and it worked well.
I already committed the interfaces/odbc part.

Thanks.
Hiroshi Inoue

Bruce Momjian wrote:

The attached patch should add MD5 support to ODBC. I don't have ODBC
here so I would appreciate if someone would test it and let me know. I
am not considering applying the patch to CVS.

I checked it under Windows and it worked well.
I already committed the interfaces/odbc part.

OK, great. I am surprised it worked the first time. I didn't test it
here, and I am know more for my persistance than skill. :-)

I have applied the rest of the patch. It adds a check to the
backend/libpq Makefile and aborts if the two C md5.c files are not
identical.

There are two copies of md5.c because odbc has to be compile-able on its
own, and md5.c is also used by the backend and libpq. With this check,
the two files will remain in sync because it will not even compile if
they aren't.

Also, odbc/md5.h has copies of certain definitions that normally appear
in include/c.h. Because md5.c must compile alone in the odbc directory,
I needed those defines pulled out and added into odbc. I will document
that these defines also appear in odbc/md5.h.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

! all: check_md5 SUBSYS.o
!
! check_md5:
! @cmp -s md5.c ../../interfaces/odbc/md5.c || \
! (echo "src/interfaces/odbc/md5.c doesn't match src/backend/libpq/md5.c" && \
! exit 1)

Nope, this doesn't work. The source directory is not necessarily the
current directory.

OK, I will remove it. However, many of our Makefiles that do ../.. so I
assume they have to assume which directory they are in, i.e, from
libpq/Makefile:

subdir = src/interfaces/libpq
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global

Also, should we add such checks to the other files that must remain
identical?

I don't think it's particularly useful to put checks of static source
files in the build path. There are quite a number of places that need to
be synchronized manually and there is no check anywhere. It would
probably have been better to have one master copy of the file and symlink
it to whereever else it is needed. (See libpq Makefile for several
examples.)

Yes, I already do a symlink for md5.c in libpq. The problem is that
ODBC has to compile stand-alone, with no reference to any outside
directory. I assume that includes symlinks so you can take just /odbc,
put it on a Win32 partition, and compile it. I don't want md5.c to
change that capability.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

! all: check_md5 SUBSYS.o
!
! check_md5:
! @cmp -s md5.c ../../interfaces/odbc/md5.c || \
! (echo "src/interfaces/odbc/md5.c doesn't match src/backend/libpq/md5.c" && \
! exit 1)

Nope, this doesn't work. The source directory is not necessarily the
current directory.

I don't think it's particularly useful to put checks of static source
files in the build path. There are quite a number of places that need to
be synchronized manually and there is no check anywhere. It would
probably have been better to have one master copy of the file and symlink
it to whereever else it is needed. (See libpq Makefile for several
examples.)

--
Peter Eisentraut peter_e@gmx.net

Bruce Momjian wrote:

I don't think it's particularly useful to put checks of static source
files in the build path. There are quite a number of places that need to
be synchronized manually and there is no check anywhere. It would
probably have been better to have one master copy of the file and symlink
it to whereever else it is needed. (See libpq Makefile for several
examples.)

Yes, I already do a symlink for md5.c in libpq. The problem is that
ODBC has to compile stand-alone, with no reference to any outside
directory. I assume that includes symlinks so you can take just /odbc,
put it on a Win32 partition, and compile it. I don't want md5.c to
change that capability.

Yes I don't love any reference to any outside directory.
If a backward incompatible change is made, I don't use
it exactly any longer.

regards,
Hiroshi Inoue

Bruce Momjian wrote:

I don't think it's particularly useful to put checks of static source
files in the build path. There are quite a number of places that need to
be synchronized manually and there is no check anywhere. It would
probably have been better to have one master copy of the file and symlink
it to whereever else it is needed. (See libpq Makefile for several
examples.)

Yes, I already do a symlink for md5.c in libpq. The problem is that
ODBC has to compile stand-alone, with no reference to any outside
directory. I assume that includes symlinks so you can take just /odbc,
put it on a Win32 partition, and compile it. I don't want md5.c to
change that capability.

Yes I don't love any reference to any outside directory.
If a backward incompatible change is made, I don't use
it exactly any longer.

I will keep it as you see it now --- a separate file in /odbc.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

Nope, this doesn't work. The source directory is not necessarily the
current directory.

OK, I will remove it. However, many of our Makefiles that do ../..

The *build* directory is always the current directory, so '..' stuff is
okay to refer to built files. But to reference source files you need to
start with $(srcdir) or $(top_srcdir), whichever is convenient.

Also, should we add such checks to the other files that must remain
identical?

I don't think we have any others that must remain identical per se.

In general, checks for source code sanity are okay, but if you want them
in a makefile they should be under the maintainer-check target, not in the
build path. However, since there is very little that merits an automated
check of this sort, I doubt very many people would actually run this
target.

Yes, I already do a symlink for md5.c in libpq. The problem is that
ODBC has to compile stand-alone, with no reference to any outside
directory.

Okay, that's reasonable. I think making a note in the file under odbc/
should be sufficient. Possibly include which CVS revision of the original
the copy is based on, so one can see when it needs updating. Also, a note
in the venerable RELEASE_CHANGES file seems appropriate.

--
Peter Eisentraut peter_e@gmx.net

Bruce Momjian writes:

Nope, this doesn't work. The source directory is not necessarily the
current directory.

OK, I will remove it. However, many of our Makefiles that do ../..

The *build* directory is always the current directory, so '..' stuff is
okay to refer to built files. But to reference source files you need to
start with $(srcdir) or $(top_srcdir), whichever is convenient.

Oh, OK.

Also, should we add such checks to the other files that must remain
identical?

I don't think we have any others that must remain identical per se.

In general, checks for source code sanity are okay, but if you want them
in a makefile they should be under the maintainer-check target, not in the
build path. However, since there is very little that merits an automated
check of this sort, I doubt very many people would actually run this
target.

OK, removed.

Yes, I already do a symlink for md5.c in libpq. The problem is that
ODBC has to compile stand-alone, with no reference to any outside
directory.

Okay, that's reasonable. I think making a note in the file under odbc/
should be sufficient. Possibly include which CVS revision of the original
the copy is based on, so one can see when it needs updating. Also, a note
in the venerable RELEASE_CHANGES file seems appropriate.

I am not sure if it is even worth it there. I can't imagine anyone
changing md5.c anyway.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026