Re: Unify drop-by-OID functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unify drop-by-OID functions
Date: 2020-05-05 17:28:58
Message-ID: CA+TgmoYhgjHm6map2pAic=kh-YkEdVzgKsrbi+PmrqizaiKAYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 5, 2020 at 1:22 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must call table_close, after systable_endscan.
> Now (1) and (2), I would have no hesitation in using it.
> I work with ERP, and throughout the time, the later, lock resources and release them soon, the better, for the performance of the system as a whole.
> Even if it doesn't make much difference locally, using this process, throughout the system, efficiency is noticeable.
> Apparently, it is more code, but it is less resources used and for less time.
> And (2), if it is a case, frequently, no table would be blocked in this function.

Nobody here is going to question the concept that it's better to use
resources for less time rather than more, but the wisdom of sticking
to well-established coding patterns instead of inventing altogether
new ones is also well-understood. There are often good reasons why the
code is written in the way that it is, and it's important to
understand those before proposing to change things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2020-05-05 17:42:17 Re: Unify drop-by-OID functions
Previous Message Ranier Vilela 2020-05-05 17:21:36 Re: Unify drop-by-OID functions