RE: User locks code

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: User locks code
Дата
Msg-id 3705826352029646A3E91C53F7189E32016750@sectorbase2.sectorbase.com
обсуждение исходный текст
Ответ на User locks code  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Ответы Re: User locks code  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: User locks code  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: User locks code
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: User locks code