[GitHub] [iceberg] ismailsimsek edited a comment on pull request #2010: Core: Add primary key spec.

[GitBox <gi...@apache.org>]

ismailsimsek edited a comment on pull request #2010:
URL: https://github.com/apache/iceberg/pull/2010#issuecomment-760880495


   > One thing in the discussion was whether we should call this `primary key` or something like a `default equality key`. Saying primary key would make people feel the uniqueness is enforced, but it actually cannot enforce it. I don't have a strong opinion on this, but I constantly hear customers using Redshift complaining about this. Also, once we introduce primary key, there will definitely be an ask to have a foreign key concept. Just something to think about if we decide to go with this approach.
   
   +1 for having `primary key` without enforcement. Most of the Analytic databases are supporting informational `Primary Key` and `Foreign Key` Definitions without enforcing it, to use it as metadata. ex [snowflake](https://docs.snowflake.com/en/sql-reference/constraints-overview.html)
   
   Vertica has good balance between both it enforces/checks [constraints during the read,join](http://vertica-forums.com/viewtopic.php?t=101#p143) and not checks it during insert.
   
   it could be good feature to have [ANALYZE_CONSTRAINTS](https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Functions/VerticaFunctions/ANALYZE_CONSTRAINTS.htm) command which the user can validate constraint manually on a table. for-example after insert.
   
   in-case of enforcement it could be good idea to have flag on table level constraints ENABLED/DISABLED
   not sure if this would be possible (for small and less frequently changing tables)
   1. append data to a table
   2. if `constraints_enabled` check constraint before commit!
      - commit or rollback
   
   


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org