Noah Yetter's questions

A função string_agg(expr, delimitador) do Postgres é ótima. Mas eu gostaria de ter uma versão que levasse um único argumento -- o campo para agregar -- e assumisse um delimitador de ', ' já que é o que eu quero 9 vezes em 10. Com uma função não agregada, eu poderia simplesmente faça isso:

create or replace function public.string_agg(text)
returns text
as $$
    select string_agg($1, ', ');
$$ language sql
immutable;

Mas como string_agg é uma função agregada, isso não funciona. Ele reclama que o campo que estou passando para ele precisa estar na cláusula GROUP BY, o que me diz que o mecanismo de consulta não entende que meu wrapper é uma função agregada.

Eu olhei os documentos para agregados definidos pelo usuário (http://www.postgresql.org/docs/9.1/static/xaggr.html e http://www.postgresql.org/docs/9.1/static/sql-createaggregate .html ), mas não é óbvio para mim como eu poderia definir meu novo string_agg(text) usando o string_agg(text, text) existente. Parece que eu teria que definir minha nova função do zero, que é mais complexa do que eu quero assumir, e também não estou totalmente confiante de que poderia espelhar perfeitamente o comportamento do string_agg integrado.

Então, existe alguma técnica para criar um wrapper simples que não estou vendo? Ou vou ter que fazer mais trabalho?

Ao portar um aplicativo para PostgreSQL (9.1), descobri uma estranha incompatibilidade SQL que diz respeito à round()função, especificamente a versão que recebe um segundo argumento indicando a precisão do arredondamento.

No MySQL, round(some_float_column, 2)funciona conforme o esperado, retornando o valor de some_float_columnarredondado para duas casas decimais. No Postgres, ele comete erros ERROR: function round(double precision, integer) does not existe sugere arquivos HINT: No function matches the given name and argument types. You might need to add explicit type casts..

Conforme indicado pelos documentos... http://www.postgresql.org/docs/9.1/static/functions-math.html ...Postgres tem duas funções de rodada, round(value)que levam uma precisão dupla ou numérica, e round(value, precision)que levam um numérico apenas e um número inteiro.

Portanto, não entendo por que a forma de rodada de dois argumentos não leva um duplo para começar, mas tanto faz. Na pesquisa, descobri duas soluções para esse problema. Uma é simplesmente criar minha própria versão round(value, precision)que leva (double, int) e envolve a versão existente (numérica, int) com uma conversão explícita. Isso certamente funciona, mas eu não gosto disso (minha experiência é em Oracle, que nem mesmo tem um tipo de ponto flutuante verdadeiro). Parece-me que float/double deve ser implicitamente convertido em numérico. E acontece que uma conversão de ASSIGNMENT para esses tipos vem pré-definida. Mas ASSIGNMENT não funciona para chamadas de função, como vemos aqui, precisaria ser IMPLICIT. O problema com issoé que apenas uma conversão pode ser definida por par de tipos, e as conversões de atribuição float4->numeric e float8->numeric são exigidas pelo sistema e não podem ser descartadas. Portanto, a única maneira de tornar essas conversões implícitas é update pg_cast set castcontext = 'i' where castsource in (700,701) and casttarget = 1700.

Agora estamos hackeando o catálogo, e isso é um sinal de que isso pode ser uma má ideia. Mas não tenho nenhuma evidência concreta de que seja ruim. Os valores float/double são inexatos e os valores numéricos são exatos, portanto, parece-me que a conversão do primeiro para o último seria totalmente preservadora de dados e, portanto, logicamente segura. O único problema potencial que conheço seria introduzir ambiguidade nos padrões de argumento de outras funções, mas o objetivo de fazer essa pergunta é principalmente pescar problemas potenciais que não conheço.

Então, é perigoso mudar o comportamento de conversão float->numeric de ASSIGNMENT para IMPLICIT?