Re: User locks code

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

In response to

Browse pgsql-hackers by date

  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