Обсуждение: too many variants of relation_open

Поиск
Список
Период
Сортировка

too many variants of relation_open

От
"Jaime Casanova"
Дата:
Hi,

I can understand why we have relation_openrv and try_relation_open,
but relation_open_nowait can be merged with relation_open.

Or there is something i'm missing? attached is a patch that do the merge.

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

Вложения

Re: too many variants of relation_open

От
Heikki Linnakangas
Дата:
Jaime Casanova wrote:
> I can understand why we have relation_openrv and try_relation_open,
> but relation_open_nowait can be merged with relation_open.

Well, yes it could, but why? Keeping them separate looks slightly more
readable to me, and the change could break a lot of external modules for
no good reason.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Re: too many variants of relation_open

От
Neil Conway
Дата:
On Fri, 2007-09-28 at 10:02 +0100, Heikki Linnakangas wrote:
> Well, yes it could, but why? Keeping them separate looks slightly more
> readable to me, and the change could break a lot of external modules for
> no good reason.

I agree: it also complicates the common case (calling relation_open()
and waiting to acquire for a lock).

If anything, you could perhaps refactor relation_open_nowait() to be
implemented in terms of relation_open() (first try to get the lock, then
do a relation_open(rel, NoLock)), but since you'd only be saving a
handful of duplicated lines, it hardly seems worth it.

-Neil