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
Re: User locks code |
Список | 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 по дате отправления: