Re: Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4

Saludos, listeros.
Quisiera tener un ambiente de desarrollo en mi Linux para cada versión
de PostgreSQL. He visto que algunos tenían esto; lo que quiero es que en
mi misma PC tenga por ejemplo un directorio que actúe como si fuera una
PC diferente con todas las librerías y programas que necesita PostgreSQL
para correr; algo parecido a las llamadas Zonas en Open Solaris, y a las
Jaulas en FreeBSD; las cuales actúan como si fueran un sistema operativo
más.

¿Alguien ha hecho esto en Debian o algunos de sus derivados?

Saludos

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
http://personas.grm.uci.cu/+marcos

Centro de Tecnologías de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
> Saludos, listeros.
> Quisiera tener un ambiente de desarrollo en mi Linux para cada versión de
> PostgreSQL.

no te entendi claramente pero yo hago esto tan solo indicando un
directorio diferente en el --prefix y un puerto no utilizado en
--with-pgport al ejecutar ./configure

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

> -----Mensaje original-----
> De: pgsql-es-ayuda-owner(at)postgresql(dot)org
> [mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de
> Ing. Marcos Ortiz Valmaseda
> Enviado el: Viernes, 12 de Marzo de 2010 17:19
> Para: POSTGRESQL - Ayuda
> Asunto: [pgsql-es-ayuda] Ambientes de Desarrollo para
> versiones de PostgreSQL-8.4 y para 9.0alpha4
>
> Saludos, listeros.
> Quisiera tener un ambiente de desarrollo en mi Linux para
> cada versión de PostgreSQL. He visto que algunos tenían esto;
> lo que quiero es que en mi misma PC tenga por ejemplo un
> directorio que actúe como si fuera una PC diferente con todas
> las librerías y programas que necesita PostgreSQL para
> correr; algo parecido a las llamadas Zonas en Open Solaris, y
> a las Jaulas en FreeBSD; las cuales actúan como si fueran un
> sistema operativo más.
>
> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?
>
>

En debian/ubuntu está previsto en los packages para que coexistan múltiples
versiones instaladas.
Te quedarán prolijamente instalados en /var/lib/postgresql/8.x y la
configuración en /etc/postgresql/8.x
Luego con variables de entorno puedes definir que versión utilizar.
Lógicamente deberás configurar cada motor en un puerto distinto.

Pero me da la impresión que lo que vos estás necesitando realmente es
virtualizar.
Aquí tienes los howtos de Xen: http://wiki.xensource.com/xenwiki/

Saludos,
Fernando.

Fernando Hevia escribió:
>
>
>
>> -----Mensaje original-----
>> De: pgsql-es-ayuda-owner(at)postgresql(dot)org
>> [mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de
>> Ing. Marcos Ortiz Valmaseda
>> Enviado el: Viernes, 12 de Marzo de 2010 17:19
>> Para: POSTGRESQL - Ayuda
>> Asunto: [pgsql-es-ayuda] Ambientes de Desarrollo para
>> versiones de PostgreSQL-8.4 y para 9.0alpha4
>>
>> Saludos, listeros.
>> Quisiera tener un ambiente de desarrollo en mi Linux para
>> cada versión de PostgreSQL. He visto que algunos tenían esto;
>> lo que quiero es que en mi misma PC tenga por ejemplo un
>> directorio que actúe como si fuera una PC diferente con todas
>> las librerías y programas que necesita PostgreSQL para
>> correr; algo parecido a las llamadas Zonas en Open Solaris, y
>> a las Jaulas en FreeBSD; las cuales actúan como si fueran un
>> sistema operativo más.
>>
>> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?
>>
>>
>>
>
> En debian/ubuntu está previsto en los packages para que coexistan múltiples
> versiones instaladas.
> Te quedarán prolijamente instalados en /var/lib/postgresql/8.x y la
> configuración en /etc/postgresql/8.x
> Luego con variables de entorno puedes definir que versión utilizar.
> Lógicamente deberás configurar cada motor en un puerto distinto.
>
> Pero me da la impresión que lo que vos estás necesitando realmente es
> virtualizar.
> Aquí tienes los howtos de Xen: http://wiki.xensource.com/xenwiki/
>
> Saludos,
> Fernando.
>
>
No, no es virtualización lo que necesito.
Lo que quiero hacer es un definir un ambiente para cada versión, igual
que lo hace FreeBSD con las jaulas.
Recuerdo que en el curso que impatieron Álvaro y tú acá Jaime, él tenía
algo parecido en su laptop, la cual tiene Debian instalado si mal no
recuerdo.

Él ejecutaba pgsql84env si mal no recuerdo, y dentro del mismo prompt de
comandos se levantaba una especie de environment donde tenía corriendo
dicha versión de PostgreSQL.

No sé si me hago entender.

Saludos

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
http://personas.grm.uci.cu/+marcos

Centro de Tecnologías de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
>
> Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
> esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
> prompt de comandos le salía una especie de environment usando esta versión
> de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
> instalado en su PC si mal no recuerdo.
>

ah! pero sino me equivoco eso ha de ser solo un script que cambia el
directorio levanta la base apropiada y setea variables de ambiente...

aunque si se veia bonito y es mejor que hacerlo manualmente ;)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova escribió:
> 2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
>
>> Saludos, listeros.
>> Quisiera tener un ambiente de desarrollo en mi Linux para cada versión de
>> PostgreSQL.
>>
>
> no te entendi claramente pero yo hago esto tan solo indicando un
> directorio diferente en el --prefix y un puerto no utilizado en
> --with-pgport al ejecutar ./configure
>
>
>
Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su
laptop esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en
el mismo prompt de comandos le salía una especie de environment usando
esta versión de PostgreSQL, y creo que lo hizo con Debian, porque es lo
que tiene instalado en su PC si mal no recuerdo.

Esto es lo que queremos lograr acá, porque no podemos darlos el lujo de
tener varias versiones de PostgreSQL corriendo, o varias máquivas
virtuales en una misma PC, porque no tenemos esa cantidad de recursos.
Lo ideal sería hacerlo con las jaulas de FreeBSD, pero no contamos con
un repo completo del mismo aquí en la Universidad; ojalá lo tuviéramos.

No sé si me hago explicar

P.D: Fernando, la idea de virtualización ya la habiamos valorado pero no
es lo que queremos.

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
http://personas.grm.uci.cu/+marcos

Centro de Tecnologías de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
>
> Umm, ya entendí.
> OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la pregunta
> aquí para si otro a lo mejor quiera hacer lo mismo compartirlo con todos.
>

de eso no me quejo!!! no me vendria nada mal ese script, siempre lo
hago manualmente y me da pereza pensar en el script ;)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova escribió:
> 2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
>
>> Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
>> esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
>> prompt de comandos le salía una especie de environment usando esta versión
>> de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
>> instalado en su PC si mal no recuerdo.
>>
>>
>
> ah! pero sino me equivoco eso ha de ser solo un script que cambia el
> directorio levanta la base apropiada y setea variables de ambiente...
>
> aunque si se veia bonito y es mejor que hacerlo manualmente ;)
>
>
Umm, ya entendí.
OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la pregunta
aquí para si otro a lo mejor quiera hacer lo mismo compartirlo con todos.

Saludos

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
http://personas.grm.uci.cu/+marcos

Centro de Tecnologías de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

Ing. Marcos Ortiz Valmaseda escribió:
> Jaime Casanova escribió:
> >2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
> >>Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
> >>esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
> >>prompt de comandos le salía una especie de environment usando esta versión
> >>de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
> >>instalado en su PC si mal no recuerdo.
> >>
> >
> >ah! pero sino me equivoco eso ha de ser solo un script que cambia el
> >directorio levanta la base apropiada y setea variables de ambiente...
> >
> >aunque si se veia bonito y es mejor que hacerlo manualmente ;)
> >
> Umm, ya entendí.
> OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la
> pregunta aquí para si otro a lo mejor quiera hacer lo mismo
> compartirlo con todos.

Este es mi script. Se llama "runpg" y hace muchas cosas, dependiendo
del segundo parámetro (el primer parámetro lo describo más adelante).
"config" invoca configure con los parámetros estándar (que yo defino
dentro del mismo script, o bien los puedo sobreescribir con un archivo
CONFIGURE_ARGS dentro del árbol del código fuente); "build" construye
(make); "install" hace un make install; "init" hace un initdb en la
ubicación estándar que yo defino; "server" echa a andar el postmaster;
"client" abre un psql; "check" y "pcheck" son para ejecutar los tests de
regresión, serial y paralelo respectivamente (requiere tener el server
andando); tags actualiza el archivo de ctags y cscope; changelog genera
el archivo ChangeLog para esa rama usando cvs2cl; rmderived borra los
archivos derivados; update hace un cvs update; showdiff hace un cvs diff
y lo pasa por un pager (obviamente puedes redirigirlo si quieres guardar
el parche en un archivo); touchchanged hace un "touch" de todos los
archivos modificados (esto sirve para forzar a que se recompilen); edit
abre un "vi -g" en el directorio base del código fuente.

Si uno hace "runpg commands" da una lista de órdenes que conoce (esto es
útil para el "bash completion")

El primer parámetro debe ser el nombre de un "cvs checkout" de una rama,
y el nombre debe empezar con un número, el cual se suma a 55432 para
obtener el nombre de puerto base que se pasa a --with-pgport. (Yo uso
nombres como "84_rel" y así, de manera que cada nombre es fácil de
recordar y quedan en puertos distintos, así que puedo tener los servers
corriendo simultáneamente).

Si uno le da el nombre de la rama pero ninguna otra opción, emite una
serie de definiciones de variables de ambiente. Eso se puede agregar al
ambiente existente. Por ej. yo uso `runpg 84_rel` y define PGDATA,
PGPORT, y otras cosas útiles.

El código se debe poner en un directorio con esta estructura:

pgsql/
source/
84_rel
83_rel
etc
build/
84_rel
etc
install/
(Esto se ubica en /pgsql normalmente, pero uno puede definir la variable
de ambiente PGROOT para cambiar esto. Yo tengo "export
PGROOT=~/Code/pgsql" o algo por el estilo).

Cuando uno hace "config" de una rama del source, se crea el directorio
dentro de build y se ejecuta configure allí; los .o quedan en ese otro
directorio (esto se conoce como una construcción VPATH).

Además tengo un mecanismo rudimentario pero suficiente para hacer
completación automática de órdenes en bash. Finalmente, tengo un
pequeño script que define funciones para cambiar de un directorio a
otro, por ej. si estás en source/84_rel/src/backend y ejecutas "cdbld"
te deja parado en build/84_rel/src/backend. También existen cdinst y
cdsrc. Además cdpg que te posiciona en pgsql/ (si es que no le pasas
ningún parámetro) o bien puedes hacer cdpg 84_rel y te deja en
pgsql/84_rel. Como también tiene completación automática, puedes darle
cdpg 84<tab> y luego te va completando con los directorios que existen
dentro (o sea cdpg 84<tab>s<tab>bac<tab> te completa a
84_rel/src/backend, etc etc)

Hace unos años le pasé este script a Michael Glaesemann y él hizo unas
cuantas modificaciones para sus propósitos, que yo nunca llegué a
adoptar (por pereza, no porque no me gustaran). A Germán Poo también se
lo pasé años después, y él hizo un repositorio Mercurial en alguna
parte ... ahh, acá está: http://pgsql.calcifer.org/settings/ ... ah!
si me hubiera acordado de verlo antes me habría ahorrado tener que
escribir la explicación otra vez!!

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)

"Ing . Marcos Luís Ortíz Valmaseda" escribió:

> Sencillamente genial !!!!
> No tengo palabras para esto.

Siempre que escucho esto me acuerdo del Transmogrificador:
http://progressiveboink.com/archive/calvinhobbes.htm
(buscar por "Words fail me", pero todo el homenaje es muy divertido)

> Realmente veo que pensaste en todo aquí.

No, le fui agregando cosas de a poco a medida que las necesité :-)
Y tiene varias cosas que corregirle; por ejemplo lo del CONFIGURE_ARGS
no me gusta nada. Me gustaría que hubiera un directorio para dejar
parches, y poder aplicar y desaplicar. Me gustaría que tuviera otra
forma de configurarse. Me gustaría que pudiera tener más de un
directorio "build" para un mismo directorio source. Me gustaría poder
construir en el mismo directorio en vez de usar VPATH (útil para probar
parches que arreglan problemas con VPATH, para verificar que no echan a
perder el caso normal no-VPATH).

> Veo que los únicos sistemas de control de versiones que tienes
> soportados son CVS y Subversion, ya que veo que Git no está
> soportado.
> Me gusta Git para trabajar, así que voy a hacerle unas
> modificaciones para que lo soporte. Luego que lo termine, te lo paso
> si quieres.

Le puse soporte para showdiff solamente, pero como el modelo de "update"
y demás es tan diferente, no me metí mucho (nota que la versión de
Germán Poo tiene un comentario similar respecto de "update"). Uso git
directamente. Claro que no tengo muchos árboles con git; para casi todo
sigo usando CVS. Sólo en un árbol con Mammoth Replicator uso git.

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)

Alvaro Herrera escribió:
> Ing. Marcos Ortiz Valmaseda escribió:
>
>> Jaime Casanova escribió:
>>
>>> 2010/3/12 Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>:
>>>
>>>> Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
>>>> esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
>>>> prompt de comandos le salía una especie de environment usando esta versión
>>>> de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
>>>> instalado en su PC si mal no recuerdo.
>>>>
>>>>
>>> ah! pero sino me equivoco eso ha de ser solo un script que cambia el
>>> directorio levanta la base apropiada y setea variables de ambiente...
>>>
>>> aunque si se veia bonito y es mejor que hacerlo manualmente ;)
>>>
>>>
>> Umm, ya entendí.
>> OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la
>> pregunta aquí para si otro a lo mejor quiera hacer lo mismo
>> compartirlo con todos.
>>
>
> Este es mi script. Se llama "runpg" y hace muchas cosas, dependiendo
> del segundo parámetro (el primer parámetro lo describo más adelante).
> "config" invoca configure con los parámetros estándar (que yo defino
> dentro del mismo script, o bien los puedo sobreescribir con un archivo
> CONFIGURE_ARGS dentro del árbol del código fuente); "build" construye
> (make); "install" hace un make install; "init" hace un initdb en la
> ubicación estándar que yo defino; "server" echa a andar el postmaster;
> "client" abre un psql; "check" y "pcheck" son para ejecutar los tests de
> regresión, serial y paralelo respectivamente (requiere tener el server
> andando); tags actualiza el archivo de ctags y cscope; changelog genera
> el archivo ChangeLog para esa rama usando cvs2cl; rmderived borra los
> archivos derivados; update hace un cvs update; showdiff hace un cvs diff
> y lo pasa por un pager (obviamente puedes redirigirlo si quieres guardar
> el parche en un archivo); touchchanged hace un "touch" de todos los
> archivos modificados (esto sirve para forzar a que se recompilen); edit
> abre un "vi -g" en el directorio base del código fuente.
>
> Si uno hace "runpg commands" da una lista de órdenes que conoce (esto es
> útil para el "bash completion")
>
> El primer parámetro debe ser el nombre de un "cvs checkout" de una rama,
> y el nombre debe empezar con un número, el cual se suma a 55432 para
> obtener el nombre de puerto base que se pasa a --with-pgport. (Yo uso
> nombres como "84_rel" y así, de manera que cada nombre es fácil de
> recordar y quedan en puertos distintos, así que puedo tener los servers
> corriendo simultáneamente).
>
> Si uno le da el nombre de la rama pero ninguna otra opción, emite una
> serie de definiciones de variables de ambiente. Eso se puede agregar al
> ambiente existente. Por ej. yo uso `runpg 84_rel` y define PGDATA,
> PGPORT, y otras cosas útiles.
>
> El código se debe poner en un directorio con esta estructura:
>
> pgsql/
> source/
> 84_rel
> 83_rel
> etc
> build/
> 84_rel
> etc
> install/
> (Esto se ubica en /pgsql normalmente, pero uno puede definir la variable
> de ambiente PGROOT para cambiar esto. Yo tengo "export
> PGROOT=~/Code/pgsql" o algo por el estilo).
>
> Cuando uno hace "config" de una rama del source, se crea el directorio
> dentro de build y se ejecuta configure allí; los .o quedan en ese otro
> directorio (esto se conoce como una construcción VPATH).
>
> Además tengo un mecanismo rudimentario pero suficiente para hacer
> completación automática de órdenes en bash. Finalmente, tengo un
> pequeño script que define funciones para cambiar de un directorio a
> otro, por ej. si estás en source/84_rel/src/backend y ejecutas "cdbld"
> te deja parado en build/84_rel/src/backend. También existen cdinst y
> cdsrc. Además cdpg que te posiciona en pgsql/ (si es que no le pasas
> ningún parámetro) o bien puedes hacer cdpg 84_rel y te deja en
> pgsql/84_rel. Como también tiene completación automática, puedes darle
> cdpg 84<tab> y luego te va completando con los directorios que existen
> dentro (o sea cdpg 84<tab>s<tab>bac<tab> te completa a
> 84_rel/src/backend, etc etc)
>
>
> Hace unos años le pasé este script a Michael Glaesemann y él hizo unas
> cuantas modificaciones para sus propósitos, que yo nunca llegué a
> adoptar (por pereza, no porque no me gustaran). A Germán Poo también se
> lo pasé años después, y él hizo un repositorio Mercurial en alguna
> parte ... ahh, acá está: http://pgsql.calcifer.org/settings/ ... ah!
> si me hubiera acordado de verlo antes me habría ahorrado tener que
> escribir la explicación otra vez!!
>
>
>
Sencillamente genial !!!!
No tengo palabras para esto.
Con esto creo que ya tengo el trabajo bastante adelantado para el
desarrollo.
Realmente veo que pensaste en todo aquí.

Veo que los únicos sistemas de control de versiones que tienes
soportados son CVS y Subversion, ya que veo que Git no está soportado.
Me gusta Git para trabajar, así que voy a hacerle unas modificaciones
para que lo soporte. Luego que lo termine, te lo paso si quieres.

Saludos y gracias de nuevo.

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu

Centro de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

2010/3/12 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
>
> Este es mi script.  Se llama "runpg" y hace muchas cosas,

hace "bastantes" cosas de hecho...
Cuando crezca quiero se como tu ;)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Virtualiza y listo.

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas

*-Soporte PostgreSQL

*-www.jqmicrosistemas.com
*-809-849-8087
*-------------------------------------------------------*

> Date: Fri, 12 Mar 2010 15:18:43 -0500
> From: mlortiz(at)uci(dot)cu
> To: pgsql-es-ayuda(at)postgresql(dot)org
> Subject: [pgsql-es-ayuda] Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4
>
> Saludos, listeros.
> Quisiera tener un ambiente de desarrollo en mi Linux para cada versión
> de PostgreSQL. He visto que algunos tenían esto; lo que quiero es que en
> mi misma PC tenga por ejemplo un directorio que actúe como si fuera una
> PC diferente con todas las librerías y programas que necesita PostgreSQL
> para correr; algo parecido a las llamadas Zonas en Open Solaris, y a las
> Jaulas en FreeBSD; las cuales actúan como si fueran un sistema operativo
> más.
>
> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?
>
>
> Saludos
>
> --
> --------------------------------------------------------
> -- Ing. Marcos Luís Ortíz Valmaseda --
> -- Twitter: http://twitter.com/@marcosluis2186 --
> -- FreeBSD Fan/User --
> -- http://www.freebsd.org/es --
> -- Linux User # 418229 --
> -- Database Architect/Administrator --
> -- PostgreSQL RDBMS --
> -- http://www.postgresql.org --
> -- http://planetpostgresql.org --
> -- http://www.postgresql-es.org --
> --------------------------------------------------------
> -- Data WareHouse -- Business Intelligence Apprentice --
> -- http://www.tdwi.org --
> --------------------------------------------------------
> -- Ruby on Rails Fan/Developer --
> -- http://rubyonrails.org --
> --------------------------------------------------------
>
> Comunidad Técnica Cubana de PostgreSQL
> http://postgresql.uci.cu
> http://personas.grm.uci.cu/+marcos
>
> Centro de Tecnologías de Gestión de Datos (DATEC)
> Contacto:
> Correo: centalad(at)uci(dot)cu
> Telf: +53 07-837-3737
> +53 07-837-3714
> Universidad de las Ciencias Informáticas
> http://www.uci.cu
>
>
>
> --
> TIP 4: No hagas 'kill -9' a postmaster

_________________________________________________________________

Sería mejor virtualizar, si es en tu pc utilizar virtualbox o si es un servidor utilizar XEN.

Saludos

Marcelo Silva
Quito - Ecuador

________________________________
De: Ing. Marcos Ortiz Valmaseda <mlortiz(at)uci(dot)cu>
Para: POSTGRESQL - Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Enviado: vie, marzo 12, 2010 3:18:43 PM
Asunto: [pgsql-es-ayuda] Ambientes de Desarrollo para versiones de PostgreSQL-8.4 y para 9.0alpha4

Saludos, listeros.
Quisiera tener un ambiente de desarrollo en mi Linux para cada versión de PostgreSQL. He visto que algunos tenían esto; lo que quiero es que en mi misma PC tenga por ejemplo un directorio que actúe como si fuera una PC diferente con todas las librerías y programas que necesita PostgreSQL para correr; algo parecido a las llamadas Zonas en Open Solaris, y a las Jaulas en FreeBSD; las cuales actúan como si fueran un sistema operativo más.

¿Alguien ha hecho esto en Debian o algunos de sus derivados?

Saludos

-- -------------------------------------------------------- -- Ing. Marcos Luís Ortíz Valmaseda --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
-------------------------------------------------------- -- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu
http://personas.grm.uci.cu/+marcos
Centro de Tecnologías de Gestión de Datos (DATEC) Contacto: Correo: centalad(at)uci(dot)cu Telf: +53 07-837-3737 +53 07-837-3714 Universidad de las Ciencias Informáticas http://www.uci.cu

--
TIP 4: No hagas 'kill -9' a postmaster

____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8.
http://downloads.yahoo.com/ieak8/?l=e1

Ing. Marcos Ortiz Valmaseda dijo [Fri, Mar 12, 2010 at 03:18:43PM -0500]:
> Saludos, listeros.
> Quisiera tener un ambiente de desarrollo en mi Linux para cada versión
> de PostgreSQL. He visto que algunos tenían esto; lo que quiero es que en
> mi misma PC tenga por ejemplo un directorio que actúe como si fuera una
> PC diferente con todas las librerías y programas que necesita PostgreSQL
> para correr; algo parecido a las llamadas Zonas en Open Solaris, y a las
> Jaulas en FreeBSD; las cuales actúan como si fueran un sistema operativo
> más.
>
> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?

En Debian es lo normal, de hecho, es como haces una migración de
versión de PostgreSQL: Si mañana sale PostgreSQL 8.5, me aparecerá el
paquete (en mi entorno, que es inestable - en estable toca esperar un
poco más ;-) ), éste quedará instalado con un espacio ("cluster") en
/var/lib/postgresql/8.5/main - Actualmente tengo el mío en
/var/lib/postgresql/8.4/main, y puedes tener varias versiones
instaladas de manera simultánea.

Ahora, tú mencionas específicamente algo que huele a
virtualización. Para eso, sí, tendrías que usar un método de
virtualización como vservers, openvz, Xen, KVM o similares... Pero en
realidad no hace falta. Si quieres tener instalaciones de PostgreSQL
completamente independientes entre sí, crea varios clusters. Para ver
cómo hacer esto, asómate a
/usr/share/doc/postgresql-common/README.Debian.gz — No hay pierde.

Saludos,

--
Gunnar Wolf • gwolf(at)gwolf(dot)org • (+52-55)5623-0154 / 1451-2244

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

En ubuntu hardy heron lo que nosotros utilizamos es: pg_createcluster

http://pwet.fr/man/linux/administration_systeme/pg_createcluster

Petru Ghita

On 12/03/2010 21:18, Ing. Marcos Ortiz Valmaseda wrote:
> Saludos, listeros. Quisiera tener un ambiente de desarrollo en mi
> Linux para cada versión de PostgreSQL. He visto que algunos tenían
> esto; lo que quiero es que en mi misma PC tenga por ejemplo un
> directorio que actúe como si fuera una PC diferente con todas las
> librerías y programas que necesita PostgreSQL para correr; algo
> parecido a las llamadas Zonas en Open Solaris, y a las Jaulas en
> FreeBSD; las cuales actúan como si fueran un sistema operativo
> más.
>
> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?
>
>
> Saludos
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkufNGsACgkQt6IL6XzynQRugACfXK6Ecu/nEImIAcVNXTkdAuSd
/KIAn33Camk33MMn4y0Yr3Ku4Y2FrDJs
=SSpk
-----END PGP SIGNATURE-----

Gunnar Wolf escribió:
> Ing. Marcos Ortiz Valmaseda dijo [Fri, Mar 12, 2010 at 03:18:43PM -0500]:
>
>> Saludos, listeros.
>> Quisiera tener un ambiente de desarrollo en mi Linux para cada versión
>> de PostgreSQL. He visto que algunos tenían esto; lo que quiero es que en
>> mi misma PC tenga por ejemplo un directorio que actúe como si fuera una
>> PC diferente con todas las librerías y programas que necesita PostgreSQL
>> para correr; algo parecido a las llamadas Zonas en Open Solaris, y a las
>> Jaulas en FreeBSD; las cuales actúan como si fueran un sistema operativo
>> más.
>>
>> ¿Alguien ha hecho esto en Debian o algunos de sus derivados?
>>
>
> En Debian es lo normal, de hecho, es como haces una migración de
> versión de PostgreSQL: Si mañana sale PostgreSQL 8.5, me aparecerá el
> paquete (en mi entorno, que es inestable - en estable toca esperar un
> poco más ;-) ), éste quedará instalado con un espacio ("cluster") en
> /var/lib/postgresql/8.5/main - Actualmente tengo el mío en
> /var/lib/postgresql/8.4/main, y puedes tener varias versiones
> instaladas de manera simultánea.
>
> Ahora, tú mencionas específicamente algo que huele a
> virtualización. Para eso, sí, tendrías que usar un método de
> virtualización como vservers, openvz, Xen, KVM o similares... Pero en
> realidad no hace falta. Si quieres tener instalaciones de PostgreSQL
> completamente independientes entre sí, crea varios clusters. Para ver
> cómo hacer esto, asómate a
> /usr/share/doc/postgresql-common/README.Debian.gz — No hay pierde.
>
> Saludos,
>
>
Gracias por los comentarios, tomaré consejos y veré que hago
Saludos

--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- FreeBSD Fan/User --
-- http://www.freebsd.org/es --
-- Linux User # 418229 --
-- Database Architect/Administrator --
-- PostgreSQL RDBMS --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
--------------------------------------------------------
-- Data WareHouse -- Business Intelligence Apprentice --
-- http://www.tdwi.org --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
--------------------------------------------------------

Comunidad Técnica Cubana de PostgreSQL
http://postgresql.uci.cu

Centro de Gestión de Datos (DATEC)
Contacto:
Correo: centalad(at)uci(dot)cu
Telf: +53 07-837-3737
+53 07-837-3714
Universidad de las Ciencias Informáticas
http://www.uci.cu

El 12/03/10 18:30, Alvaro Herrera escribió:
> Ing. Marcos Ortiz Valmaseda escribió:
>
>> Jaime Casanova escribió:
>>
>>> 2010/3/12 Ing. Marcos Ortiz Valmaseda<mlortiz(at)uci(dot)cu>:
>>>
>>>> Recuerdo Jaime, que cuando Álvaro y tú vinieron acá, él tenía en su laptop
>>>> esto configurado. Él ejecutaba pgsql84env si mal no recuerdo y en el mismo
>>>> prompt de comandos le salía una especie de environment usando esta versión
>>>> de PostgreSQL, y creo que lo hizo con Debian, porque es lo que tiene
>>>> instalado en su PC si mal no recuerdo.
>>>>
>>>>
>>> ah! pero sino me equivoco eso ha de ser solo un script que cambia el
>>> directorio levanta la base apropiada y setea variables de ambiente...
>>>
>>> aunque si se veia bonito y es mejor que hacerlo manualmente ;)
>>>
>>>
>> Umm, ya entendí.
>> OK, tendré que preguntarle entonces a él cómo lo hizo, lancé la
>> pregunta aquí para si otro a lo mejor quiera hacer lo mismo
>> compartirlo con todos.
>>
> Este es mi script. Se llama "runpg" y hace muchas cosas, dependiendo
> del segundo parámetro (el primer parámetro lo describo más adelante).
> "config" invoca configure con los parámetros estándar (que yo defino
> dentro del mismo script, o bien los puedo sobreescribir con un archivo
> CONFIGURE_ARGS dentro del árbol del código fuente); "build" construye
> (make); "install" hace un make install; "init" hace un initdb en la
> ubicación estándar que yo defino; "server" echa a andar el postmaster;
> "client" abre un psql; "check" y "pcheck" son para ejecutar los tests de
> regresión, serial y paralelo respectivamente (requiere tener el server
> andando); tags actualiza el archivo de ctags y cscope; changelog genera
> el archivo ChangeLog para esa rama usando cvs2cl; rmderived borra los
> archivos derivados; update hace un cvs update; showdiff hace un cvs diff
> y lo pasa por un pager (obviamente puedes redirigirlo si quieres guardar
> el parche en un archivo); touchchanged hace un "touch" de todos los
> archivos modificados (esto sirve para forzar a que se recompilen); edit
> abre un "vi -g" en el directorio base del código fuente.
>
> Si uno hace "runpg commands" da una lista de órdenes que conoce (esto es
> útil para el "bash completion")
>
> El primer parámetro debe ser el nombre de un "cvs checkout" de una rama,
> y el nombre debe empezar con un número, el cual se suma a 55432 para
> obtener el nombre de puerto base que se pasa a --with-pgport. (Yo uso
> nombres como "84_rel" y así, de manera que cada nombre es fácil de
> recordar y quedan en puertos distintos, así que puedo tener los servers
> corriendo simultáneamente).
>
> Si uno le da el nombre de la rama pero ninguna otra opción, emite una
> serie de definiciones de variables de ambiente. Eso se puede agregar al
> ambiente existente. Por ej. yo uso `runpg 84_rel` y define PGDATA,
> PGPORT, y otras cosas útiles.
>
> El código se debe poner en un directorio con esta estructura:
>
> pgsql/
> source/
> 84_rel
> 83_rel
> etc
> build/
> 84_rel
> etc
> install/
> (Esto se ubica en /pgsql normalmente, pero uno puede definir la variable
> de ambiente PGROOT para cambiar esto. Yo tengo "export
> PGROOT=~/Code/pgsql" o algo por el estilo).
>
> Cuando uno hace "config" de una rama del source, se crea el directorio
> dentro de build y se ejecuta configure allí; los .o quedan en ese otro
> directorio (esto se conoce como una construcción VPATH).
>
> Además tengo un mecanismo rudimentario pero suficiente para hacer
> completación automática de órdenes en bash. Finalmente, tengo un
> pequeño script que define funciones para cambiar de un directorio a
> otro, por ej. si estás en source/84_rel/src/backend y ejecutas "cdbld"
> te deja parado en build/84_rel/src/backend. También existen cdinst y
> cdsrc. Además cdpg que te posiciona en pgsql/ (si es que no le pasas
> ningún parámetro) o bien puedes hacer cdpg 84_rel y te deja en
> pgsql/84_rel. Como también tiene completación automática, puedes darle
> cdpg 84<tab> y luego te va completando con los directorios que existen
> dentro (o sea cdpg 84<tab>s<tab>bac<tab> te completa a
> 84_rel/src/backend, etc etc)
>
>
> Hace unos años le pasé este script a Michael Glaesemann y él hizo unas
> cuantas modificaciones para sus propósitos, que yo nunca llegué a
> adoptar (por pereza, no porque no me gustaran). A Germán Poo también se
> lo pasé años después, y él hizo un repositorio Mercurial en alguna
> parte ... ahh, acá está: http://pgsql.calcifer.org/settings/ ... ah!
> si me hubiera acordado de verlo antes me habría ahorrado tener que
> escribir la explicación otra vez!!
>
>
>
Álvaro, estaba leyendo tu correo sobre el script que utilizas para el
mantenimiento de varias versiones de PostgreSQL en tu PC, y me quedó una
duda. Me dices acá que runpg config: ejecuta el ./configure de manera
estándar, pero que le cambiaste varios parámetros para que ya los tome
por defecto.
¿Cuáles fueron lo que cambiaste?
Y lo último, luego de que yo hago algún cambio en el configure, como yo
le digo a las fuentes que se ajusten a estos cambios. ¿Esto tiene que
ver con GNU/autotools?

Saludos

"TND (Ing. Marcos Ortíz Valmaseda)" escribió:

> Álvaro, estaba leyendo tu correo sobre el script que utilizas para
> el mantenimiento de varias versiones de PostgreSQL en tu PC, y me
> quedó una duda. Me dices acá que runpg config: ejecuta el
> ./configure de manera estándar, pero que le cambiaste varios
> parámetros para que ya los tome por defecto.
> ¿Cuáles fueron lo que cambiaste?

Hmm, no me acuerdo; el script runpg tiene una variable al principio que
indica las opciones con que invoca configure. Esto incluye cosas como
--with-pgport, --prefix, etc.

> Y lo último, luego de que yo hago algún cambio en el configure, como
> yo le digo a las fuentes que se ajusten a estos cambios. ¿Esto tiene
> que ver con GNU/autotools?

No debes cambiar configure, porque es un archivo derivado. El original,
que es lo que debes modificar, es configure.in. Una vez que lo hayas
modificado, ejecutas autoconf, el cual generará una copia actualizada de
configure. A continuación debes recompilar Postgres. Nota que las
fuentes no se "ajustan" a los cambios; la gran parte del código fuente
no cambia para nada. Los archivos que sí cambian son generados por
configure al final de su ejecución, como pg_config.h,
src/Makefile.global, y otros.

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Nunca confiaré en un traidor. Ni siquiera si el traidor lo he creado yo"
(Barón Vladimir Harkonnen)

El 30/04/10 16:14, Alvaro Herrera escribió:
> "TND (Ing. Marcos Ortíz Valmaseda)" escribió:
>
>
>> Álvaro, estaba leyendo tu correo sobre el script que utilizas para
>> el mantenimiento de varias versiones de PostgreSQL en tu PC, y me
>> quedó una duda. Me dices acá que runpg config: ejecuta el
>> ./configure de manera estándar, pero que le cambiaste varios
>> parámetros para que ya los tome por defecto.
>> ¿Cuáles fueron lo que cambiaste?
>>
> Hmm, no me acuerdo; el script runpg tiene una variable al principio que
> indica las opciones con que invoca configure. Esto incluye cosas como
> --with-pgport, --prefix, etc.
>
>
>> Y lo último, luego de que yo hago algún cambio en el configure, como
>> yo le digo a las fuentes que se ajusten a estos cambios. ¿Esto tiene
>> que ver con GNU/autotools?
>>
> No debes cambiar configure, porque es un archivo derivado. El original,
> que es lo que debes modificar, es configure.in. Una vez que lo hayas
> modificado, ejecutas autoconf, el cual generará una copia actualizada de
> configure. A continuación debes recompilar Postgres. Nota que las
> fuentes no se "ajustan" a los cambios; la gran parte del código fuente
> no cambia para nada. Los archivos que sí cambian son generados por
> configure al final de su ejecución, como pg_config.h,
> src/Makefile.global, y otros.
>
>

Gracias, hermano.
Tengo que leerme entonces un poco más el trabajo con Autotools para ver
si lo puedo ajustar entonces a las necesidades que queremos acá

Saludos

"TND (Ing. Marcos Ortíz Valmaseda)" escribió:

> Tengo que leerme entonces un poco más el trabajo con Autotools para
> ver si lo puedo ajustar entonces a las necesidades que queremos acá

Modificar configure.in es bien complicado :-( ¿Qué necesidades tienen
allá?

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"La victoria es para quien se atreve a estar solo"