On 2/11/16 1:27 AM, Pavel Stehule wrote:
> 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.
> 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.
--
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