RE: User locks code

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>
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:55:29
Message-ID: 3705826352029646A3E91C53F7189E32016750@sectorbase2.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Ah, ok.

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

Ok, let's do one step back - you wrote:

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

So, one would have to open-source and GPL all procedures/triggers
used by application just because of application uses user_lock()
in queries?! Is it good?

Vadim

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-08-24 00:11:38 Re: User locks code
Previous Message Bruce Momjian 2001-08-23 23:34:40 Re: User locks code