In trying to decide how to keep ODBC compilable standalone, I can't
figure out how to get md5.c in there from backend/libpq.  Is it crazy to
put md5.c in interfaces/odbc and symlink it from there to backend/libpq
and interfaces/libpq?  I don't want to have two copies of md5.c but that
may be another option.  Opinions?

-- 
  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

Sat, 25 Aug 2001 15:06:46 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
linking hba.c
> In trying to decide how to keep ODBC compilable standalone, I can't
> figure out how to get md5.c in there from backend/libpq.  Is it crazy to
> put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> and interfaces/libpq?  I don't want to have two copies of md5.c but that
> may be another option.  Opinions?
>

Seems to me that a stand-alone driver would have to have its own md5.c....
otherwise you may as well start linking in all kinds of code from the
distro. Of course that is what just about all other ODBC drivers do anyway.

Peter



Sat, 25 Aug 2001 12:26:11 -0700
Peter Harvey <pharvey@codebydesign.com>
Re: linking hba.c
> > In trying to decide how to keep ODBC compilable standalone, I can't
> > figure out how to get md5.c in there from backend/libpq.  Is it crazy to
> > put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> > and interfaces/libpq?  I don't want to have two copies of md5.c but that
> > may be another option.  Opinions?
> >
> 
> Seems to me that a stand-alone driver would have to have its own md5.c....
> otherwise you may as well start linking in all kinds of code from the
> distro. Of course that is what just about all other ODBC drivers do anyway.

If we want to have only one copy of md5.c, and we want ODBC to be
standalone, the only way I can think to do it is to link the _other_
uses of md5.c back to interfaces/odbc/md5.c

-- 
  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

Sat, 25 Aug 2001 16:15:42 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: linking hba.c
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> In trying to decide how to keep ODBC compilable standalone, I can't
> figure out how to get md5.c in there from backend/libpq.

AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it
depend on our toplevel configure script now?

> Is it crazy to
> put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> and interfaces/libpq?

YES, that's crazy.  If you think ODBC should build separately, then give
it its own copy of md5.c.  But please first check that your assumption
is still valid.

			regards, tom lane

Sat, 25 Aug 2001 19:18:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: linking hba.c 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > In trying to decide how to keep ODBC compilable standalone, I can't
> > figure out how to get md5.c in there from backend/libpq.
> 
> AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it
> depend on our toplevel configure script now?

The Unix version is not compilable on its own, but I see no code in
win32.mak that refers to upper directories.

> 
> > Is it crazy to
> > put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> > and interfaces/libpq?
> 
> YES, that's crazy.  If you think ODBC should build separately, then give
> it its own copy of md5.c.  But please first check that your assumption
> is still valid.

And I will just throw a note at the top of each mentioning they should
be identical.

-- 
  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

Sat, 25 Aug 2001 19:26:42 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: linking hba.c
Bruce Momjian wrote:
> 
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > In trying to decide how to keep ODBC compilable standalone, I can't
> > > figure out how to get md5.c in there from backend/libpq.
> >
> > AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it
> > depend on our toplevel configure script now?
> 
> The Unix version is not compilable on its own, but I see no code in
> win32.mak that refers to upper directories.

Yes. 
 
> >
> > > Is it crazy to
> > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> > > and interfaces/libpq?
> >
> > YES, that's crazy.  If you think ODBC should build separately, then give
> > it its own copy of md5.c.  But please first check that your assumption
> > is still valid.
> 
> And I will just throw a note at the top of each mentioning they should
> be identical.

Is it that easy to copy md5.c ?
ms5.c includes postgres.h and libpq/crypt.h.
I prefer to have e.g. md5.dll.

regards,
Hiroshi Inoue

Mon, 27 Aug 2001 10:54:58 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: linking hba.c
> > > > Is it crazy to
> > > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> > > > and interfaces/libpq?
> > >
> > > YES, that's crazy.  If you think ODBC should build separately, then give
> > > it its own copy of md5.c.  But please first check that your assumption
> > > is still valid.
> > 
> > And I will just throw a note at the top of each mentioning they should
> > be identical.
> 
> Is it that easy to copy md5.c ?
> ms5.c includes postgres.h and libpq/crypt.h.
> I prefer to have e.g. md5.dll.

There is not much there.  I can use a -Ddefine in ODBC and just
conditionally define what I need when I am compiling in ODBC.  Isn't
worth a DLL.

Can you help me add MD5 to ODBC?  I am getting lost in the way they do
passwords, and I don't even have a MSWin machine to test it once I am
done.

-- 
  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

Sun, 26 Aug 2001 22:45:37 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: linking hba.c