2012/8/30 Anselmo Silva <[email protected]> > > > Em 30 de agosto de 2012 08:25, Matheus de Oliveira < > [email protected]> escreveu: > >> >> >> >> 2012/8/29 Osvaldo Kussama <[email protected]> >> >>> Em 29/08/12, Matheus de Oliveira<[email protected]> escreveu: >>> > 2012/8/29 Osvaldo Kussama <[email protected]> >>> > >>> >> Em 29/08/12, Edson Lidorio<[email protected]> escreveu: >>> >> > Só ordena, no ano atual >>> >> > veja como aparece: >>> >> > >>> >> > 3/2012 >>> >> > 4/2010 >>> >> > 4/2012 >>> >> > 5/2012 >>> >> > 6/2011 >>> >> > 6/2012 >>> >> > 7/2012 >>> >> > 8/2012 >>> >> > >>> >> >>> >> >>> >> Mas você está usando ORDER BY date_trunc('month', a.dt_mov);? >>> >> O comportamento acima não é o usual na ordenação de um campo date. >>> >> Me parece que você está ordenando por to_char(a.dt_mov, 'MM/YYYY'). >>> >> >>> >> >>> > Osvaldo, na verdade é sim, veja que se usar `ORDER BY >>> date_trunc('month', >>> > a.dt_mov);` apenas o mês será considerado na ordenação, logo todo mês >>> de >>> > Junho (inteiro 6), por exemplo, vai ficar junto independente do ano que >>> > seja (2011, 2012, etc.), porque o ano não foi considerado. Logo a >>> ordenação >>> > tem que considerar o mês e o ano, sendo que o ano deve vir antes (ou o >>> > mesmo problema acontecerá), e temos, é claro, várias formas de fazer >>> isso, >>> > como: >>> > >>> > * ORDER BY to_char(a.dt_mov, 'YYYYMM') >>> > * ORDER BY extract(year from a.dt_mov), extract(month from a.dt_mov) >>> (e a >>> > variante com date_trunc, mesma coisa) >>> > >>> > Ambas já apresentadas aqui, e só deve-se tomar cuidado que o que >>> aparece no >>> > ORDER BY tem, *obrigatóriamente*, que aparecer no GROUP BY, ou o >>> PostgreSQL >>> > vai apresentar um erro. >>> > >>> > Atenciosamente, >>> > -- >>> > Matheus de Oliveira >>> > >>> >>> Creio que você entendeu mal a definição da função date_truc. Para >>> tirar as dúvidas sugiro que você faça alguns testes. >>> Do manual: >>> "The function date_trunc is conceptually similar to the trunc function >>> for numbers. >>> date_trunc('field', source) >>> source is a value expression of type timestamp or interval. (Values of >>> type date and time are cast automatically to timestamp or interval, >>> respectively.) field selects to which precision to truncate the input >>> value. The return value is of type timestamp or interval with all >>> fields that are less significant than the selected one set to zero (or >>> one, for day and month)." >>> >>> Aproveitando o exemplo do Juliano: >>> SELECT date_trunc('month', d.d) >>> FROM (VALUES ('01/03/2012'::date), ('10/04/2010'), ('21/04/2012'), >>> ('09/02/2012'), ('10/04/2011')) d(d) >>> ORDER BY date_trunc('month', d.d); >>> date_trunc >>> ------------------------ >>> 2010-04-01 00:00:00-03 >>> 2011-04-01 00:00:00-03 >>> 2012-02-01 00:00:00-02 >>> 2012-03-01 00:00:00-03 >>> 2012-04-01 00:00:00-03 >>> (5 rows) >>> >>> Repare que todas as datas são truncadas para o primeiro dia o mês, ou >>> seja, é como se estivesse ordenando por ano/mês. >>> >>> >> Osvaldo, peço desculpas, fiquei até com vergonha agora. Já conhecia e >> sabia o que fazia a date_trunc, inclusive já usei em projetos, mas por >> total falta de atenção eu a confundi com a date_part, que faria exatamente >> o que eu descrevi... Desculpe novamente. >> >> E, de qualquer forma, talvez a date_trunc não seria boa pra ele exibir os >> dados (já que quer mês e ano), ao menos que formate pela aplicação. Mas >> ainda seria útil no ORDER BY e GROUP BY. >> >> Completando e corrigindo a minha lista, do que o pessoal já disse podemos >> usar: >> >> >> * ORDER BY to_char(a.dt_mov, 'YYYYMM') >> * ORDER BY extract(year from a.dt_mov), extract(month from a.dt_mov) (e >> a variante com *date_part*, mesma coisa) >> * ORDER BY a.dt_mov >> * ORDER BY date_trunc(a.dt_mov) >> >> Só não sei dizer qual seria mais performática, já que todos dão o mesmo >> resultado. >> > "mais performática"? Eu apostaria ORDER BY a.dt_mov, por não executar > funções de conversão > > Não tenho certeza, pois tem a contrapartida de que o PostgreSQL tem que gerenciar muito mais chaves únicas na ordenação, o que poderia causar uso de arquivos temporários (principalmente se houver muitos registros).
Mas de qualquer forma acho que a diferença dessas opções seriam poucas. -- Matheus de Oliveira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
