From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User locks code |
Date: | 2001-08-23 23:34:40 |
Message-ID: | 200108232334.f7NNYeC23884@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > No, you were clear.
>
> So I missed your "near-zero cost" sentence.
OK.
> > My assumption is that once you link that code into
> > the backend, the entire backend is GPL'ed and any other
> > application code you link into it is also (stored procedures,
> > triggers, etc.) I don't think your client application will
> > be GPL'ed, assuming you didn't link in libreadline.
>
> Application would explicitly call user_lock() functions in
> queries, so issue is still not clear for me. And once again -
Well, yes, it calls user_lock(), but the communication is not OS-linked,
it is linked over a network socket, so I don't think the GPL spreads
over a socket. Just as telnet'ing somewhere an typing 'bash' doesn't
make your telnet GPL'ed, so I think the client code is safe. To the
client, the backend is just returning information. You don't really
link to the query results.
> compare complexities of contrib/userlock and backend' userlock
> code: what's reason to cover contrib/userlock by GPL?
Only because Massimo prefers it. I can think of no other reason. It
clearly GPL-stamps any backend that links it in.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2001-08-23 23:55:29 | RE: User locks code |
Previous Message | Tom Lane | 2001-08-23 23:27:01 | Re: Assessment on namespace clean include file names |