Re: COMPARE_POINTER_FIELD been dead 13 years after living 2 weeks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COMPARE_POINTER_FIELD been dead 13 years after living 2 weeks
Date: 2015-09-21 19:09:11
Message-ID: 6261.1442862551@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I happened to notice that we have a macro COMPARE_POINTER_FIELD in
> nodes/equalfuncs.c that Tom introduced in 2eafcf68d563d (25 Nov 2002)
> and then removed its only callers a0bf885f9ea (12 Dec 2002).

Hm. I think it was meant to correspond to copyfuncs.c's
COPY_POINTER_FIELD() macro. The reason it's unused at the moment is
that the only node types where that macro is needed are Plan subtypes,
and we don't have infrastructure for comparing plan trees.

If someone were to introduce a similar data representation into a
parsetree node type, then we'd need this macro ... but then we would
probably also need outfuncs.c and readfuncs.c infrastructure for the
representation, which very possibly explains why there are no such cases;
it's just a lot easier to use an OID list or suchlike, if you need to
provide such support.

> Should we just remove it?

Perhaps. It's not really doing any harm ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-09-21 19:16:02 COPY planning
Previous Message Tom Lane 2015-09-21 19:01:53 Re: TEXT vs VARCHAR join qual push down diffrence, bug or expected?