Обсуждение: Question about an inconsistency - 1
Hi,<div class=""><br class="" /></div><div class="">I have a question regarding the source code in file pg_proc.h (postgresql-9.4.4).</div><divclass=""><br class="" /></div><div class="">At line 1224 (copied below) why the 28th identifieris timestamp_eq?</div><div class=""><br class="" /></div><div class=""><div class="" style="margin: 0px; font-size:11px; line-height: normal; font-family: Monaco;">DATA(insert OID = 1152 ( timestamptz_eq PGNSP PGUID 12 1 00 0 f f f t t f i 2 0 16 <span class="" style="color: #3933ff">"1184 1184"</span> _null_ _null_ _null_ _null_ timestamp_eq_null_ _null_ _null_ ));</div></div><div class=""><div class=""><span class="" style="font-size: 11px;"><br class=""/></span></div><div class="">I would expect it to be timestamptz_eq (the same as the 5th identifier from the sameline). Shouldn't it be the same </div></div><div class="">like in the line 2940 copied also below having the same identifierin the 28th and 5th positions (timestamp_eq)?</div><div class=""><span class="" style="font-size: 11px;"><br class=""/></span></div><div class=""><div class="" style="margin: 0px; font-size: 11px; line-height: normal; font-family:Monaco;">DATA(insert OID = 2052 ( timestamp_eq<span class="Apple-tab-span" style="white-space:pre"> </span>PGNSPPGUID 12 1 0 0 0 f f f t t f i 2 0 16 <span class="" style="color: #3933ff">"1114 1114"</span> _null_ _null__null_ _null_ timestamp_eq _null_ _null_ _null_ ));</div></div><div class=""><br class="" /></div><div class="">A similarquestion can be asked for lines 1225 to 1229 (but for their specific identifiers).</div><div class=""><br class=""/></div><div class="">Regards,</div><div class="">Pepi</div>
"petrum@gmail.com" <petrum@gmail.com> writes:
> I have a question regarding the source code in file pg_proc.h (postgresql-9.4.4).
> At line 1224 (copied below) why the 28th identifier is timestamp_eq?
> DATA(insert OID = 1152 ( timestamptz_eq PGNSP PGUID 12 1 0 0 0 f f f t t f i 2 0 16 "1184 1184" _null_ _null_
_null__null_ timestamp_eq _null_ _null_ _null_ ));
> I would expect it to be timestamptz_eq (the same as the 5th identifier
> from the same line).
If timestamptz_eq actually existed as a separate C function, then yes that
would be correct. But see this bit in timestamp.h:
extern int timestamp_cmp_internal(Timestamp dt1, Timestamp dt2);
/* timestamp comparison works for timestamptz also */
#define timestamptz_cmp_internal(dt1,dt2) timestamp_cmp_internal(dt1, dt2)
AFAICS there are not similar #defines equating timestamptz_eq to
timestamp_eq and so on, probably because we don't have much need
to refer to those functions in the C code. But even if we had
such #defines, I think that pg_proc.h could not rely on them.
It has to reference actual C functions.
regards, tom lane
Hi, In file postgresql-9.4.4/src/backend/utils/adt/format_type.c function format_type_internal line 159, shouldn’t be used array_base_type instead of type_oid? In line 153 it is searched for array_base_type and thus shouldn’t we use it (ie., array_base_type) to report that the type is not found. It is similar to the case of searching for type_oid in lines 129-135. Thanks, Petru Florin Mihancea
<br class="" />Hi,<div class=""><br class="" /></div><table cellpadding="0" cellspacing="0" class="first_procedure_tableprocedure_content_table" summary="code listing"><tbody class=""><tr class="filename_row"><tdclass="filename_cell" colspan="5"><span class="" style="font-size: 12px;">In file postgres/postgresql-9.4.4/src/timezone/zic.c</span></td></tr></tbody></table>functionstringzone line 2091we have<div class=""><brclass="" /></div><div class=""><span class="p0 superint_left super_interesting" id="S80"> </span><span class="keywordp1 super_interesting" id="S81">if</span><span class="p3 superint_right super_interesting" id="S82"> (<spanclass="hil_stringrule p5">stringrule</span>(<span class="p16 hil_result">result</span>, <span class="p24hil_stdrp">stdrp</span>, <span class="p31 hil_dstrp">dstrp</span>-><span class="hil_r_stdoff p38">r_stdoff</span>,<span class="p48 hil_zp">zp</span>-><span class="p52 hil_z_gmtoff">z_gmtoff</span>) != <span class="hil_0p65">0</span>)</span></div><div class=""><br class="" /></div><div class="">Is it ok to have as the 3rd argument <spanclass="p31 hil_dstrp">dstrp</span>-><span class="hil_r_stdoff p38">r_stdoff or should we </span></div><divclass=""><span class="hil_r_stdoff p38">have </span><span class="p31 hil_dstrp"><b class="">stdrp</b></span>-><spanclass="hil_r_stdoff p38">r_stdoff? In line 2085 dstrp is used in both arguments.</span></div><divclass=""><br class="" /></div><div class="">Not very sure because I do not understand the semanticsof the </div><div class="">invoked operation, but I thought it would be better to ask.</div><div class=""><div class=""><divclass=""><br class="" /></div></div></div><div class="">Thanks,</div><div class="">Petru Florin Mihancea</div>
"petrum@gmail.com" <petrum@gmail.com> writes:
> In file postgresql-9.4.4/src/backend/utils/adt/format_type.c
> function format_type_internal line 159, shouldn’t be used
> array_base_type instead of type_oid?
IIRC, that was intentional. Supposing there's a pg_type row with
a corrupted typelem value, it's more useful to point at the bogus
row than to report the junk value with no context. I suppose you
could argue that it should be more like
elog(ERROR, "cache lookup failed for type %u (typelem of %u)", array_base_type, type_oid);
regards, tom lane
"petrum@gmail.com" <petrum@gmail.com> writes: > In file postgres/postgresql-9.4.4/src/timezone/zic.c > function stringzone line 2091we have > if (stringrule(result, stdrp, dstrp->r_stdoff, zp->z_gmtoff) != 0) > Is it ok to have as the 3rd argument dstrp->r_stdoff or should we > have stdrp->r_stdoff? In line 2085 dstrp is used in both arguments. Doubt it, because if the coding were like that there would be no need to pass the third argument separately at all; the subroutine could just access rp->r_stdoff for itself. But this isn't our code, so if you want an authoritative answer you should ask athttps://mm.icann.org/mailman/listinfo/tz regards, tom lane