Re: proposal: function parse_ident

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