jian he <jian.universal...@gmail.com> writes: > On Thu, Jan 18, 2024 at 4:17 PM Peter Eisentraut <pe...@eisentraut.org> wrote: >> Reading back through the discussion, I wasn't quite able to interpret >> the resolution regarding Oracle compatibility. From the patch, it looks >> like you chose not to adopt the parameter names from Oracle. Was that >> your intention?
> per committee message: > https://git.postgresql.org/cgit/postgresql.git/commit/?id=6424337073589476303b10f6d7cc74f501b8d9d7 > Even if the names are all the same, our function is still not the same > as oracle. The fact that there's minor discrepancies in the regex languages doesn't seem to me to have a lot of bearing on whether we should follow Oracle's choices of parameter names. However, if we do follow Oracle, it seems like we should do that consistently, which this patch doesn't. For instance, per [1] Oracle calls the arguments of regex_substr source_char, pattern, position, occurrence, match_param, subexpr while we have string, pattern, start, N, flags, subexpr The patch proposes to replace "N" with "occurrence" but not touch the other discrepancies, which seems to me to be a pretty poor choice. "occurrence" is very long and difficult to spell correctly, and if you're not following Oracle slavishly, exactly what is the argument in its favor? I quite agree that Oracle's other choices aren't improvements over ours, but neither is that one. On the whole my inclination would be to stick to the names we have in the documentation. There might be an argument for changing "N" to something lower-case so you don't have to quote it; but if we do, I'd go for, say, "count". regards, tom lane [1] https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/REGEXP_SUBSTR.html#GUID-2903904D-455F-4839-A8B2-1731EF4BD099
