Re: Bug: PGTYPEStimestamp_from_asc() in ECPG pgtypelib

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