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
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? |