This won't work, because empty string is not a valid timestamp. First, you are trying to insert an empty string '' to handle NULL values in the dojo column. 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.Your current query has severals problems, two of which I think my answer can resolve. 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.

Postgresql coalesce empty string