I am trying to create a table in postgres for storing raster data.
I have 2 different environments: dev and prod.
if I execute the DDL statement in dev then it is creating the table without any problem.
But in prod I am getting the some strange error. How to solve this issue? I am not an admin person and currently facing difficulties with this.
DDL for the table
CREATE TABLE test_shema.test_table (
rid int4 NOT NULL,
rast raster NULL,
CONSTRAINT elevation_hi_pkey_test PRIMARY KEY (rid),
CONSTRAINT enforce_height_rast_test CHECK ((st_height(rast) = ANY (ARRAY[100, 92]))),
CONSTRAINT enforce_max_extent_rast_test CHECK ((st_envelope(rast) # '0103000020E61000000100000005000000A2221ECF131C64C07F55AF453F8C3240A2221ECF131C64C0FEE6DF13C4963640444672D5B14263C0FEE6DF13C4963640444672D5B14263C07F55AF453F8C3240A2221ECF131C64C07F55AF453F8C3240'::geometry)) NOT VALID,
CONSTRAINT enforce_nodata_values_rast_test CHECK ((_raster_constraint_nodata_values(rast) = '{32767.0000000000}'::numeric[])),
CONSTRAINT enforce_num_bands_rast_test CHECK ((st_numbands(rast) = 1)),
CONSTRAINT enforce_out_db_rast_test CHECK ((_raster_constraint_out_db(rast) = '{f}'::boolean[])),
CONSTRAINT enforce_pixel_types_rast_test CHECK ((_raster_constraint_pixel_types(rast) = '{16BSI}'::text[])),
CONSTRAINT enforce_same_alignment_rast_test CHECK (st_samealignment(rast, '01000000006A98816335DA4E3F6A98816335DA4EBFA2221ECF131C64C0FEE6DF13C496364000000000000000000000000000000000E610000001000100'::raster)),
CONSTRAINT enforce_scalex_rast_test CHECK ((round((st_scalex(rast))::numeric, 10) = round(0.000941539829921079, 10))),
CONSTRAINT enforce_scaley_rast_test CHECK ((round((st_scaley(rast))::numeric, 10) = round((-0.000941539829921079), 10))),
CONSTRAINT enforce_srid_rast_test CHECK ((st_srid(rast) = 4326)),
CONSTRAINT enforce_width_rast_test CHECK ((st_width(rast) = ANY (ARRAY[100, 15])))
);
Error that I am getting in prod environment
ERROR: operator does not exist: double precision[] = numeric[]
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
Must be the third constraint. Compare with this instead:
'{32767.0000000000}'::double precision[]
Related
We have a table with 2 columns (both have the same type and size) and 2 constraints for them:
create table colors
(
color varchar(6)
constraint color_check check
((color)::text ~ '^[0-9a-fA-F]{6}$'::text),
color_secodandry varchar(6)
constraint color_secondary_check check
((color_secodandry)::text ~ '^[0-9a-fA-F]{6}$'::text),
);
In case of inserts with long values:
insert into colors (color, color_secondary) values ('ccaabb', 'TOO_LONG_TEXT');
insert into colors (color, color_secondary) values ('TOO_LONG_TEXT', 'ccaabb');
we'll get the same errors for two error cases:
ERROR: value too long for type character varying(6) (SQLSTATE 22001)
PostgreSQL validates length for that columns before make inserts, so our checks never run. Is there a way to understand, which column has an invalid data?
The issue you are having is the order of evaluation for the intended values. You told Postgres to not allow a length over 6 (character varying(6)) you also specified additional certain criteria those values have to satisfy. What is happening is Postgres validates the length criteria and throws an exception when the value fails, in that case the check constraint is not preformed as Postgres works on an exit on first failure. The check constraint is processed only after the length passes. Example:
create table test1( id integer generated always as identity
, color6 character varying (6)
constraint color6_check check (color6 ~ '^[0-9a-fA-F]{6}$')
, color60 character varying (60)
constraint color60_check check (color60 ~ '^[0-9a-fA-F]{6}$')
) ;
insert into test1( color6 ) values ('aabbccdd') ;
/* Result
SQL Error [22001]: ERROR: value too long for type character varying(6)
ERROR: value too long for type character varying(6)
*/
insert into test1( color60 ) values ('aabbccdd') ;
/* Result
SQL Error [23514]: ERROR: new row for relation "test1" violates check constraint "color60_check"
Detail: Failing row contains (3, null, aabbccdd).
ERROR: new row for relation "test1" violates check constraint "color60_check"
*/
Notice the only difference between them is the length specification for the column being inserted. Yet they fail, but for a different reasons. Since both the length specification and the check constraint enforce the length you need to decide now how you want to handle the 2 conditions: a separate error for each condition or a single error for both. (IMHO: separate messages)
I have the following table in my Postgres database
CREATE TABLE "public"."zuffs"
(
"hash" bigint NOT NULL,
"zuff" BIGINT NOT NULL,
"lat" INTEGER NOT NULL,
"lng" INTEGER NOT NULL,
"weather" INTEGER DEFAULT 0,
"expires" INTEGER DEFAULT 0,
"clients" INTEGER DEFAULT 0,
CONSTRAINT "zuffs_hash" PRIMARY KEY ("hash")
) WITH (oids = false);
to which I want to add a new row or update the weather, expires & clients columns if the row already exists. To do this I get my PHP script to generate the following SQL
INSERT INTO zuffs (hash,zuff,lat,lng,weather,expires)
VALUES(5523216,14978310951341,4978,589,105906435,4380919) ON CONFLICT(hash) DO UPDATE SET
weather = 105906435,expires = 4380919,clients = clients + 1;
which fails with the error
ERROR: column reference "clients" is ambiguous
I fail to see why this might be happening. I hope that someone here can explain
In the UPDATE part you should use the EXCLUDED "row" to reference the values. And to reference the existing value, you need to prefix the column with the table again to avoid the ambiguity between "excluded" and "current" values:
INSERT INTO zuffs (hash,zuff,lat,lng,weather,expires)
VALUES (5523216,14978310951341,4978,589,105906435,4380919)
ON CONFLICT(hash) DO UPDATE
SET weather = excluded.weather,
expires = excluded.expires,
clients = zuffs.clients + 1;
I create a domain to catch empty strings:
CREATE DOMAIN TEXTN AS TEXT
CONSTRAINT non_empty CHECK (length(VALUE) > 0);
Then I replace all text/varchars fields on the DB with TEXTN.
However, when I get a error, it not give much info:
DbError { severity: "ERROR", parsed_severity: Some(Error),
code: SqlState("23514"),
message: "value for domain textn violates check constraint \"non_empty\"",
detail: None, hint: None, position: None, where_: None,
schema: Some("libs"),
table: None,
column: None, datatype: Some("textn"),
constraint: Some("non_empty")}
It not even tell me in what table and field the check fail.
If is even possible to print the row to insert better, but at least table and field is possible?
PostgreSQL (I checked version 11) simply does not provide this information as part of the protocol. Consider these statements:
=> CREATE DOMAIN TEXTN AS TEXT CONSTRAINT non_empty CHECK (length(VALUE) > 0);
CREATE DOMAIN
=> CREATE TABLE test_table (test_column textn);
CREATE TABLE
=> INSERT INTO test_table VALUES ('');
ERROR: value for domain textn violates check constraint "non_empty"
The error message on the wire looks like this:
S ERROR
V ERROR
C 23514
M value for domain textn violates check constraint "non_empty\
s public
d textn
n non_empty
F execExprInterp.c
L 3494
R ExecEvalConstraintCheck
There is no trace of test_table or test_column.
If you have some control over how your framework creates tables, it may be possible to use named table constraints instead of domain types, like this:
CREATE TABLE test_table (
test_column text
CONSTRAINT test_column_check CHECK (length(test_column) > 0));
If you make sure that the constraint name uniquely identifies the column, you can use that to recover the problematic column.
Even for a CHECK constraint defined on the column, as in CREATE TABLE test_table (test_column text CHECK (length(test_column) > 0));, PostgreSQL does not report the column name. You only get the name of the constraint, which is autogenerated by PostgreSQL on table creation and usually starts with the column name, but this is not guaranteed.
In a PostgreSQL 9.5.1 database I have a table:
CREATE TABLE test.table01 (
pgid serial NOT NULL,
sample_id text NOT NULL,
all_data jsonb NOT NULL,
CONSTRAINT table01_pkey
PRIMARY KEY (pgid)
)
And a view of that table:
CREATE OR REPLACE VIEW test.test_view AS
SELECT table01.sample_id,
table01.all_data ->> 'technician'::text AS technician,
table01.all_data ->> 'depth'::text AS depth,
table01.all_data ->> 'colour'::text AS colour,
table01.all_data ->> 'duplicate of'::text AS dupe_of
FROM test.table01;
Finally, on that view, I have created a RULE that aims to correctly modify the underlying jsonb object on updates against the view:
CREATE OR REPLACE RULE upd_test_view AS
ON UPDATE TO test.test_view WHERE new.colour <> old.colour
DO INSTEAD
UPDATE test.table01 SET all_data = jsonb_set(table01.all_data, '{colour}'::text[], (('"'::text || new.colour) || '"'::text)::jsonb);
When I subsequently issue
UPDATE test.test_view SET colour = 'Purple' WHERE sample_id = '1234567';
I get back
ERROR: no relation entry for relid 2
********** Error **********
ERROR: no relation entry for relid 2
SQL state: XX000
I must be doing something wrong, but I can't quite get my head around it. Your expertise is very much appreciated. Thank you.
I am no expert in this at all, but I ran into the same error message, and in my case I could solve this by removing the WHERE part of the rule. This will make the rule trigger more frequently, but it solved this problem for me. See if it works for you as well if this is still relevant.
I created a table "TEST" and i tried to input some data however i got an error. The error is ERROR: new row for relation "test" violates check constraint "test_status_check" DETAIL: Failing row contains (5 , 2015-07-21, 15:00:00, I7 , 9 , NULL, NULL).
I think it is because of the null of the status. Therefore, i tried put a null in the test table but still not working
Create table test(
clientID CHAR (20),
startDate date,
startTime time,
instructorNO CHAR(20),
centreID CHAR(20),
status CHAR(4) CHECK (status IN ('Fail','Pass')) NULL,
reason VARCHAR(400),
omitted...
)
ERROR: new row for relation "test" violates check constraint "test_status_check" DETAIL: Failing row contains (5 , 2015-07-21, 15:00:00, I7 , 9 , NULL, NULL).
EDIT: I've completely changed my mind. Your existing code is valid (and the NULL part is unnecessary).
According to the documentation,
It should be noted that a check constraint is satisfied if the check expression evaluates to true or the null value. Since most expressions will evaluate to the null value if any operand is null, they will not prevent null values in the constrained columns. To ensure that a column does not contain null values, the not-null constraint described in the next section can be used.
So, something else is messed up. See here for an example of your original code working.