Tenho um arquivo de despejo do PostgreSQL 13 feito com este comando:

$ sudo -u postgres pg_dump --no-privileges -Fc -n my_schema --file="/path/to/my_schema.sql" my_database

Mas quando tento restaurá-lo em um novo banco de dados (PG15), enfrento um problema inesperado por causa da --clean --if-existsopção:

$ sudo -u postgres pg_restore  --single-transaction --clean --if-exists --schema=my_schema --no-owner --role="app-user" --dbname=my_database /path/to/my_schema.sql
pg_restore: error: could not execute query: ERROR:  schema "my_schema" does not exist
LINE 1: CREATE TABLE my_schema.my_table (
                     ^
Command was: CREATE TABLE my_schema.my_table (
    id integer NOT NULL,
    name character varying(128),
    description text
);

O esquema não deveria ser recriado antes que as tabelas sejam realmente criadas?

Se isso puder ajudar, aqui está o cabeçalho relevante do arquivo de despejo (desculpe, é um formato binário personalizado):

$ head -n27 my_schema.sql
PGDMP0my_database13.16 (Debian 13.16-0+deb11u1)13.16 (Debian 13.16-0+deb11u1)-=0ENCODINENCODINGSET client_encoding = 'UTF8';
false=00
STDSTRINGS
STDSTRINGS(SET standard_conforming_strings = 'on';
false=00
SEARCHPATH
SEARCHPATH8SELECT pg_catalog.set_config('search_path', '', false);
false=126217698my_databasDATABASEgCREATE DATABASE my_database WITH TEMPLATE = template0 ENCODING = 'UTF8' LOCALE = 'en_US.UTF-8';
"DROP DATABASE my_database;
postgresfalse2615200013my_schemaSCHEMACREATE SCHEMA my_schema;
DROP SCHEMA my_schema;
app-userfalseo12592000138my_tableTABLECREATE TABLE my_schema.my_table (
    id integer NOT NULL,
    name character varying(128),
    description text
);
!DROP TABLE my_schema.my_table;
my_schemaheaapp-userfalse14p12592000144my_table_id_seSEQUENCE}CREATE SEQUENCE my_schema.my_table_id_seq
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;
+DROP SEQUENCE my_schema.my_table_id_seq;
my_schemaapp-userfalse62314=00my_table_id_seqSEQUENCE OWNED BYMALTER SEQUENCE my_schema.my_table_id_seq OWNED BY my_schema.my_table.id;

Há algo que eu possa fazer e por que esse erro está ocorrendo?

Gostaria de extrair algumas estatísticas básicas sobre como as tabelas são preenchidas em um determinado esquema do PostgreSQL 16, como o número absoluto e a porcentagem de valores nulos para cada coluna em todas as tabelas desse esquema.

Atualmente, estou buscando/computando esses valores usando Python/psycopg2, mas estou me perguntando se posso armazenar algum tipo de função dentro do próprio PostgreSQL que eu possa chamar sempre que quiser obter essas estatísticas.

Desejo configurar uma variável psql a partir de uma variável de ambiente shell existente que possa ser usada em psqlcomandos posteriores.

Encontrei o \setmeta-comando, mas não consigo fazer com que ele use uma variável de ambiente existente no Linux:

user@localhost# MY_DB='test_database'
user@localhost# sudo -u postgres psql
\set dbname ${MY_DB}
\set 
...
dbname = '${MY_DB}'

Considerando que eu gostaria dbname = 'test_database'na última linha para que eu possa usá-lo ou exemplo como:\connect :dbname;

Como eu poderia conseguir isso com a página 15 no debian 11?

Isso não está me ajudando muito porque \set dbname `echo ${MY_DB}` está emitindo uma string vazia.

Isso também não, porque gostaria de definir minha variável psql apenas uma vez para evitar redundância e reutilizá-la em vários psqlcomandos, em vez de defini-la várias vezes em -vcada um desses psqlcomandos.

Conheci um estranho PostgreSQL ( v.13.8 ) em uma máquina Windows server 2019 hoje ao tentar restaurar um arquivo de despejo personalizado.

O seguinte comando funcionou:

pg_restore -d postgres://postgres@localhost:5432/postgres --no-owner --no-privileges --create --clean --role=<myuser> --if-exists inputfile.backup 2> inputfile.log

mas simplesmente adicionando a --single-transactionopção à linha de comando, gerou um erro:

pg_restore -d postgres://postgres@localhost:5432/postgres --no-owner --no-privileges --single-transaction --create --clean --role=<myuser> --if-exists inputfile.backup 2> inputfile.log

Mas eu posso ler isso no arquivo de log:

pg_restore: error : options « -c/--clean » and « -a/--data-only » cannot be used together.

Eu nem usei a -abandeira... Isso é estranho, não é?
Eu li o pg_restore doc , especialmente o parágrafo sobre a --single-transactionopção, mas não diz muito sobre isso (por exemplo, sobre um -asinalizador implícito subjacente):

--transação única

Execute a restauração como uma única transação (ou seja, envolva os comandos emitidos em BEGIN/COMMIT). Isso garante que todos os comandos sejam concluídos com êxito ou que nenhuma alteração seja aplicada. Esta opção implica --exit-on-error.

Alguém pode me dizer o que exatamente está acontecendo ao usar esta opção?

Estou tentando gerar tabelas fictícias com dados fictícios para testar o desempenho com algumas tarefas SQL.

Com base neste tópico antigo: Existe uma maneira de inserir várias linhas em uma tabela com valores padrão para todas as colunas?

Percebi que com um IDENTITYtipo, não é mais possível preencher uma tabela com dados fictícios usando a generate_series(1, N)solução sugerida.

Então, como eu poderia inserir 1.000 dados fictícios, por exemplo, na tabela a seguir (PG 14), aproveitando o valor padrão para o campo namesem substituir os valores do sistema para o campo id:

CREATE TABLE foo (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    name TEXT DEFAULT md5(random()::text)
);

Tentar o seguinte falha:

INSERT INTO foo (id) 
  SELECT generate_series(1, 1000);

-- which results in:
ERROR:  cannot insert a non-DEFAULT value into column "id"
DETAIL:  Column "id" is an identity column defined as GENERATED ALWAYS.
HINT:  Use OVERRIDING SYSTEM VALUE to override.
SQL state: 428C9

Como solução alternativa, agora estou criando a tabela com um campo extra itão simples INTEGERpara alimentar este em vez do ide soltá-lo após a inserção dos dados, mas não é 100% limpo para mim.

Eu estava esperando por algo simples e claro como isso, por exemplo:

INSERT INTO foo DEFAULT VALUES (1000);

mas esta é obviamente uma sintaxe inválida.

Eu abri um túnel SSH para conectar a um servidor remoto da seguinte forma:

$ ssh -f -N -L 5433:127.0.0.1:5432 username@servername

Este túnel foi precisamente aberto da seguinte forma (como mostrado por ps aux | grep ssh):

ssh -f -N -L 5433:127.0.0.1:5432 username@servername

Eu tenho um ~/.pg_service.confcom:

[my-pg-service]
    host=127.0.0.1
    port=5433
    dbname=mydatabase
    user=pguser

# just append the .pgpass file here:
[my-pg-service-2]
    host=127.0.0.1
    port=5433
    dbname=mydatabase
    user=pguser
    passfile=~/.pgpass

Ao executar:

$ psql service=my-pg-service

ele atualmente (e surpreendentemente) se conecta sem pedir a senha do banco de dados! (pode ser armazenado em uma espécie de cache porque eu já o usei antes desse comando?)

Mas ao usá psql service=my-pg-service-2-lo, na verdade, pede a senha do banco de dados.
Eu esperava que se comportasse de maneira oposta!

meu arquivo ~/.pgpass( chmod 0600) se parece com:

#hostname:port:database:username:password

# Remote pg database on server servername when using an SSH tunnel (5433)
127.0.0.1:5433:mydatabase:pguser:8+k3&4d2ihs1=&gp!*y)62xoh+^^z$&*ino!66jj()(yw@o36

Observe que este comando também está solicitando a senha do banco de dados:

$ psql -d postgres://pguser@localhost:5433/mydatabase

Mas este não é:

$ psql -d postgres://[email protected]:5433/mydatabase

(só mudei localhostpara 127.0.0.1).

E isso ocorre precisamente porque não existe essa linha começando localhostno .pgpassarquivo:

localhost:5433:mydatabase:pguser:8+k3&4d2ihs1=&gp!*y)62xoh+^^z$&*ino!66jj()(yw@o36

Se eu adicionar essa linha, psqlconecta sem pedir senha nos dois casos anteriores, mas ainda tenho o problema com o serviço pg, por exemplo, ao especificar passfile=~/.pgpasspede senha, e quando não, não.

Alguém pode explicar esse comportamento e o que eu fiz de errado?
Isso pode estar vinculado à configuração do lado do servidor que é muito ampla?

Apenas no caso, o banco de dados é encaixado no servidor remoto. Ele usa a imagem oficial do docker postgis ( 13:3.2) que apresenta essas características padrão:

$ docker run \
  --rm \
  --name postgis \
  -e POSTGRES_DB=postgres \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=changeme \
  -d postgis/postgis:13-3.2

$ docker exec -it postgis bash -c "tail -n 21 /var/lib/postgresql/data/pg_hba.conf"

# CAUTION: Configuring the system for local "trust" authentication
# allows any local user to connect as any PostgreSQL user, including
# the database superuser.  If you do not trust all your local users,
# use another authentication method.

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     trust
host    replication     all             127.0.0.1/32            trust
host    replication     all             ::1/128                 trust

host all all all md5

SO: Ubuntu 21.10
PG: 14

Doc:
https://www.postgresql.org/docs/14/libpq-pgservice.html
https://www.postgresql.org/docs/14/libpq-connect.html#LIBPQ-PARAMKEYWORDS
https://www. postgresql.org/docs/14/libpq-pgpass.html

Eu quero exportar usando copiar 5 colunas de uma tabela, 3 delas contêm valores de ID, texto e timestamp, mas 2 delas contêm elementos JSON e GeoJSON, por exemplo:

 // Please, note the non-quoted string Value1
 // when there is no space in the value itself:
{"key": "value with space", "other_key": Value1, ...}

mas ao usar este comando:

psql \
  -d <connection_uri> \
  --command "\copy public.mytable (id, json_array, geojson_field, status, timestamp) TO './file.csv' DELIMITER ';' CSV HEADER ENCODING 'UTF8' QUOTE '\"' ;"

O resultado parece estranho:

11784,"{'"First value'",'"Second value'", ThirdValue, '"Fourth val'",...

ou seja, está colocando aspas em uma ordem estranha: "single-double <field_value> single-double"

(também não entendo os cabeçalhos ...)

Eu gostaria de poder terminar com um objeto JSON verdadeiro no arquivo csv que eu possa copiar/colar em um validador, por exemplo, aqui sem erros.

Estou fazendo algo errado?
Se sim, como corrigi-lo?

PG:13

Gostaria de saber se existe uma solução melhor do que a seguinte para construir uma nova coluna ( place_type_new) adicionando um sufixo às informações textuais de uma coluna existente ( place_type) com base no valor de uma terceira coluna (o número de inhabitantno caso mostrado aqui):

  UPDATE places_table SET place_type_new = CASE
      WHEN inhabitant = 0 AND place_type LIKE 'Village' THEN 'Village_XXXS'
      WHEN inhabitant = 10 AND place_type LIKE 'Village' THEN 'Village_XXS'
      WHEN inhabitant = 20 AND place_type LIKE 'Village' THEN 'Village_XS'
      WHEN inhabitant = 100 AND place_type LIKE 'Village' THEN 'Village_S'
      WHEN inhabitant = 2000 AND place_type LIKE 'Village' THEN 'Village_M'
      WHEN inhabitant = 5000 AND place_type LIKE 'Village' THEN 'Village_L'
      WHEN inhabitant = 10000 AND place_type LIKE 'Village' THEN 'Village_XL'
      WHEN inhabitant = 20000 AND place_type LIKE 'Village' THEN 'Village_XXL'
      WHEN inhabitant = 50000 AND place_type LIKE 'Village' THEN 'Village_XXXL'
      WHEN inhabitant = 0 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XXXS'
      WHEN inhabitant = 10 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XXS'
      WHEN inhabitant = 20 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XS'
      WHEN inhabitant = 100 AND place_type LIKE 'VillagePart' THEN 'VillagePart_S'
      WHEN inhabitant = 2000 AND place_type LIKE 'VillagePart' THEN 'VillagePart_M'
      WHEN inhabitant = 5000 AND place_type LIKE 'VillagePart' THEN 'VillagePart_L'
      WHEN inhabitant = 10000 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XL'
      WHEN inhabitant = 20000 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XXL'
      WHEN inhabitant = 50000 AND place_type LIKE 'VillagePart' THEN 'VillagePart_XXXL'
      WHEN inhabitant = 0 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XXXS'
      WHEN inhabitant = 10 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XXS'
      WHEN inhabitant = 20 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XS'
      WHEN inhabitant = 100 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_S'
      WHEN inhabitant = 2000 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_M'
      WHEN inhabitant = 5000 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_L'
      WHEN inhabitant = 10000 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XL'
      WHEN inhabitant = 20000 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XXL'
      WHEN inhabitant = 50000 AND place_type LIKE 'Neighborhood' THEN 'Neighborhood_XXXL'
      WHEN inhabitant = 0 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XXXS'
      WHEN inhabitant = 10 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XXS'
      WHEN inhabitant = 20 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XS'
      WHEN inhabitant = 100 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_S'
      WHEN inhabitant = 2000 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_M'
      WHEN inhabitant = 5000 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_L'
      WHEN inhabitant = 10000 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XL'
      WHEN inhabitant = 20000 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XXL'
      WHEN inhabitant = 50000 AND place_type LIKE 'NeighborhoodPart' THEN 'NeighborhoodPart_XXXL'
      ELSE place_type
  END;

Aqui Village, VillagePart, Neighborhoode NeighborhoodPartfazem parte de um conjunto maior de lugares (por exemplo, também existem Town, Citye assim por diante) e eu só quero que essa regra se aplique a esses 4 elementos, daí minhas LIKEdeclarações em todos os lugares.

Mas eu acho isso horrivelmente feio, mas está funcionando perfeitamente. O sufixo para anexar aos valores de campo existentes places_tableno para construir o novo place_table_new, sempre corresponde ao mesmo número na coluna inhabitantde acordo com este padrão:

0     : XXXS
10    :  XXS
20    :   XS
100   :    S
2000  :    M
5000  :    L
10000 :   XL
20000 :  XXL
50000 : XXXL

Seria melhor construir uma tabela intermediária com esse mapeamento para conseguir isso?

Estou usando o PostgreSQL 12 no Ubuntu 18.04. Eu também reduzi o problema aqui para algo tão simples quanto possível, espero sem esquecer algo importante.

Eu tenho uma função de gatilho no PostgreSQL 12 que executa algo assim:

CREATE OR REPLACE FUNCTION "my_latlon_function"()
RETURNS trigger AS
$$
BEGIN
    latcolumn:= (
        SELECT column_name
          FROM information_schema.columns
         WHERE table_schema = TG_TABLE_SCHEMA
           AND table_name = TG_TABLE_NAME
           AND column_name ~* '.*lat.*'
    );
    loncolumn := (
        SELECT column_name
          FROM information_schema.columns
         WHERE table_schema = TG_TABLE_SCHEMA
           AND table_name = TG_TABLE_NAME
           AND column_name ~* '.*lon.*'
    );
    EXECUTE 'select $1.' || loncolumn USING NEW INTO lon;
    EXECUTE 'select $1.' || latcolumn USING NEW INTO lat;

    -- do much stuff

    RETURN NEW;

END
$$
LANGUAGE 'plpgsql';

O problema é que as colunas late lontêm letras maiúsculas em seu nome, por exemplo, myLatitudee myLongitude. A função trigger é capaz de recuperar esses nomes, isso não é problema.

O problema está nas duas EXECUTEinstruções em que parece que os nomes das colunas ficam em minúsculas conforme indicado por este erro (na QUERY subjacente quando o gatilho é acionado):

ERROR:  column "mylongitude" not found in data type gpspoints
LINE 1: select $1.myLongitude
               ^
QUERY:  select $1.myLongitude
CONTEXT:  PL/pgSQL function my_latlon_function() line 24 at EXECUTE
********** Error **********

ERROR: column "mylongitude" not found in data type gpspoints
SQL state: 42703
Context: PL/pgSQL function my_latlon_function() line 24 at EXECUTE

Eu sei que o PostgreSQL precisa colocar os nomes das colunas que têm letras maiúsculas em seu nome entre aspas duplas. Portanto, tentei definir aspas duplas nas duas instruções EXECUTE como esta:

    EXECUTE 'select $1.' || "loncolumn" USING NEW INTO lon;
    EXECUTE 'select $1.' || "latcolumn" USING NEW INTO lat;

Mas o erro permanece exatamente o mesmo.

Se possível, como posso lidar com nomes de colunas CamelCase em uma função de gatilho do PostgreSQL?

Se não não, por quê?

Contexto

Estou usando o PostgreSQL 10.12.

Eu quero ser capaz de disparar uma função de gatilho em algumas tabelas específicas com dados geográficos.

Esta função de gatilho é projetada para criar um ponto PotGIS em uma coluna geomde late lonvalores.
Eu quero aplicar essa mesma função de gatilho em várias tabelas cada vez que uma nova linha é inserida.
A nomenclatura das colunas que contêm valores de latitude e longitude não é consistente nas tabelas, mas segue um padrão...

O que tenho 100% de certeza é que:
1. sempre há duas colunas contendo valores de latitude e longitude,
2. o nome dessas colunas nem sempre é o mesmo nas diferentes tabelas (caso contrário, seria muito simples), mas o palavra 'latitude' e a palavra 'longitude' sempre aparecem em seu nome e nunca aparecem em outros nomes de coluna.

Por exemplo, na tabela A:

_loc_longitude_e_loc_latitude_

e na tabela B:

_building_longitude_centere_building_latitude_center

por exemplo (+ muitos outros).

A função de disparo é a seguinte:

CREATE OR REPLACE FUNCTION make_point_with_latlon()
  RETURNS trigger AS
  $$
  DECLARE
      varlon := NULL;
      varlat := NULL;
  BEGIN
      IF to_jsonb(NEW) SIMILAR TO '.*longitude.*' THEN
          varlon := NEW.the_column_whith_longitude_in_its_name;
      END IF;
      IF to_jsonb(NEW) SIMILAR TO '.*latitude.*' THEN
          varlat := NEW.the_column_whith_latitude_in_its_name;
      END IF;
      NEW.geom = ST_MakePoint(varlon, varlat);
  END
  $$
LANGUAGE 'plpgsql';

Com os seguintes acionadores:

CREATE TRIGGER make_point_with_latlon_but
    BEFORE INSERT OR UPDATE ON schema.table1
    FOR EACH ROW
    EXECUTE PROCEDURE schema.make_point_with_latlon();

CREATE TRIGGER make_point_with_latlon_but
    BEFORE INSERT OR UPDATE ON schema.table2
    FOR EACH ROW
    EXECUTE PROCEDURE schema.make_point_with_latlon();

CREATE TRIGGER make_point_with_latlon_but
    BEFORE INSERT OR UPDATE ON schema.table3
    FOR EACH ROW
    EXECUTE PROCEDURE schema.make_point_with_latlon();

-- (...and many more other tables that need the same trigger).

Não sei como procurar o padrão .*latitude.*nos nomes das colunas passados ​​para a função e como obter seu valor em duas variáveis ​​que posso usar para construir o ponto.
E minhas habilidades de pesquisa no Google para pesquisar esse tipo de coisa estão longe de ser perfeitas, portanto, retornando resultados barulhentos.

Pergunta

Existe alguma possibilidade de fazer isso?

Contexto

Eu configurei um gatilho em uma tabela PostgreSQL (+ Postgis ) contendo pontos de observação.

Este acionador deve calcular uma nova geometria para cada ponto inserido ou atualizado. Esta nova geometria deve ser calculada como a projeção da geometria do ponto de recurso inserido atualmente na linha mais próxima de outra tabela contendo recursos de linha.

O que eu fiz

O gatilho é o seguinte, ele é disparado corretamente conforme EXPLAIN ANALYZEmostra após uma nova inserção:

nenhum erro é lançado quando insiro um novo ponto, mas a coluna de geometria projetada proj_geompermanece vazia:

CREATE OR REPLACE FUNCTION project_funct()
  RETURNS trigger AS
  $$
  BEGIN
    -- Here I wish I could update several fields (line_id, dist and proj_geom) at the same time
    -- but for the moment I only put the focus on the new geometry proj_geom:
    NEW.projected_geom := ( 
      SELECT sub.proj_geom
      FROM
        ( SELECT
             points.id AS point_id,
             schema.lines.id AS line_id,
             ST_Distance(schema.lines.geom, NEW.geom) AS dist,
             ST_ClosestPoint(schema.lines.geom, NEW.geom) AS proj_geom
          FROM schema.line, points
            -- Something is weird to me there, I should probably not have this WHERE statement here as the 
            -- trigger should be used on a single row at a time, hence with a single ID for each execution:
            WHERE points.id = NEW.id 
            ORDER BY dist
            LIMIT 1
        ) AS sub
    );
      RETURN NEW;
  END
  $$
LANGUAGE 'plpgsql';
CREATE TRIGGER proj_trigger
    -- Here, I don't really know if I must used BEFORE or AFTER, AFTER sounds better to me 
    -- but I may be totally wrong. I also wish I could keep the same code for both UPDATE and
    -- INSERT but this may not be a good idea?:
    BEFORE INSERT OR UPDATE ON points 
    FOR EACH ROW
    EXECUTE PROCEDURE project_funct();

Como descobri os gatilhos ontem à noite, e mesmo que tenha feito o meu melhor, meu código provavelmente está cheio de erros.
Eu também notei alguns scripts SQL que eu já tenho e que estão realmente funcionando, ... não funciona mais nesta maneira extravagante(?) de escrever gatilhos (por exemplo, eu não sei o significado do cifrão duplo $$).

Aviso :
Se eu retirar a SELECTdeclaração mais interna e substituir a palavra NEWpelo nome real da tabela de pontos, a consulta, quando executada diretamente no pgAdmin , com um ID especificado, como WHERE points.id = 41retorna os resultados corretos:

Na trigger, meu primeiro comentário diz respeito ao fato de desejar poder atualizar ao mesmo tempo os campos line_id, diste proj_geomda tabela pointscada vez que uma observação for inserida.

Pergunta

Como eu poderia consertar meu código, pelo menos para conseguir a nova geometria?
Tenho certeza de que estou perdendo alguns pequenos detalhes (provavelmente onde deixei alguns comentários no código onde tenho essa sensação real), mas não consigo entendê-los e fiz muito hit'n'try agora com a função de gatilho (nenhum deles funcionou tão bem quanto o aqui acima).

Meio Ambiente

Ubuntu 18.04
PostgreSQL: 10.12
PostGIS: 2.4