Re: Possible bug in ECPGlib thread-safety (Postgres
| От | Philip Yarra |
|---|---|
| Тема | Re: Possible bug in ECPGlib thread-safety (Postgres |
| Дата | |
| Msg-id | 200312161256.12516.philip@utiba.com обсуждение |
| Ответ на | Re: Possible bug in ECPGlib thread-safety (Postgres (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Ответы |
Re: Possible bug in ECPGlib thread-safety (Postgres
|
| Список | pgsql-interfaces |
On Tue, 16 Dec 2003 12:28 pm, Bruce Momjian wrote: > > I thinks it's a worthy feature, but perhaps the pre-compiler should warn > > people that they are relying on non-standard behaviour? > > Maybe we could just document its thread-safety as non-standard. Yes, but my concern is that poor suckers who try to port their code to other DBs won't be going and reading the PostgreSQL doco to figure out why their code goes suddenly goes "thud!" Maybe an additional flag for the pre-compiler to turn the warning off (how about '--fast-and-loose-thread-behaviour', '-f' for short ?) would stop it driving regular users mad, while alerting newer ECPG users that they are relying on an extension that might cause portability issues. > It would cause people moving _from_ PostgreSQL, but no one does that, of > course. :-) Not voluntarily, anyway. Off-topic: having suffered the ravages of Sybase's isql lately, I've been sorely tempted to add a Sybase-compatibility layer to psql. I don't know what would be involved (a lot, I imagine) but it's tempting. > that AT clause is annoying people Yes, it's a pain, but multi-threaded apps are more work anyway - I don't think "AT conn_name" is as onerous as pthread_mutex_lock()ing, which they will (hopefully) be doing a fair bit of. Don't get me wrong, the thread-safe extension would be nice, I'd just hate to see people rely on it without being aware of the portability cost. Philip.
В списке pgsql-interfaces по дате отправления: