Re: [pgsql-es-ayuda] ayuda con funcion

[Marcos Michel Martinez Perez]

ya gracias por la ayuda, resolvi con una tabla trabajandola como tipo de 
log en la que guardo un registro cuando se ejecuta y cada vez que se 
ejecute lo que hago es verificar eso


--


 Nunca prives a nadie de la esperanza,
   puede ser lo único que esa persona posea.





Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE 
ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com

Re: [pgsql-es-ayuda] ayuda con funcion

[Jaime Casanova]

2011/11/16 Marcos Michel Martinez Perez 
>
> como puedo saber si ya una funcion se ejecuto una vez
>
> por ejemplo yo quiero que si no se ha ejecutado nunca me haga una consulta 
> determinada pero si ya se ejecuto una vez
> entonces que me haga otra consulta
>

y si se ejecuto pero termino enseguida (sin hacer nada) por un error?
yo diria que lo mas sano es que la funcion grabe en alguna tabla que
se ejecuto y cuando.

lo otro es usar funciones plperl que te da acceso a global (aunque por
supuesto eso no sobrevive a un restart)...

lo que me lleva a preguntar, esa condicion es si se ejecuto al menos
una vez cada cierto tiempo, cada vez que reinicie o una vez para
siempre?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] ayuda con funcion

[Marcos Michel Martinez Perez]

como puedo saber si ya una funcion se ejecuto una vez

por ejemplo yo quiero que si no se ha ejecutado nunca me haga una 
consulta determinada pero si ya se ejecuto una vez entonces que me haga 
otra consulta


--


 Nunca prives a nadie de la esperanza,
   puede ser lo único que esa persona posea.





Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE 
ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com

RE: [pgsql-es-ayuda] Asignar Memoria compartida para Postgres

[Lazaro Rubén García Martinez]

>   * Puede asignarse mas valor a la memoria compartida para que lo pueda 
> utilizar el shared_buffers ?
Si

Creo leer en algún sitio que en sistemas de 32 bits el valor tope para shmmax 
es de 4 GB, y para entornos de 64 bits el límite de configurarción se amplia 
hasta casi el total de la RAM física del sistema. Si por alguna casualidad esta 
concepción estuviese mal, agradecería a alguien de la lista que me la aclarase. 

Yo utilizo este script para configurar ese parámetro:

#!/bin/bash
# simple shmsetup script
page_size=`getconf PAGE_SIZE`
phys_pages=`getconf _PHYS_PAGES`
shmall=`expr $phys_pages / 2`
shmmax=`expr $shmall \* $page_size`
echo kernel.shmmax = $shmmax
echo kernel.shmall = $shmall

Y despues ejecuto el siguiente comando:

shmsetup.sh >> /etc/sysctl.conf

Y para que los cambios tengan efecto:

sysctl -p /etc/sysctl.conf

Para más información sobre como configurar estos parámetro puedes consultar el 
siguiente enlace:

http://www.postgresql.org.es/node/229

Saludos.


De: pgsql-es-ayuda-ow...@postgresql.org [pgsql-es-ayuda-ow...@postgresql.org] 
En nombre de wilson del rosario [wilson1...@gmail.com]
Enviado el: miércoles, 16 de noviembre de 2011 22:10
Para: pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] Asignar Memoria compartida para Postgres

Hola, tengo un servidor en debian con 16 gb de memoria ram, tengo una memoria 
compartida (kernel.shmmax)que no acepta mas de 3GB:

   * Puede asignarse mas valor a la memoria compartida para que lo pueda 
utilizar el shared_buffers ?
Muchas gracias por su tiempo :D
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Asignar Memoria compartida para Postgres

[Anthony]

El 16/11/2011 22:40, wilson del rosario escribió:
Hola, tengo un servidor en debian con 16 gb de memoria ram, tengo una 
memoria compartida (kernel.shmmax)que no acepta mas de 3GB:


   * Puede asignarse mas valor a la memoria compartida para que lo 
pueda utilizar el shared_buffers ?

Muchas gracias por su tiempo :D
creo que debes echarle un vistazo al SHMMAX y  configurado en los 
parámetros del kernel del SO, busca por el /etc/sysctl.conf y varia el 
tamaño para que puedas aumentar el SHARED_BUFFERS.

saludos



Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE 
ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
http://www.antiterroristas.cu
http://justiciaparaloscinco.wordpress.com

[pgsql-es-ayuda] Asignar Memoria compartida para Postgres

[wilson del rosario]

Hola, tengo un servidor en debian con 16 gb de memoria ram, tengo una
memoria compartida (kernel.shmmax)que no acepta mas de 3GB:

   * Puede asignarse mas valor a la memoria compartida para que lo pueda
utilizar el shared_buffers ?
Muchas gracias por su tiempo :D

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

perdon el trigger no, ese es la funcion para recuperar informacion. Tambien esa 
es la razon por la cual no puedo usar TG_RELID



>
>De: Alejandro Carrillo 
>Para: Alvaro Herrera 
>CC: "pgsql-es-ayuda@postgresql.org" 
>Enviado: miércoles 16 de noviembre de 2011 16:11
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Hice la prueba y funciono con el esquema public pero al colocar un esquema 
>diferente me sale esto:
>NOTICE:  no existe la relación «clientesborradocopia»
>
>
>esto es lo que ejecuto:
>select 
>public.fn_RecuperarReg('test','clientesborradocopia','idcliente','2',null,null);
>
>
>y este es el trigger:
>
>
>create or replace function public.fn_RecuperarReg (p_schema varchar, p_tabla 
>varchar, p_campo varchar, p_valor varchar, p_maquina inet, p_usuario varchar) 
>returns varchar
>as
>$$
>declare
>    biRegRec bigint := 0;
>    biRegNoRec bigint := 0;
>    regrec
 hstore;
>begin   
>    FOR regrec IN SELECT registro from borradoscopia 
>        where registro -> p_campo like p_valor
>        and tabla = p_tabla 
>        and esquema = p_schema
>        and coalesce(maquina,'0.0.0.0') = 
>coalesce(p_maquina,coalesce(maquina,'0.0.0.0')) --campo opcional
>        and coalesce(usuario,'') like coalesce('%'||p_usuario||'%','%%') 
>--campo opcional
>        and coalesce(usuario,'') like coalesce('%'||p_usuario||'%','%%') 
>--campo opcional
>    LOOP
>    begin
>        execute 'insert into ' || 
>quote_ident(p_schema)||'.'||quote_ident(p_tabla)::regclass 
>        || ' SELECT * FROM populate_record(null::'||
 quote_ident(p_schema)||'.'||quote_ident(p_tabla)::regclass ||', $1)' using 
regrec;
>        --debe borrar cada registro que no haya fallado su copia
>        delete from borradoscopia where registro = regrec;
>        biRegRec:=biRegRec+1;
>    exception
>    when others then        
>        raise notice '%',SQLERRM;
>        biRegNoRec:=biRegNoRec+1;
>    end;    
>    END LOOP;
>    if (biRegNoRec=0) and (biRegRec >0) then
>    return biRegRec || ' Registro(s) recuperado(s) con éxito. 100% registros 
>recuperados';
>    elseif biRegNoRec>0 then 
>    return biRegNoRec || ' no se pudieron recuperar'|| biRegRec
 || ' Registro(s) recuperado(s) con éxito, ' ;
>    else         
> return 'No hay registros por recuperar.';
>    end if;
>    
>end;
>$$
>LANGUAGE plpgsql VOLATILE
>  COST 100;
>
>
>¿que puede ser?
>
>
>
>
>>
>>De: Alvaro Herrera 
>>Para: Alejandro Carrillo 
>>CC: Ayuda 
>>Enviado: miércoles 16 de noviembre de 2011 15:30
>>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>>
>>
>>Excerpts from Alejandro Carrillo's message of mié nov 16 17:15:11 -0300 2011:
>>> Es TG_TABLE_SCHEMA, sin embargo he tenido lios al tratar de incluir el 
>>> schema en el insert, por favor revisen que pudo haber pasado:
>>> 
>>> execute 'insert into ' || quote_ident(p_schema||'.'||p_tabla)::regclass 
>>>         || ' SELECT * FROM populate_record(null::'|| 
>>> quote_ident(p_schema||'.'||p_tabla)::regclass ||', $1)' using regrec;
>>> 
>>> El error:
>>> 
>>> NOTICE:  no existe la relación «public.clientesborradocopia»
>>> 
>>> Y la bendita tabla si existe.
>>
>>No, estás tratando de usar el nombre-con-esquema como si fuera
 solamente
>>el nombre.  Debes aplicar quote_ident a cada parte separadamente.   Creo
>>que esto debería funcionar:
>>
>>execute 'insert into ' || (quote_ident(p_schema) 
>>||'.'||quote_ident(p_tabla))::regclass 
>>
>>(mismo tratamiento a la siguiente línea), aunque honestamente en este
>>caso y dado que ya estás usando un cast a regclass yo usaría simplemente
>>el OID,
>>
>>execute 'insert into ' || TG_RELID::regclass 
>>
>>-- 
>>Álvaro Herrera 
>>
>>
>>
>
>

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

Hice la prueba y funciono con el esquema public pero al colocar un esquema 
diferente me sale esto:
NOTICE:  no existe la relación «clientesborradocopia»

esto es lo que ejecuto:
select 
public.fn_RecuperarReg('test','clientesborradocopia','idcliente','2',null,null);

y este es el trigger:

create or replace function public.fn_RecuperarReg (p_schema varchar, p_tabla 
varchar, p_campo varchar, p_valor varchar, p_maquina inet, p_usuario varchar) 
returns varchar
as
$$
declare
    biRegRec bigint := 0;
    biRegNoRec bigint := 0;
    regrec hstore;
begin   
    FOR regrec IN SELECT registro from borradoscopia 
        where registro -> p_campo like p_valor
        and tabla = p_tabla 
        and esquema = p_schema
        and coalesce(maquina,'0.0.0.0') = 
coalesce(p_maquina,coalesce(maquina,'0.0.0.0')) --campo opcional
        and coalesce(usuario,'') like coalesce('%'||p_usuario||'%','%%') 
--campo opcional
        and coalesce(usuario,'') like coalesce('%'||p_usuario||'%','%%') 
--campo opcional
    LOOP
    begin
        execute 'insert into ' || 
quote_ident(p_schema)||'.'||quote_ident(p_tabla)::regclass 
        || ' SELECT * FROM populate_record(null::'|| 
quote_ident(p_schema)||'.'||quote_ident(p_tabla)::regclass ||', $1)' using 
regrec;
        --debe borrar cada registro que no haya fallado su copia
        delete from borradoscopia where registro = regrec;
        biRegRec:=biRegRec+1;
    exception
    when others then        
        raise notice '%',SQLERRM;
        biRegNoRec:=biRegNoRec+1;
    end;    
    END LOOP;
    if (biRegNoRec=0) and (biRegRec >0) then
    return biRegRec || ' Registro(s) recuperado(s) con éxito. 100% registros 
recuperados';
    elseif biRegNoRec>0 then 
    return biRegNoRec || ' no se pudieron recuperar'|| biRegRec || ' 
Registro(s) recuperado(s) con éxito, ' ;
    else         
 return 'No hay registros por recuperar.';
    end if;
    
end;
$$
LANGUAGE plpgsql VOLATILE
  COST 100;

¿que puede ser?




>
>De: Alvaro Herrera 
>Para: Alejandro Carrillo 
>CC: Ayuda 
>Enviado: miércoles 16 de noviembre de 2011 15:30
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Excerpts from Alejandro Carrillo's message of mié nov 16 17:15:11 -0300 2011:
>> Es TG_TABLE_SCHEMA, sin embargo he tenido lios al tratar de incluir el 
>> schema en el insert, por favor revisen que pudo haber pasado:
>> 
>> execute 'insert into ' || quote_ident(p_schema||'.'||p_tabla)::regclass 
>>         || ' SELECT * FROM populate_record(null::'|| 
>> quote_ident(p_schema||'.'||p_tabla)::regclass ||', $1)' using regrec;
>> 
>> El error:
>> 
>> NOTICE:  no existe la relación «public.clientesborradocopia»
>> 
>> Y la bendita tabla si existe.
>
>No, estás tratando de usar el nombre-con-esquema como si fuera solamente
>el nombre.  Debes aplicar quote_ident a cada parte separadamente.   Creo
>que esto debería funcionar:
>
>execute 'insert into ' || (quote_ident(p_schema) 
>||'.'||quote_ident(p_tabla))::regclass 
>
>(mismo tratamiento a la siguiente línea), aunque honestamente en este
>caso y dado que ya estás usando un cast a regclass yo usaría simplemente
>el OID,
>
>execute 'insert into ' || TG_RELID::regclass 
>
>-- 
>Álvaro Herrera 
>
>
>

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alvaro Herrera]

Excerpts from Alejandro Carrillo's message of mié nov 16 16:28:07 -0300 2011:
> -Supongo que deberías especificar el esquema de la tabla, no solamente su
> nombre.
> No es tan simple ya que en la function fn_borradocopia, que devuelve el 
> trigger, la variable TG_RELNAME contiene solo el nombre de la tabla.

TG_SCHEMA_NAME ...  En todo caso, supuestamente TG_RELNAME está
obsoleto; mejor usa TG_TABLE_NAME.

> -Otra cosa ¿has considerado qué pasa si la versión actual de la tabla
> difiere en columnas con la que tenía al momento de ejecutar el borrado?
> Si
> 
> 1) Si tiene columnas nuevas, al reataurarla las deja en null
> 2) Si ha cambiado el nombre de alguna columna, al restaurarla deja el dato en 
> null
> 3) Si la columna no existe, no muestra el dato
> 
> Toda esta magía la hace la función populate_record de, obviamente, la 
> extensión hstore

Suena razonable ...

> ¿Alguna otra observación? ¿Sugerencia?

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

1) def un error de capa 8
Estaba leyendo:
http://www.postgresql.org/docs/8.1/static/plpgsql-trigger.html
y era por lo menos 8.2 en adelante jajajajajaja
Ya corrigo

2) No solo suena razonable. ¡Funciona!




>
>De: Alvaro Herrera 
>Para: Alejandro Carrillo 
>CC: Ayuda 
>Enviado: miércoles 16 de noviembre de 2011 14:38
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Excerpts from Alejandro Carrillo's message of mié nov 16 16:28:07 -0300 2011:
>> -Supongo que deberías especificar el esquema de la tabla, no solamente su
>> nombre.
>> No es tan simple ya que en la function fn_borradocopia, que devuelve el 
>> trigger, la variable TG_RELNAME contiene solo el nombre de la tabla.
>
>TG_SCHEMA_NAME ...  En todo caso, supuestamente TG_RELNAME está
>obsoleto; mejor usa TG_TABLE_NAME.
>
>> -Otra cosa ¿has considerado qué pasa si la versión actual de la tabla
>> difiere en columnas con la que tenía al momento de ejecutar el borrado?
>> Si
>> 
>> 1) Si tiene columnas nuevas, al reataurarla las deja en null
>> 2) Si ha cambiado el nombre de alguna columna, al restaurarla deja el dato 
>> en null
>> 3) Si la columna no existe, no muestra el dato
>> 
>> Toda esta magía la hace la función populate_record de, obviamente, la 
>> extensión hstore
>
>Suena razonable ...
>
>> ¿Alguna otra observación? ¿Sugerencia?
>
>-- 
>Álvaro Herrera 
>
>
>

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

Es TG_TABLE_SCHEMA, sin embargo he tenido lios al tratar de incluir el schema 
en el insert, por favor revisen que pudo haber pasado:

execute 'insert into ' || quote_ident(p_schema||'.'||p_tabla)::regclass 
        || ' SELECT * FROM populate_record(null::'|| 
quote_ident(p_schema||'.'||p_tabla)::regclass ||', $1)' using regrec;

El error:

NOTICE:  no existe la relación «public.clientesborradocopia»

Y la bendita tabla si existe.



>
>De: Alvaro Herrera 
>Para: Alejandro Carrillo 
>CC: Ayuda 
>Enviado: miércoles 16 de noviembre de 2011 14:38
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Excerpts from Alejandro Carrillo's message of mié nov 16 16:28:07 -0300 2011:
>> -Supongo que deberías especificar el esquema de la tabla, no solamente su
>> nombre.
>> No es tan simple ya que en la function fn_borradocopia, que devuelve el 
>> trigger, la variable TG_RELNAME contiene solo el nombre de la tabla.
>
>TG_SCHEMA_NAME ...  En todo caso, supuestamente TG_RELNAME está
>obsoleto; mejor usa TG_TABLE_NAME.
>
>> -Otra cosa ¿has considerado qué pasa si la versión actual de la tabla
>> difiere en columnas con la que tenía al momento de ejecutar el borrado?
>> Si
>> 
>> 1) Si tiene columnas nuevas, al reataurarla las deja en null
>> 2) Si ha cambiado el nombre de alguna columna, al restaurarla deja el dato 
>> en null
>> 3) Si la columna no existe, no muestra el dato
>> 
>> Toda esta magía la hace la función populate_record de, obviamente, la 
>> extensión hstore
>
>Suena razonable ...
>
>> ¿Alguna otra observación? ¿Sugerencia?
>
>-- 
>Álvaro Herrera 
>
>
>

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alvaro Herrera]

Excerpts from Alejandro Carrillo's message of mié nov 16 17:15:11 -0300 2011:
> Es TG_TABLE_SCHEMA, sin embargo he tenido lios al tratar de incluir el schema 
> en el insert, por favor revisen que pudo haber pasado:
> 
> execute 'insert into ' || quote_ident(p_schema||'.'||p_tabla)::regclass 
>         || ' SELECT * FROM populate_record(null::'|| 
> quote_ident(p_schema||'.'||p_tabla)::regclass ||', $1)' using regrec;
> 
> El error:
> 
> NOTICE:  no existe la relación «public.clientesborradocopia»
> 
> Y la bendita tabla si existe.

No, estás tratando de usar el nombre-con-esquema como si fuera solamente
el nombre.  Debes aplicar quote_ident a cada parte separadamente.   Creo
que esto debería funcionar:

 execute 'insert into ' || (quote_ident(p_schema) 
||'.'||quote_ident(p_tabla))::regclass 

(mismo tratamiento a la siguiente línea), aunque honestamente en este
caso y dado que ya estás usando un cast a regclass yo usaría simplemente
el OID,

 execute 'insert into ' || TG_RELID::regclass 

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: Fwd: [pgsql-es-ayuda] OT Desesperado

[Carlos Agustín López Avila]

El 16/11/2011 01:34 p.m., Juan Manuel Acuña Barrera escribió:



Inicio del mensaje reenviado:

*De: *Miguel Angel Hernandez Moreno >

*Asunto: **Re: [pgsql-es-ayuda] OT Desesperado*
*Fecha: *16 de noviembre de 2011 13:17:55 CST
*Para: *Carlos Agustín López Avila >
*Cc: *Ayuda >


te equivocaste de lista

El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila 
mailto:cagusti...@gmail.com>> escribió:


Saludos a todos.
Me pueden ayudar con un problema que tengo en relación a diseñar
un procedimiento almacenado que actualiza una tabla en MySql
utilizando como fuente otra tabla pero que esta en MSSQL Server
2003. La BD de Mysql esta en un servidor Debian
Espero que el planteamiento no sea ambigüo.
Gracias.
-
Enviado a la lista de correo pgsql-es-ayuda
(pgsql-es-ayuda@postgresql.org
)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda




--
ISC Miguel Angel Hernandez Moreno



Quizá te puedan ayudar en:

mysql...@lists.mysql.com 

Saludos!

Juan Manuel Acuña.





Gracias Juan Manuel Acuña.

Fwd: [pgsql-es-ayuda] OT Desesperado

[Juan Manuel Acuña Barrera]

Inicio del mensaje reenviado:

> De: Miguel Angel Hernandez Moreno 
> Asunto: Re: [pgsql-es-ayuda] OT Desesperado
> Fecha: 16 de noviembre de 2011 13:17:55 CST
> Para: Carlos Agustín López Avila 
> Cc: Ayuda 
> 
> te equivocaste de lista
> 
> El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila 
>  escribió:
> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un 
> procedimiento almacenado que actualiza una tabla en MySql utilizando como 
> fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta en 
> un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
> 
> 
> 
> -- 
> ISC Miguel Angel Hernandez Moreno
> 


Quizá te puedan ayudar en:

mysql...@lists.mysql.com

Saludos!

Juan Manuel Acuña.

Re: [pgsql-es-ayuda] OT Desesperado

[Miguel Angel Hernandez Moreno]

te equivocaste de lista

El 16 de noviembre de 2011 12:59, Carlos Agustín López Avila <
cagusti...@gmail.com> escribió:

> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un
> procedimiento almacenado que actualiza una tabla en MySql utilizando como
> fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta
> en un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org
> **)
> Para cambiar tu suscripción:
> http://www.postgresql.org/**mailpref/pgsql-es-ayuda
>



-- 
ISC Miguel Angel Hernandez Moreno

Re: [pgsql-es-ayuda] OT Desesperado

[Cesar Erices]

El 16 de noviembre de 2011 14:59, Carlos Agustín López Avila <
cagusti...@gmail.com> escribió:

> Saludos a todos.
> Me pueden ayudar con un problema que tengo en relación a diseñar un
> procedimiento almacenado que actualiza una tabla en MySql utilizando como
> fuente otra tabla pero que esta en MSSQL Server 2003. La BD de Mysql esta
> en un servidor Debian
> Espero que el planteamiento no sea ambigüo.
> Gracias.
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org
> **)
> Para cambiar tu suscripción:
> http://www.postgresql.org/**mailpref/pgsql-es-ayuda
>


No es la lista apropiada para esta consulta

-- 
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alvaro Herrera]

Excerpts from Alejandro Carrillo's message of mié nov 16 11:58:30 -0300 2011:
> ¿Y entonces text como los almacena? ¿Acaso no los almacena tal y como vengan 
> para poder soportar datos binarios?

text almacena texto.  Cualquier texto -- siempre y cuando sea válido
para la codificación del servidor  (hago esta aclaración porque si bien
las codificaciones de un byte normalmente pueden almacenar cualquier
basura, otras codificaciones como UTF8 sólo tienen algunas secuencias de
bytes que son válidas, y rechazan aquellas que no lo son).

Si tratas de meter un bytea en texto, pueden pasar dos cosas: o bien es
convertido a la representación en texto del bytea (usando las secuencias
de escape que ya mencioné) o bien se meten los bytes tal como vienen.
Ambas tienen desventajas: en el primer caso, es ineficiente porque
gastas varios bytes para representar cada uno.  En el segundo caso la
cosa es muy mala (datos posiblemente corruptos), porque si después llega
alguien y extrae los datos con una codificación distinta, los bytes que
salgan pueden ser diferentes de los bytes que entraron.

Si guardas registros como hstore, las llaves y valores se almacenan
usando su representación en texto.  En el caso de imágenes y cosas así
(datos de tipo bytea), esto es ineficiente por el consumo de espacio;
pero la simplicidad de manejo y la flexibilidad que te da este mecanismo
de almacenamiento bien vale la pena.

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alvaro Herrera]

Excerpts from Alejandro Carrillo's message of mié nov 16 15:28:30 -0300 2011:
> Gracias a todos por ayudarme a crear un sistema de borrado físico.
> Creo que me hace falta especificar el schema de la tabla (ya que
> pueden haber 2 tablas con el mismo nombre) pero no se como obtenerlo
> desde el trigger.

Supongo que deberías especificar el esquema de la tabla, no solamente su
nombre.

Otra cosa ¿has considerado qué pasa si la versión actual de la tabla
difiere en columnas con la que tenía al momento de ejecutar el borrado?

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] OT Desesperado

[Carlos Agustín López Avila]

Saludos a todos.
Me pueden ayudar con un problema que tengo en relación a diseñar un 
procedimiento almacenado que actualiza una tabla en MySql utilizando 
como fuente otra tabla pero que esta en MSSQL Server 2003. La BD de 
Mysql esta en un servidor Debian

Espero que el planteamiento no sea ambigüo.
Gracias.
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] optimización de busqueda por like

[Alvaro Herrera]

Excerpts from Anita Ramirez's message of mar nov 15 15:11:24 -0300 2011:
> Buenas tardes,
> 
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno  se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2),

Eso me huele a mal diseño.  ¿No debería haber una llave foránea en
alumno que apunte a un registro específico en persona?  Si cada alumno
es también una persona, ¿qué sentido tiene almacenar los nombres y
apellidos en alumno, que ya están en persona?

> por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
> 
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 58 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
> igual", por lo que no me resulta.

Una idea simple sería tener dos índices, un btree normal y un btree con
varchar_pattern_ops.  Eso te permitiría usar búsquedas con LIKE y al
mismo tiempo con =.

> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.

Hay algo muy mal en tu sistema.

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] optimización de busqueda por like

[Emanuel Calvo]

El día 15 de noviembre de 2011 19:11, Anita Ramirez
 escribió:
>
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno  se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2), por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 58 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es igual",
> por lo que no me resulta.
>
> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.
>
> Alguna idea?
>
> Desde ya, gracias.
>
> Ana Ramirez.-
>


Migrar a 9.1 es una opción?

http://palominodb.com/blog/2011/10/12/indexing-text-columns-gist-or-gin-optimize-ilike-using-pgtrgm-postgres-91-part-1


-- 
--
              Emanuel Calvo
              Helpame.com
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] optimización de busqueda por like

[Rodriguez Fernando]

El 16/11/2011 01:22 p.m., Cesar Erices escribió:
El 15 de noviembre de 2011 14:11, Anita Ramirez > escribió:



Buenas tardes,

Resulta que tengo una función que realiza varias validaciones,
inserciones etc. Una de ellas es realizar búsqueda por like a una
tabla. Básicamente tengo dos tablas "alumno" y "persona", a cada
alumno  se debe buscar en la tabla persona, y para ello solo
contamos con nombres y apellidos (nombre completo, es decir en un
solo campo y campos separados, es decir nombre1, nombre2,
apellido1, apellido2), por lo que inicialmente procedemos a buscar
por "=", considerando mayusculas, minusculas, caracteres
especiales, si eso no emite resultado procedemos a buscar por like
en los campos separados, y si nuevamente no emite resultados, se
realiza nuevamente la búsqueda por like en el campo que contiene
el nombre y apellido completo.

La tabla persona en la que se realiza la búsqueda tiene
aproximadamente 58 registros. Probé con indices btree, y
también leí acerca de varchar_pattern_ops, pero con éste ultimo no
es posible utilizar "es igual", por lo que no me resulta.

Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
aproximadamente, lo cual es mas que excesivo.

Alguna idea?

Desde ya, gracias.

Ana Ramirez.-


Revisa los indices y pk, habitualmente esto se produce por un ml 
diseño de BBDD


atte.

--
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

Se certificó que el correo no contiene virus.
Comprobada por AVG - www.avg.es 
Versión: 2012.0.1869 / Base de datos de virus: 2092/4620 - Fecha de la 
versión: 16/11/2011



Hola, que caracteristicas tiene el equipo de la bd.
Como es la cnsulta de like que estas usando?
es  algo asi : select * from persona where  coalesce(apellido1,'')||' 
'||colaesce(apellido2,'')||' '||coalesce(nombre1,'')||' 
'||colaesce(nombre2,'') ilike '%rodriguez fernando%'


saludos fernando rodriguez

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] optimización de busqueda por like

[Cesar Erices]

El 15 de noviembre de 2011 14:11, Anita Ramirez escribió:

>
> Buenas tardes,
>
> Resulta que tengo una función que realiza varias validaciones, inserciones
> etc. Una de ellas es realizar búsqueda por like a una tabla. Básicamente
> tengo dos tablas "alumno" y "persona", a cada alumno  se debe buscar en la
> tabla persona, y para ello solo contamos con nombres y apellidos (nombre
> completo, es decir en un solo campo y campos separados, es decir nombre1,
> nombre2, apellido1, apellido2), por lo que inicialmente procedemos a buscar
> por "=", considerando mayusculas, minusculas, caracteres especiales, si eso
> no emite resultado procedemos a buscar por like en los campos separados, y
> si nuevamente no emite resultados, se realiza nuevamente la búsqueda por
> like en el campo que contiene el nombre y apellido completo.
>
> La tabla persona en la que se realiza la búsqueda tiene aproximadamente
> 58 registros. Probé con indices btree, y también leí acerca de
> varchar_pattern_ops, pero con éste ultimo no es posible utilizar "es
> igual", por lo que no me resulta.
>
> Tal cual como se encuentra ahora por 50 registros tarda 6 minutos
> aproximadamente, lo cual es mas que excesivo.
>
> Alguna idea?
>
> Desde ya, gracias.
>
> Ana Ramirez.-
>

Revisa los indices y pk, habitualmente esto se produce por un ml diseño de
BBDD

atte.

-- 
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alvaro Herrera]

Excerpts from Alejandro Carrillo's message of mié nov 16 10:52:26 -0300 2011:
> Entonces porque razón el unico tipo binario es bytea segun la documentación?
> http://www.postgresql.org/docs/9.1/static/datatype-binary.html

bytea almacena los bytes como bytes, tal como vienen.  La representación
en texto de un bytea convierte a secuencias de escape algunos o todos
los caracteres.

-- 
Álvaro Herrera 
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

Entonces porque razón el unico tipo binario es bytea segun la documentación?
http://www.postgresql.org/docs/9.1/static/datatype-binary.html




>
>De: Alvaro Herrera 
>Para: Alejandro Carrillo 
>CC: Jaime Casanova ; Ayuda 
>
>Enviado: martes 15 de noviembre de 2011 17:22
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Excerpts from Alejandro Carrillo's message of mar nov 15 17:35:58 -0300 2011:
>> Creo que ac谩 la pregunta es la siguiente y aplica tanto para tu c贸digo como 
>> para el mio. 驴Un tipo text puede grabar de forma efectiva datos binarios 
>> como fotos y archivos binarios de tal forma que esa informaci贸n se pueda 
>> recuperar hacia la tabla de donde provino?
>
>Claro que s铆; de otro modo pg_dump no podr铆a funcionar.
>
>-- 
>脕lvaro Herrera 
>-
>Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
>Para cambiar tu suscripci髇:
>http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>

Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

El objetivo de esto es que se pueda hacer select sobre la tabla borradoscopia 
de tal forma que se pueda recuperar uno u varios registros, dependiendo del 
criterio de busqueda

- Mensaje reenviado -
>De: Alejandro Carrillo 
>Para: "pgsql-es-ayuda@postgresql.org" 
>CC: "alvhe...@alvh.no-ip.org" 
>Enviado: martes 15 de noviembre de 2011 10:56
>Asunto: Re: [pgsql-es-ayuda] recorrer old
>
>
>Siguiendo con el tema, tengo un problema ya que al grabar en la tabla 
>borradoscopia los campos y sus valores, no los graba en el orden de creación 
>de los campos en la tabla, sino en el orden que le da la gana. Esto es debido 
>a la función hstore que ejecuta ese trabajo de esa forma. ¿Como podría cambiar 
>este orden (usando alguna funcion de hstore) de tal forma que aparezcan 
>ordenados usando el orden de creación en la tabla de la BD?
>
>
>Gracias
>
>
>Anexo function actual
>
>
>
>/* esta funcion va asociada a todos los triggers de cada tabla donde se deseé 
>el borrado fisico con copia*/
>create or replace function public.fn_borradocopia () returns trigger
>as
>$$
>declare 
>    arrDatos bytea[]; 
>   
 arrCampos bytea[]; 
>    i integer := 1;
>    r record;
>begin    
>    FOR r IN SELECT (each(hstore(OLD))).* 
>    LOOP 
>        arrCampos[i] := r.key;
>        arrDatos[i] := r.value; 
>        --RAISE NOTICE 'key:%, value: %', r.key, r.value; 
>        i=i+1;
>    END LOOP;
>    insert into borradoscopia values (TG_RELNAME,arrCampos,arrDatos);
>    return OLD;
>end;
>$$
>LANGUAGE plpgsql VOLATILE
>  COST 100;
>
>--aca van cada trigger para cada tabla
>drop TRIGGER trg_borradocopia on clientesborradocopia;
>CREATE TRIGGER trg_borradocopia BEFORE DELETE ON clientesborradocopia
>    FOR EACH ROW EXECUTE PROCEDURE  fn_borradocopia () ;  
>
>DELETE from clientesborradocopia where idcliente = 1
>
>
>
>>
>>De: Alejandro Carrillo 
>>Para: Alvaro Herrera 
>>CC: "pgsql-es-ayuda@postgresql.org" 
>>Enviado: martes 8 de noviembre de 2011 14:51
>>Asunto: Re: [pgsql-es-ayuda] recorrer old
>>
>>
>>jajajaj muy chistoso. ¿O es que en postgresql no soporta arrays 
>>multidimensionales en una funcion?
>>
>>
>>
>>
>>>
>>>De: Alvaro Herrera 
>>>Para: Alejandro Carrillo 
>>>CC: Ayuda 
>>>Enviado: martes 8 de noviembre de 2011 14:47
>>>Asunto: Re: [pgsql-es-ayuda] recorrer old
>>>
>>>
>>>Excerpts from Alejandro Carrillo's message of mar nov 08 15:47:43 -0300 2011:
 porq la tabla solo tiene 2 campos:
 
 drop TABLE borradoscopia;
 
 CREATE TABLE borradoscopia
 (
   tabla character varying(80) NOT NULL,
   registro bytea[][] NOT NULL 
 );
>>>
>>>entonces borrala y hazla de nuevo.
>>>
>>>-- 
>>>Álvaro Herrera 
>>>
>>>
>>>
>>
>>
>
>

Re: Rv: [pgsql-es-ayuda] recorrer old

[Alejandro Carrillo]

Pero, entonces como podría hacer para garantizar la integridad de campos tipo 
binario como foto, archivo, etc? ¿hstore me lo permite?




>
>De: Alvaro Herrera 
>Para: Alejandro Carrillo 
>CC: Ayuda 
>Enviado: martes 15 de noviembre de 2011 12:06
>Asunto: Re: Rv: [pgsql-es-ayuda] recorrer old
>
>
>Excerpts from Alejandro Carrillo's message of mar nov 15 13:37:20 -0300 2011:
>> como seria con hstore?
>
>WHERE campo_hstore -> 'columna' = 'valor'
>
>La documentación de hstore tiene un listado de operadores: 
>http://www.postgresql.org/docs/9.1/static/hstore.html
>
>-- 
>Álvaro Herrera 
>
>
>