eric-maynard commented on PR #1003:
URL: https://github.com/apache/polaris/pull/1003#issuecomment-2664780393

   Non-enumerated keys are certainly rarer, but also impossible to detect if
   we make this change.
   
   On Mon, Feb 17, 2025 at 7:18 PM Dennis Huo ***@***.***> wrote:
   
   > I think this is reasonable, but what about =s in the key? I initially
   > decided to just restrict = altogether because you can always use the
   > Python client instead of the CLI for more sophisticated scenarios like
   > this. Another alternative would be to support JSON or some other syntax
   > that lets us escape special characters.
   >
   > Yeah it's worth thinking about where to draw the line between
   > "sophisticated" scenarios and ones that work straight out of the box. As
   > you mention, cases that might require '=' in the key could still go all the
   > way to the Python client.
   >
   > In practical terms, there does seem to be precedent for being able to
   > specify kv lists as the value of a property and values that use base64
   > encodings that would include '='. In both these cases, the '=' is present
   > in the string precisely because of the value not being from low-cardinality
   > enumeration of possible values. It does seem that non-enumerated keys would
   > be much rarer, since by nature such a situation would only occur if the
   > consuming code iterates over all keys instead of performing a point-get of
   > a key.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > <https://github.com/apache/polaris/pull/1003#issuecomment-2664514445>, or
   > unsubscribe
   > 
<https://github.com/notifications/unsubscribe-auth/AFRE3SGNQLRWUALW7ACYZJD2QKRBTAVCNFSM6AAAAABXDWUDTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRUGUYTINBUGU>
   > .
   > You are receiving this because your review was requested.Message ID:
   > ***@***.***>
   > [image: dennishuo]*dennishuo* left a comment (apache/polaris#1003)
   > <https://github.com/apache/polaris/pull/1003#issuecomment-2664514445>
   >
   > I think this is reasonable, but what about =s in the key? I initially
   > decided to just restrict = altogether because you can always use the
   > Python client instead of the CLI for more sophisticated scenarios like
   > this. Another alternative would be to support JSON or some other syntax
   > that lets us escape special characters.
   >
   > Yeah it's worth thinking about where to draw the line between
   > "sophisticated" scenarios and ones that work straight out of the box. As
   > you mention, cases that might require '=' in the key could still go all the
   > way to the Python client.
   >
   > In practical terms, there does seem to be precedent for being able to
   > specify kv lists as the value of a property and values that use base64
   > encodings that would include '='. In both these cases, the '=' is present
   > in the string precisely because of the value not being from low-cardinality
   > enumeration of possible values. It does seem that non-enumerated keys would
   > be much rarer, since by nature such a situation would only occur if the
   > consuming code iterates over all keys instead of performing a point-get of
   > a key.
   >
   > —
   > Reply to this email directly, view it on GitHub
   > <https://github.com/apache/polaris/pull/1003#issuecomment-2664514445>, or
   > unsubscribe
   > 
<https://github.com/notifications/unsubscribe-auth/AFRE3SGNQLRWUALW7ACYZJD2QKRBTAVCNFSM6AAAAABXDWUDTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRUGUYTINBUGU>
   > .
   > You are receiving this because your review was requested.Message ID:
   > ***@***.***>
   >
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to