From: | "Jaime Casanova" <systemguards(at)gmail(dot)com> |
---|---|
To: | Luis D(dot) García <ldgarc(at)gmail(dot)com> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Modificación del SelectStmt |
Date: | 2007-09-06 05:06:27 |
Message-ID: | c2d9e70e0709052206mcd168c2q1cea30bf164103f1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On 9/5/07, Luis D. García <ldgarc(at)gmail(dot)com> wrote:
>
> > Bueno, hay varias preguntas aquí, aunque me da la impresión que no las
> > estás captando todas :-). Una es cómo inyectar en una consulta enviada
> > por el usuario el cómputo de las columnas de valid_time (es decir, cómo
> > hacer que una consulta del usuario lleve automáticamente el valid_time).
> > La siguiente es cómo calcular el valor de la nueva columna para cada
> > registro.
> >
> > Para la primera pregunta, la respuesta anterior que te di (modificar el
> > rewriter) es correcta. Para la segunda pregunta, tienes razón que debe
> > hacerse en el Executor (el punto exacto no sabría decírtelo).
>
> > En todo caso, ahora que lo pienso, tu planteamiento en general tiene una
> > pifia bastante grande: es que cada registro tiene un valor de valid_time
> > que depende del orden en que se entreguen los registros. Es decir, si
> > llegas a hacer un UPDATE y después haces un VACUUM, el cual reordene los
> > registros en la tabla, tendrás un problema muy serio porque el orden
> > físico de los registros en la tabla podría cambiar.
> >
> >
>
> Es verdad lo que dices, son muchos los detalles que se deben tomar en cuenta
> en lo
> que a operaciones del usuario sobre las tablas se refiere y eso ya lo he
> venido tomando
> en cuenta (tengo cierto registro de los cambios que deben hacerse más
> adelante) para
> que el sistema trabaje de manera correcta en un futuro, pero esta
> modificación que estoy
> haciendo es para un caso en especial de una empresa de mi país, y aquí no se
> estaría
> trabajando, o al menos no es eso lo que se ha planteado por ahora, con
> UPDATES, DELETES,
> o algún tipo de operación que pueda alterar el orden o la posición que
> tienen los datos,
> ya que es de suma importancia que todos los datos sean registrados tal cual
> en la BD,
> y la única modificación que podría existir, sería la de comprimir o no los
> datos (como en el
> 2do de los 2 casos que te mostré en el primer Mail de este Thread), cosa que
> ya es decisión
> del usuario como tal.
>
> Igualmente agradezco tu ayuda y por lo menos ya sé de seguro que es entonces
> en el
> EXECUTOR donde debo ir trabajando.
>
aunque no entiendo del todo el asunto...
no se suponia que esta columna era una columna virtual que ibas a
calcular en base a un valor en pg_frecuency para esa tabla?
en ese caso, como dice Alvaro no hay nada que hacer en el parser y mas
bien es algo exclusivo del EXECUTOR
--
Atentamente,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
From | Date | Subject | |
---|---|---|---|
Next Message | Espartano | 2007-09-06 05:27:57 | Re: Formas posibles de conectar a Postgres desde PHP |
Previous Message | Jaime Casanova | 2007-09-06 04:06:16 | Re: Tecnicas para mejora de eficiencia en consultas |