Thread

  1. Re: Bug: PGTYPEStimestamp_from_asc() in ECPG pgtypelib

    Ryo Matsumura (Fujitsu) <matsumura.ryo@fujitsu.com> — 2024-05-10T05:45:15Z

    Hi Tom,
    Thank you for comment.
    
    >> At current implementation, PGTYPEStimestamp_from_asc returns -1.
    > It looks to me like it returns 0 ("noresult").  Where are you seeing -1?
    
    I took a mistake. Sorry.
    PGTYPEStimestamp_from_asc returns 0(noresult).
    PGTYPEStimestamp_fmt_asc given 'noresult' returns -1.
    
    
    > But how come we haven't noticed that
    > before?  Have you added a setlocale() call somewhere?
    
    I didn't notice to this point.
    I added setlocale() to ECPG in my local branch.
    I will test again after removing it.
    It looks to me like existing ECPG code does not include setlocale().
    
    So Please ignore about behavior of PGTYPEStimestamp_fmt_asc().
    I want to continue to discuss about PGTYPEStimestamp_from_asc.
    
    
    Current PGTYPEStimestamp_from_asc() returns 0, but should we return -1?
    The document claims about return that "It is set to 1899-12-31 23:59:59.".
    
    I wonder.
    It is the incompatibility, but it may be allowed.
    because I think usual users may check with errno.
    Of course, the reason is weak.
    Some users may check with 0(noresult) from their experience.
    
    
    > That documentation has more problems too: it claims that "endptr"
    > is unimplemented, which looks like a lie to me: the code is there
    > to do it, and there are several callers that depend on it.
    
    I think so too. The followings have the same problem.
    PGTYPESdate_from_asc    (ParseDate)
    PGTYPESinterval_from_asc    (ParseDate)
    PGTYPEStimestamp_from_asc    (ParseDate)
    PGTYPESnumeric_from_asc
    
    
    > which is consistent with that, but not very much like what the
    > comment is expecting.  I'm a bit inclined to just drop "block 3".
    > If we want to keep some kind of test of the error behavior,
    > it doesn't belong right there, and it should be showing what errno
    > gets set to.
    
    It is easy to exchange block3 to errno-checking.
    However if we just fix there, it is weird because there is
    no other errno-checking in dt_tests.
    
    > I'm a bit inclined to just drop "block 3".
    Are you concerned at the above point?
    
    Best Regards
    Ryo Matsumura