beldaz's questions

Estou usando um servidor PostgreSQL 10, no qual tenho algumas tabelas contendo atributos do tipo double precision[]destinados a armazenar arrays 1D de dados, de comprimento ~1000. Meu código interagindo com o banco de dados continha um bug que inseria dados como um array de arrays de comprimento 1 (veja meu relatório de bug psycopg onde acabei descobrindo que era isso que estava acontecendo), mas isso foi permitido pelo DBMS :

A implementação atual também não impõe o número declarado de dimensões. As matrizes de um tipo de elemento específico são todas consideradas do mesmo tipo, independentemente do tamanho ou do número de dimensões. Portanto, declarar o tamanho do array ou o número de dimensões em CREATE TABLEé simplesmente documentação; ele não afeta o comportamento em tempo de execução.

Como posso corrigir esses arrays deformados dentro do DBMS (ou seja, usando SQL em vez de atualizar a partir de código externo)? Basicamente, desejo apenas achatar cada matriz em uma matriz 1D, conforme pretendido originalmente.

Um trecho dos dados da matriz conforme retornado por psqlé:

{{2.20751909662576},{2.20679071024511},{2.20615506273571},{2.2055910715332},{2.
20507756148068},{2.20459435596551},{2.20412336646322},{2.20364958013081},{2.2031
618420891},{2.20265334228114},{2.20212174686242},{2.20156895755458},{2.201000532
12516},{2.20042484573123},{2.19985210697606},{2.19929335742568},{2.1987595765431
},{2.19826098783408},{2.19780662274576},{2.19740415504621},{2.19705997866427},{2
.19677947299938},{2.1965673849541},{2.19642825612809},{2.1963668334181},{2.19638 ...

No pgAdmin 3 (e no pgAdmin 4 se você estiver preparado para esperar mais) o DDL para o objeto de banco de dados selecionado atualmente é mostrado no painel principal, juntamente com os gatilhos, restrições, etc. correspondentes, todos bem formatados. Parece bem diferente do DDL exportado do pgdump. Existe uma maneira de obter a versão melhor, sem copiar e colar manualmente do pgAdmin?

Tenho um servidor PostgreSQL 9.5 no qual tenho scripts que criam funções e bancos de dados para usuários automaticamente. Dentro desses bancos de dados, seria útil habilitar extensões específicas (por exemplo, pgcrypto), mas, pelo que entendi, é preciso ser um superusuário para executar o CREATE EXTENSION. Existe uma maneira de habilitar essas extensões sem fazer login manualmente com uma conta de superusuário?

Eu preciso escrever instruções DDL dinâmicas, como CREATE USER ?. Eu sei que posso usar EXECUTE IMMEDIATE para fazer isso, mas até agora não encontrei nenhuma maneira de incorporar parâmetros dinâmicos sem simplesmente concatenar strings, o que me deixa aberto à injeção de SQL.

Vindo do PostgreSQL, estou acostumado a poder citar identificadores ou usar FORMAT para colocar identificadores com segurança em uma string formatada que pode ser executada. Existe algo assim no Oracle (particularmente 12c)? Se não, como alguém executa esse SQL dinâmico com segurança?

No exemplo a seguir, tenho uma tabela fooda qual gostaria de escolher aleatoriamente uma linha por grupo.

CREATE TABLE foo (
  line INT
);
INSERT INTO foo (line)
SELECT generate_series(0, 999, 1);

Digamos que eu gostaria de agrupar por line % 10. Eu poderia fazer isso com:

SELECT DISTINCT ON (bin) bin, line
FROM (
    SELECT line, line % 10 AS bin, random() x
    FROM foo
    ORDER BY x
) X

O que eu gostaria de fazer é obter escolhas aleatórias de cada caixa várias vezes. Eu pensei que seria capaz de fazer isso com generate_series()eLATERAL

SELECT i, line, bin
FROM
(
 SELECT generate_series(1,3) i
) m,
LATERAL
(SELECT DISTINCT ON (bin) bin, line
FROM (
    SELECT line, line % 10 bin, random() x
    FROM foo
    ORDER BY x
) X
ORDER BY bin) Q
ORDER BY bin, i;

No entanto, quando faço isso no PostgreSQL 9.5, descubro que recebo o mesmo linepara um dado binpara cada iteração i, por exemplo,

i;line;bin
1;530;0
2;530;0
3;530;0
1;611;1
2;611;1
3;611;1
...

Estou confuso, pois pensei que a subconsulta contendo o random()seria executada de maneira diferente para cada linha do arquivo generate_series().

EDIT: Percebi que posso alcançar o mesmo objetivo gerando mais combinações e escolhendo entre elas com

SELECT DISTINCT ON (bin, round) round, bin, line
FROM (
    SELECT line, line % 10 as bin, round
    FROM foo, generate_series(1,3) round
    ORDER BY bin, random()
) X;

Então, minha pergunta é simplesmente por que a primeira maneira não funcionou?

EDIT: O problema parece ser que LATERAL só age como um loop for se as subconsultas estiverem correlacionadas de alguma forma (graças ao comentário de @ypercube). Portanto, minha abordagem original pode ser corrigida adicionando a seguinte pequena alteração

SELECT i, line, bin
FROM
(
 SELECT generate_series(1,3) i
) m,
LATERAL
(
SELECT DISTINCT ON (bin) bin, line
FROM (
    SELECT line, line % 10 bin, m.i, random() x -- <NOTE m.i HERE
    FROM foo
    ORDER BY x
) X
ORDER BY bin
LIMIT 3
) Q
ORDER BY bin, i;

Isso apareceu algumas vezes, por exemplo, no grupo de notícias postgresql e no wiki . Em geral, a relação entre diferentes intervals pode não ser bem definida - um mês pode ter diferentes números de dias, dependendo de qual mês (e ano) está sendo considerado. Mas às vezes é necessário calcular quantos intervalos ocorrem entre dois pontos no tempo, por exemplo (exemplo simplificado):

CREATE TABLE recordings(tstart timestamp, tend timestamp, interval ticklength);

SELECT (tend - tstart) / ticklength AS numticks
FROM recordings;

Isso não é permitido no PostgreSQL porque é uma divisão entre dois intervalos, que não teria um comportamento geral bem definido pelos motivos acima. Existe uma solução alternativa para quando um intervalo pode ser convertido em segundos, mas qual é a melhor maneira quando não é o caso, por exemplo, quando o intervalo é da ordem de milissegundos?

Estou usando o PostgreSQL 9.5 e estou tentando entender como implementar um índice GiST onde tenho uma representação que é uma versão compactada com perdas do tipo indexado. Por exemplo, digamos que eu tenha imagens armazenadas em BYTEAtype e, para o índice, armazeno os intervalos de cores (rmin, rmax, gmin, gmax, bmin, bmax) e desejo comparar imagens com base na semelhança de cores - por exemplo, com um ===operador que retorna true quando as faixas de cores são exatamente iguais, me permitindo facilitar consultas como:

SELECT COUNT(*)
FROM icons, avatars
WHERE icon.image === avatar.image AND avatar.id = 123;

onde iconse avatarssão ambas tabelas com um imagecampo do tipo BYTEA.

Depois de examinar a documentação de implementação, parece que isso deve ser possível. Usando a situação de exemplo acima, acho que poderia fazer o seguinte:

• o unionmétodo geraria o intervalo delimitador de todas as entradas
• picksplite penaltyapenas tentaria minimizar os intervalos, semelhante a um R-Tree
• compresspegaria os dados BYTEA e calcularia a faixa de cores
• decompressseria uma função identidade
• consistent(para o ===operador) retornaria verdadeiro se o intervalo de cores da entrada contivesse o intervalo de consulta para nós internos e somente se os intervalos correspondessem exatamente aos nós folha.

É este o caminho certo? Não estou claro sobre quando as etapas de compactação ocorrem. Por exemplo, consistenté presumivelmente chamado várias vezes em diferentes nós da árvore. Então, isso significa que a consulta terá que recalcular o intervalo de cores dos dados da consulta todas as vezes? E no índice, os nós das folhas conterão uma cópia dos dados da imagem ou apenas sua faixa de cores?

Observação O exemplo fornecido é apenas para fins ilustrativos. Minha pergunta é sobre representações com perdas no GiST, não indexando imagens.

Estou tendo problemas para fazer um gatilho INSTEAD OF funcionar corretamente e acho que não entendi como usar NEW. Considere o seguinte cenário simplificado:

CREATE TABLE Product (
  product_id SERIAL PRIMARY KEY,
  product_name VARCHAR
);
CREATE TABLE Purchase (
  purchase_id SERIAL PRIMARY KEY,
  product_id INT REFERENCES Product,
  when_bought DATE
);

CREATE VIEW PurchaseView AS
SELECT purchase_id, product_name, when_bought
FROM Purchase LEFT JOIN Product USING (product_id);

Eu gostaria de poder criar INSTEAD OFgatilhos para permitir que eu insira diretamente no PurchaseView, por exemplo:

INSERT INTO Product(product_name) VALUES ('foo');
INSERT INTO PurchaseView(product_name, when_bought) VALUES ('foo', NOW());

O que eu tinha em mente era algo como:

CREATE OR REPLACE FUNCTION insert_purchaseview_func()
  RETURNS trigger AS
$BODY$
BEGIN
  INSERT INTO Purchase(product_id, when_bought)
  SELECT product_id, when_bought
  FROM NEW 
  LEFT JOIN Product USING (product_name)
  RETURNING * INTO NEW;
END;
$BODY$
LANGUAGE plpgsql;

CREATE TRIGGER insert_productview_trig
  INSTEAD OF INSERT
  ON PurchaseView
  FOR EACH ROW
  EXECUTE PROCEDURE insert_purchaseview_func();

No entanto, a função de gatilho acima apresenta erros ( relation "new" does not exist) quando executada. Sei que posso escrever consultas que usam explicitamente atributos de NEWcláusulas WHEREe SELECT, mas às vezes seria conveniente poder incluir NEWem uma junção. Existe uma maneira de fazer isso?

Solução atual (insatisfatória)

O mais próximo que posso chegar do que quero é

CREATE OR REPLACE FUNCTION insert_purchaseview_func()
  RETURNS trigger AS
$BODY$
DECLARE
tmp RECORD;
BEGIN
    WITH input (product_name, when_bought) as (
       values (NEW.product_name, NEW.when_bought)
    ) 
    INSERT INTO Purchase(product_id, when_bought)
    SELECT product_id, when_bought
    FROM input
    LEFT JOIN Product USING (product_name)
    RETURNING * INTO tmp;
    RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;

Isso é um pouco insatisfatório por vários motivos:

1. Preciso escrever explicitamente todos os atributos NEWem CTE WITH query, o que para visualizações grandes (especialmente aquelas cujos atributos são determinados automaticamente com SELECT *) fica pesado;

2. O resultado retornado não tem o SERIALtipo product_idatualizado, então você não obtém o resultado esperado para:

   INSERT INTO PurchaseView(product_name, when_bought) 
   VALUES ('foo', NOW())
   RETURNING *;
   

O que se deve fazer quando se deseja substituir um objeto grande por um novo objeto grande. Um exemplo seria atualizar um arquivo carregado com uma nova versão.

Presumivelmente, uma maneira seria criar um novo objeto grande, atualizar os links para o novo id e, em seguida, desvincular o objeto antigo. Mas é razoável substituir os dados existentes, digamos, escrevendo sobre o original (talvez truncando o conteúdo primeiro)?

FWIW eu estaria fazendo isso em JDBC e para PostgreSQL 9.4.

Muitas tabelas em meu banco de dados compartilham um layout comum, em particular, elas têm uma serialchave primária com o nome do nome da relação. Atualizar essas tabelas de dentro de um aplicativo da Web geralmente envolve uma consulta do formulário:

UPDATE table SET attribute = x WHERE table_id = y

Isso é tão comum que tenho um procedimento armazenado que executa esta tarefa:

CREATE OR REPLACE FUNCTION setvalue(
    relname text,
    row_id integer,
    colname text,
    newvalue text)
RETURNS void AS
$BODY$
BEGIN
  EXECUTE format('UPDATE %I SET %I = $1 WHERE %I = $2', relname, colname, relname || '_id', colname) USING row_id;
END;
$BODY$
LANGUAGE plpgsql;

Infelizmente, isso não funciona para tipos não textuais. Por exemplo, atualizar uma datecoluna fornece ERROR: column ... is of type date but expression is of type text. Supondo que o texto seja uma representação literal válida do tipo pretendido, existe uma maneira segura de fazer o DBMS descobrir o tipo certo e fazer a coisa certa?

Eu tenho um banco de dados PostgreSQL (9.4) que limita o acesso aos registros dependendo do usuário atual e rastreia as alterações feitas pelo usuário. Isso é obtido por meio de exibições e acionadores e, na maioria das vezes, funciona bem, mas estou tendo problemas com exibições que exigem INSTEAD OFacionadores. Tentei reduzir o problema, mas peço desculpas antecipadamente por isso ainda ser muito longo.

A situação

Todas as conexões com o banco de dados são feitas a partir de um front-end da web por meio de uma única conta dbweb. Uma vez conectado, o papel é alterado SET ROLEpara corresponder à pessoa que está usando a interface da web, e todos esses papéis pertencem ao grupo role dbuser. (Veja esta resposta para detalhes). Vamos supor que o usuário seja alice.

A maioria das minhas tabelas são colocadas em um esquema que aqui vou chamar privatee pertencer dbowner. Essas tabelas não são acessíveis diretamente para dbuser, mas para outra função dbview. Por exemplo:

SET SESSION AUTHORIZATION dbowner;
CREATE TABLE private.incident
(
  incident_id serial PRIMARY KEY,
  incident_name character varying NOT NULL,
  incident_owner character varying NOT NULL
);
GRANT ALL ON TABLE private.incident TO dbview;

A disponibilidade de linhas específicas para o usuário atual aliceé determinada por outras exibições. Um exemplo simplificado (que poderia ser reduzido, mas precisa ser feito dessa forma para dar suporte a casos mais gerais) seria:

-- Simplified case, but in principle could join multiple tables to determine allowed ids
CREATE OR REPLACE VIEW usr_incident AS 
 SELECT incident_id
   FROM private.incident
  WHERE incident_owner  = current_user;
ALTER TABLE usr_incident
  OWNER TO dbview;

O acesso às linhas é fornecido por meio de uma visualização acessível a dbuserfunções como alice:

CREATE OR REPLACE VIEW public.incident AS 
 SELECT incident.*
   FROM private.incident
  WHERE (incident_id IN ( SELECT incident_id
           FROM usr_incident));
ALTER TABLE public.incident
  OWNER TO dbview;
GRANT ALL ON TABLE public.incident TO dbuser;

Observe que, como apenas uma relação aparece na FROMcláusula, esse tipo de exibição é atualizável sem nenhum acionador adicional.

Para criação de log, existe outra tabela para registrar qual tabela foi alterada e quem a alterou. Uma versão reduzida é:

CREATE TABLE private.audit
(
  audit_id serial PRIMATE KEY,
  table_name text NOT NULL,
  user_name text NOT NULL
);
GRANT INSERT ON TABLE private.audit TO dbuser;

Isso é preenchido por meio de gatilhos colocados em cada uma das relações que desejo rastrear. Por exemplo, um exemplo private.incidentlimitado a apenas inserções é:

CREATE OR REPLACE FUNCTION private.if_modified_func()
  RETURNS trigger AS
$BODY$
BEGIN
    IF TG_OP = 'INSERT' THEN
        INSERT INTO private.audit (table_name, user_name)
        VALUES (tg_table_name::text, current_user::text);
        RETURN NEW;
    END IF;
END;
$BODY$
  LANGUAGE plpgsql;
GRANT EXECUTE ON FUNCTION private.if_modified_func() TO dbuser;

CREATE TRIGGER log_incident
AFTER INSERT ON private.incident
FOR EACH ROW
EXECUTE PROCEDURE private.if_modified_func();

Agora, se aliceinsere em public.incident, um registro ('incident','alice')aparece na auditoria.

O problema

Essa abordagem atinge problemas quando as exibições se tornam mais complicadas e precisam INSTEAD OFde gatilhos para suportar inserções.

Digamos que eu tenha duas relações, por exemplo, representando entidades envolvidas em algum relacionamento muitos-para-um:

CREATE TABLE private.driver
(
  driver_id serial PRIMARY KEY,
  driver_name text NOT NULL
);
GRANT ALL ON TABLE private.driver TO dbview;

CREATE TABLE private.vehicle
(
  vehicle_id serial PRIMARY KEY,
  incident_id integer REFERENCES private.incident,
  make text NOT NULL,
  model text NOT NULL,
  driver_id integer NOT NULL REFERENCES private.driver
);
GRANT ALL ON TABLE private.vehicle TO dbview;

Suponha que eu não queira expor os detalhes além do nome de private.driver, e assim ter uma visão que una as tabelas e projete os bits que desejo expor:

CREATE OR REPLACE VIEW public.vehicle AS 
 SELECT vehicle_id, make, model, driver_name
   FROM private.driver
   JOIN private.vehicle USING (driver_id)
  WHERE (incident_id IN ( SELECT incident_id
               FROM usr_incident));
ALTER TABLE public.vehicle OWNER TO dbview;
GRANT ALL ON TABLE public.vehicle TO dbuser;

Para alicepoder inserir nesta visão, um gatilho deve ser fornecido, por exemplo:

CREATE OR REPLACE FUNCTION vehicle_vw_insert()
  RETURNS trigger AS
$BODY$
DECLARE did INTEGER;
   BEGIN
     INSERT INTO private.driver(driver_name) VALUES(NEW.driver_name) RETURNING driver_id INTO did;
     INSERT INTO private.vehicle(make, model, driver_id) VALUES(NEW.make_id,NEW.model, did) RETURNING vehicle_id INTO NEW.vehicle_id;
     RETURN NEW;
    END;
$BODY$
  LANGUAGE plpgsql SECURITY DEFINER;
ALTER FUNCTION vehicle_vw_insert()
  OWNER TO dbowner;
GRANT EXECUTE ON FUNCTION vehicle_vw_insert() TO dbuser;

CREATE TRIGGER vehicle_vw_insert_trig
INSTEAD OF INSERT ON public.vehicle
FOR EACH ROW
EXECUTE PROCEDURE vehicle_vw_insert();

O problema disso é que a SECURITY DEFINERopção na função trigger faz com que ela seja executada com current_userset to dbowner, então se aliceinsere um novo registro na view a entrada correspondente nos private.auditregistros o autor a ser dbowner.

Então, existe uma maneira de preservar current_user, sem dar ao dbusergrupo acesso direto às relações no esquema private?

Solução Parcial

Conforme sugerido por Craig, usar regras em vez de gatilhos evita alterar o arquivo current_user. Usando o exemplo acima, o seguinte pode ser usado no lugar do acionador de atualização:

CREATE OR REPLACE RULE update_vehicle_view AS
  ON UPDATE TO vehicle
  DO INSTEAD
     ( 
      UPDATE private.vehicle
        SET make = NEW.make,
            model = NEW.model
      WHERE vehicle_id = OLD.vehicle_id
       AND (NEW.incident_id IN ( SELECT incident_id
                   FROM usr_incident));
     UPDATE private.driver
        SET driver_name = NEW.driver_name
       FROM private.vehicle v
      WHERE driver_id = v.driver_id
      AND vehicle_id = OLD.vehicle_id
      AND (NEW.incident_id IN ( SELECT incident_id
                   FROM usr_incident));               
   )

Isso preserva current_user. RETURNINGCláusulas de apoio podem ser um pouco complicadas, no entanto. Além disso, não consegui encontrar uma maneira segura de usar regras para inserir simultaneamente em ambas as tabelas para lidar com o uso de uma sequência para arquivos driver_id. A maneira mais fácil seria usar uma WITHcláusula em um INSERT(CTE), mas estes não são permitidos em conjunto com NEW(error: rules cannot refer to NEW within WITH query), deixando um para recorrer ao lastval()qual é fortemente desencorajado .

Eu tenho um programa Java/JDBC que pega um arquivo de amostra e importa os dados para o banco de dados, fragmentando-os em várias relações. O programa faz isso várias vezes para várias representações diferentes, uma das quais usa objetos grandes. Posso compartilhar mais detalhes dessas representações, mas elas são muito longas e não são relevantes para essa questão, pois estou procurando algo genérico.

Gostaria de comparar os tamanhos dessas diferentes representações examinando o tamanho do banco de dados após cada importação. O banco de dados está em uma instância do servidor Windows local PostgreSQL 9.4, sem outros usuários e com configuração padrão. Sua única finalidade é realizar este teste.

Meu plano inicial era o seguinte:

for each representation {
  call VACUUM ANALYZE
  record old DB size with SELECT pg_tablespace_size('pg_default');
  import data into database
  call VACUUM ANALYZE
  record new DB size with SELECT pg_tablespace_size('pg_default');
  store storage cost as new DB size - old DB size
}

Obviamente, há limitações para essa abordagem, mas minha expectativa é que, para arquivos grandes (~ 100 MB), os custos de armazenamento relatados sejam aproximações razoáveis. Observe que utilizo pg_tablespace_sizede forma a incluir a contribuição de dados fora do esquema principal, como objetos grandes (in pg_catalog.pg_largeobjecte pg_catalog.pg_largeobject_metadata).

Eu estou querendo saber se esta é uma abordagem correta e se existe uma abordagem melhor. Não tenho certeza se VACUUM ANALYZEatualiza corretamente as estatísticas usadas por pg_tablespace_size, mesmo que seja chamado na mesma sessão. Também seria melhor se eu pudesse evitar chamar VACUUM ANALYZE, pois isso requer conexão como superusuário para executar as pg_catalogrelações.

Alguma ideia?

Estou procurando importar dados de série temporal multicanal grandes (100 MB - 1 GB) para um banco de dados PostgreSQL. Os dados vêm de arquivos no formato EDF que dividem os dados em "registros" ou "épocas" de alguns segundos cada. O registro de cada época contém os sinais para cada canal de dados como matrizes sequenciais de inteiros curtos.

Sou obrigado a armazenar os arquivos no banco de dados, no pior dos casos, como BLOBs. Diante disso, gostaria de investigar opções que me permitissem fazer algo mais com os dados do banco de dados, como facilitar consultas com base nos dados do sinal.

Meu plano inicial é armazenar os dados como uma linha por registro de época. O que estou tentando avaliar é se devo armazenar os dados do sinal real como tipos bytea ou smallint[] (ou mesmo smallint[][]). Alguém poderia recomendar um sobre o outro? Estou interessado nos custos de armazenamento e acesso. É provável que o uso seja inserido uma vez, lido ocasionalmente, nunca atualizado. Se um fosse mais facilmente agrupado como um tipo personalizado, de modo que eu pudesse adicionar funções para analisar ou comparar registros, tanto melhor.

Sem dúvida, estou com poucos detalhes, então sinta-se à vontade para adicionar comentários sobre o que você gostaria que eu esclarecesse.

Eu tenho três tabelas, representando duas entidades e um relacionamento de conexão. Cada uma das relações de entidade tem uma chave substituta artificial usada para restrições de chave estrangeira no lugar de chaves naturais.

CREATE TABLE Person (
person_id SERIAL PRIMARY KEY,
username VARCHAR NOT NULL UNIQUE
);

CREATE TABLE Group (
group_id SERIAL PRIMARY KEY,
group_name VARCHAR NOT NULL UNIQUE
);

CREATE TABLE GroupMember (
person_id INTEGER REFERENCES Person,
group_id INTEGER REFERENCES Group,
PRIMARY KEY (person_id, group_id)
);

Gostaria de inserir várias entradas na relação de relacionamento GroupMember, mas usando as chaves naturais das entidades associadas. Algo na linha de:

INSERT INTO GroupMember (person_id,group_id)
SELECT person_id,group_id
FROM Person P, Group G, (
('alice','girls'),
('bob','boys'),
('alice','coolkids'),
('bob','coolkids')
) AS X
WHERE P.username = X.1 AND G.group_name = X.2;

Obviamente, a sintaxe acima não é válida, mas esperamos transmitir a ideia. Existe uma maneira de fazer isso no PostgreSQL?

Na resposta muito útil que recebi para uma pergunta anterior , estou tentando escrever algum código JDBC que primeiro defina a função para um usuário específico antes de executar consultas subsequentes. Por segurança, gostaria de evitar ataques de injeção de SQL parametrizando a SET ROLEinstrução. Minha abordagem no Groovy (que usa JDBC) foi:

def sql = Sql.newInstance('jdbc:postgresql:mydb', 'mydbweb', 'mydbwebpass', 'org.postgresql.Driver')
sql.execute 'SET ROLE ?', user

mas isso gera um erro de sintaxe. A documentação diz que SET ROLEpode levar uma string literal, mas não estou claro como posso passá-la validamente. Alguma sugestão?

O seguinte parece ser uma situação bastante comum, mas não vi nenhuma solução.

Eu tenho um banco de dados PostgreSQL contendo exibições específicas para o $user, a fim de restringir os dados dependendo de alguma lógica ACL específica do banco de dados. O banco de dados é normalmente acessado por meio de JDBC e, em particular, em JSP para uma interface da web. Os usuários fazem login no site com autenticação de senha usando LDAP.

O que eu gostaria é de usar as visualizações de dentro da conexão JDBC com o banco de dados. Mas normalmente essa conexão intermediária é criada usando um usuário genérico, e não específico para a pessoa conectada ao site. Acredito que no Oracle a abordagem "correta" seja Proxy Authentication , mas AFAIAA não há equivalente para PostgreSQL. Então, o que fazer em vez disso?

Algumas ideias vêm à mente:

• Dê a todas as contas de banco de dados dos usuários a mesma senha e, em seguida, crie uma conexão JDBC específica do usuário usando essa senha genérica (isso parece tão errado ...)
• Armazene a senha de login do usuário em algum lugar do site, para reutilizar ao criar uma conexão de banco de dados (novamente, isso parece muito errado)

Alguma outra sugestão (espero que melhor)?