I have a CSV which contains numbers stored as strings example: 1,200 when loading in these are stored as VARCHAR
I'd like to store these as integers. So tested the below;
update data
set stringy_number = replace (stringy_number,',','')::integer
This runs and removes the , from the number but doesn't change the character type. I then tried;
update data
set stringy_number::integer = replace (stringy_number,',','')::integer
Which threw a syntax error. At which point I switched to the below which worked, but I don't understand why I can't set a data type along with an update
alter table data
alter column stringy_number type integer using replace(stringy_number,',','')::integer;
update works on the values. You can cast from a datatype to another, but the result is still cast to to underlying column type.
--> you can save a "number" in a text column because it is easy to cast a number to a text. You cannot save a letter in a numerical column because the cast cannot (easily) be done.
alter column works on the entire column type. When changing the type, you can supply a custom transformation method allowing the old data to match the new data type.
Related
I have a table with an INTEGER Column which has NOT NULL constraint and a DEFAULT value = 0;
I need to copy data from a series of csv files.
In some of these files this column is an empty string.
So far, I have set NULL parameter in the COPY command to some non existing value so empty string is not converted to NULL value, but now I get an error saying that empty string is incorrect value for the INTEGER column.
I would like to use COPY command because of its speed, but maybe it is not possible.
The file contains no header. All columns in the file have their counterparts in the table.
It there a way to specify that:
an empty sting is zero, or
if there is en empty string use the default column value?
You could create a view on the table that does not contain the column and create an INSTEAD OF INSERT trigger on it. When you COPY data into that view, the default value will be used for the table. Don't know if the performance will be good enough.
In my database I have several fields with INTEGER Type. I need to change some of them to BIGINT.
So my question is, can I just use the following command?
ALTER TABLE MyTable ALTER COLUMN MyIntegerColumn TYPE BIGINT;
Are the contained data be converted the correct way? After the convert is this column a "real" BIGINT column?
I know this is not possible if there are constraints on this column (Trigger, ForeingKey,...). But if there are no constraints is it possible to do it this way?
Or is it better to convert it by a Help-Column:
MyIntegerColumn -> MyIntegerColumnBac -> MyBigIntColumn
When you execute
ALTER TABLE MyTable ALTER COLUMN MyIntegerColumn TYPE BIGINT;
Firebird will not convert existing data from INTEGER to BIGINT, instead it will create a new format version for the table.
When inserting new rows or updating existing rows, the value will be stored as a BIGINT, but when reading Firebird will convert 'old' rows on the fly from INTEGER to BIGINT. This happens transparently for you as the user. This is to prevent needing to rewrite all existing rows, which could be costly (IO, garbage collection of old versions of rows, etc).
So please, do use ALTER TABLE .. ALTER COLUMN, do not do MyIntegerColumn -> MyIntegerColumnBac -> MyBigIntColumn. There are some exceptions to this rule, eg (potentially) lossy character set transformations are better done that way to prevent transliterations errors on select if a character does not exist in the new character set, or changing a (var)char column to be shorter (which can't be done with alter column).
To be a little more specific: when a row is written in the database it contains a format version (aka version count) of that row. The format version points to a description of a row (datatypes, etc) how Firebird should read that row. An alter table will create a new format version, and that format will be applied when writing new rows or updating existing rows. When reading an old row, Firebird will apply necessary transformation to present that row as the new format (for example adding new columns with their default values, transforming a data type of a column).
These format versions are also a reason why the number of alter tables are restricted: if you apply more than 255 alter tables on a single table you must backup and restore the database (the format version is a single byte) before further changes are allowed to that table.
Currently creating my PostgreSQL tables through Postico, and I came across this field for when creating new columns. It is called DEFAULT and its default value is no default. You can select constant, expression, and sequence as options, though.
What exactly do these mean?
The manual on CREATE TABLE:
DEFAULT default_expr
The DEFAULT clause assigns a default data value for the column whose column definition it appears within. The value is any
variable-free expression (subqueries and cross-references to other
columns in the current table are not allowed). The data type of the
default expression must match the data type of the column.
The default expression will be used in any insert operation that does
not specify a value for the column. If there is no default for a
column, then the default is null.
constant and expression should be clear now. sequence is a special feature to make it a serial column:
Creating a PostgreSQL sequence to a field (which is not the ID of the record)
More details on the page #mu provided:
https://www.postgresql.org/docs/current/static/ddl.html
Is there a constraint available in DB2 such that when a column is restricted to a particular length, the values are trimmed to appropriate length before insertion. For Eg. if a column has been specified to be of length 5 , inserting a value 'overflow' will get inserted as 'overf'.
Can CHECK constraint be used here? My understanding of CHECK constraint is that it will allow insertions or not allow them but it can not modify values to satisfy the condition.
A constraint isn't going to be able to do this.
A before insert trigger is normally the mechanism you'd use to modify data during an insert before it is actually placed in the table.
However, I'm reasonably sure it won't work in this case. You'd get an SQLCODE -404 (SQLSTATE 22001) "The Sql Statement specified contains a String that is too long." thrown before the trigger gets fired.
I see two possible options
1) Create a view over the table where the column is cast to a larger size. Then create an INSTEAD OF trigger on the view to substring the data during write.
2) Create and use a stored procedure that accepts a larger size and substrings the data then inserts it.
I just create a new view as follows
CREATE OR REPLACE VIEW gettreelistvw AS
SELECT "CRM".groupid, 'pointrewarding'::text AS applicationid, "CM".menuid, "CM".menuname, "CM".levelstructure, "CM".moduleid, "CM".haschild, "CM".installed
FROM core_capabilitymap "CRM"
JOIN core_menus "CM" ON "CRM".menuid::text = "CM".menuid::text;
ALTER TABLE gettreelistvw
when i execute this error appear
ERROR: cannot change data type of view column "applicationid" from
unknown to text
although I already cast the value of applicationid column to text. it's still recognized as unkown datatype
'pointrewarding'::text
The alternative method of postgres conversion also didn't work.
CAST('pointrewarding' AS TEXT)
How to solve this problem.
If you want to change the data type of a view's columns, you have to drop it, then create it.
Version 9.2 docs
CREATE OR REPLACE VIEW .... The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list.
Emphasis added.