In brief, I'd like the database to provide efficient lookups of a unique email column. The database should be able toĭo lookups on the email column efficiently. Instance, every time someone signs in, I find the user record by emailĪddress and then verify the given password. Third, the email column in my database will be accessed frequently. Scenarios like a user logging in where I cannot assume how they will
should be handled as the same email address. Second, email addresses should be treated as case-insensitive. Like the database to ensure the uniqueness of stored email addresses. When working with email addresses from a database perspective, there are a fewįirst, an email address is generally used to identify a user. The concepts will generally apply to anything you consider to be That while the rest of this post will focus on the email address example, The more verbose title for this post would read, "Working With EmailĪddresses And Other Case-Insensitive Data In PostgreSQL". Working for us and, more importantly, where they are not? Is our databaseĮnforcing the constraints we think? Do we understand where our indexes are For theĭata that is though, we need to check our assumptions. Most of the data we work with day to day is not case-insensitive. In EDB Postgres Advanced Server, there is a compatibility setting called edb_redwood_strings, which, when set to true, enables the same behaviour as Oracle when it comes to concatenation.PostgreSQL Working with Email Addresses in PostgreSQL What is interesting here is that, in Oracle, concatenating a NULL and a character together results in the character as the output value, whereas in PostgreSQL, the fact that a NULL is present in either value means that the result is NULL as the output value, no matter what it is being concatenated with. PostgreSQL: | id | content | concatnull | concatchar | Oracle: | ID | CONTENT | CONCATNULL | CONCATCHAR | The query we will be using is: SELECT id, content, Let's see what we get if we try concatenating a NULL or a 1-character string to the values in our example table. NULLs and non-NULLsĪnother important difference between Oracle and PostgreSQL is when a NULL value is concatenated with a non-NULL character. PostgreSQL's behaviour follows the standard in its treatment of NULL values. No conversion has occurred, and we can see that it isn't considered to be a NULL in the query results, but an empty string. But when we look at the empty string that we inserted for the 2nd row, we don't have a NULL value, we still have an empty string. If we look at the first two, the NULL we inserted is still considered a NULL and can't be compared to an empty string. We can ignore the bottom two rows because the functionality is the same, as expected. We don't need to change anything about the above DDL, DML or SQL, so let's just look at the results we end up with: | id | content | isnull | isempty | blank | Let's do the same thing again, but in PostgreSQL this time. NULLs and empty strings in PostgreSQLīut in PostgreSQL, the story is different. The same goes for when we have any non-whitespace characters it's all the same. However, if we have a single space, this isn't converted, as it isn't an empty string. So, empty strings cannot be stored in the database. This tells us that the empty string was treated as a NULL when inserted into the table, and that it can't be compared to regular values as if it were an empty string because it's a full-fledged NULL. | ID | CONTENT | ISNULL | ISEMPTY | BLANK | Note: Remember to change the default null output from '' to (null) psql -P 'null=(null)' SELECTĬASE WHEN content IS NULL THEN 1 ELSE 0 END AS isnull,ĬASE WHEN content = '' THEN 1 ELSE 0 END AS isempty,ĬASE WHEN content = ' ' THEN 1 ELSE 0 END AS blank Here we have a value that's explicitly NULL, an empty string, a string with a single space in it, and another with a 1-character string. INSERT INTO test (id, content) VALUES (4, 'x') INSERT INTO test (id, content) VALUES (3, ' ') INSERT INTO test (id, content) VALUES (2, '') INSERT INTO test (id, content) VALUES (1, NULL) We'll demonstrate this behaviour with a simple table and some data: CREATE TABLE test ( In Oracle, NULLs and empty strings are equivalent when it comes to values stored in the database. Oracle and PostgreSQL behave similarly in many cases, but one way they differ is in their treatment of NULLs and empty strings. Concatenating NULL values with non-NULL characters results in that character in Oracle, but NULL in PostgreSQL. Oracle reads empty strings as NULLs, while PostgreSQL treats them as empty. SUMMARY: This article discusses the differences between how Oracle and PostgreSQL evaluate NULL characters and empty strings.
0 kommentar(er)
