I editorialized the docs and some of the comments. In particular, I documented behavior of not truncating, and recommended casting to name[] if user cares about that. Added a unit test to verify that works. BTW, I saw mention in the thread about not truncated spaces, but the function *does* truncate them, unless they're inside quotes, where they're legitimate.
ok
I missed some of my edits. Updated patch with those in place attached.
Also added test for invalid characters.
I think "strict" would be more in line with other uses in code. There are currently no other occurrences of 'strictmode' in the code. There are loads of references to 'strict', but I didn't go through all of them to see if any were used as externally visible function parameter names.
I am sorry, I don't understand to this point. You unlike the name of parameter "strictmode" ? Have you any proposal? Maybe "restrictive" ?
I would just call it strict. There's precedent for that in the code.
+1
fixed in attached patch
The almost all code +/- is related to human readable error messages. We can move some code to separate static functions - read_quoted_ident, read_unquoted_ident, but there will be some magic about parameters, and the code will not be much better, than it is now.
What I'm saying is that most places that need to do de-quoting or similar just run a simple while loop and use an in_quote variable to track whether they're inside a quote or not. See backend/utils/adt/rowtypes.c line 199 for an example.
As I said, I don't have a strong opinion on it, so if you prefer it this way that's fine with me.
yes, I don't see string differences between for(;;) and break and while(var). I prefer current state.
Regards
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com