MironAtHome commented on issue #1985: URL: https://github.com/apache/age/issues/1985#issuecomment-2243986264
I have 2 separate questions regarding above #1 is_valid_label and #2 label_id_is_valid ( with regards to PG_UINT16_MAX ) I tried best I could to clarify both questions from the start, but it looks like things got a bit clobbered, so, let me try one more attempt. This is only to better clarify and see what your / team thinking is regarding same questions asked above. So, let's start from question number 1 :) Yes, there is a function is_valid_label and, just as you have pointed out, it currently does cater to label name. However, there is one more function, and taking into account function mentioned in your response, age_is_valid_label_name, third function ( 3 for three ). Function number 3 is called is_valid_label_name. Now, if you look into file name_validation.c you will find that it currently carries 2 ( non - static ) functions: Function number 1: is_valid_graph_name Function number 2: is_valid_label So, what I am trying to say is that it would be very - very nice to make functions named consistent, so that both were named according to their function, similarly, and so, after the change the two function names will be Function number 1: is_valid_graph_name Function number 2: is_valid_label_name Please note, an static function with name is_valid_label currently does exist in the unit label_commands.c So, my suggestion is to rename it to is_valid_label and have it cater to label validity. It does make sense to make it available, as part of the interface. Please note, I am not trying to refer to something like naming convention. My hope is to instill consistency into interface. To note, it does make sense to make functions, checking validity of name or object return boolean. Please do accept all what I said with a grain of salt and my apologies ahead of time for redacting away in each sentence "in my opinion", else, this comment will ran twice as long :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@age.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
