Thursday, May 8, 2008

[HACKERS] Relatively simple question about getting attributes from the where clause

Hi guys, I am new to postgres hacking, and I have the following question.
Say that someone executes a query:

SELECT * FROM user u, logins l WHERE u.id = l.id
(assume I have tables user, and logins, with id fields).

After this query has been parsed and created into a plan tree, how can I
get the char* form of the attribute name on which my WHERE clause searches
on (in this case, user.id and logins.id)?

Thanks a bunch guys
-TJ


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Auto-updated fields

On Thu, 2008-05-08 at 00:41 -0400, Tom Lane wrote:
> Tino Wildenhain <tino@wildenhain.de> writes:
> > I may be wrong but my feeling is, not to much weirdness in the core
> > please :)
>
> +1 ... we have wasted more than enough man-hours trying to get the magic
> "serial" type to play nicely. If I had it to do over, we'd never have
> put that in at all. The underlying mechanisms are perfectly good ---
> it's the idea that the user shouldn't need to know what they're doing
> that causes problems.

This kind of hiding will mostly hit the Leaky Abstraction "pattern"

http://www.joelonsoftware.com/articles/LeakyAbstractions.html


http://en.wikipedia.org/wiki/Leaky_abstraction

----------------
Hannu

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] Replicación de Tabla de Oracle a PostgreSQL

Hola listeros...

Les escribo para saber qué recomendaciones me pueden dar para replicar datos de una tabla en Oracle a otra en Postgres.

Específicamente lo que necesito es definir un mecanismo que replique datos de una tabla de Oracle a Postgres una vez a la semana.

Sé que existe el DBI-Link, que si no me equivoco permite realizar consultas en una BD en Oracle desde PostgreSQL, pero como verán, necesitaría que las consultas se ejecuten automáticamente cada cierto período de tiempo.

Pensé que de repente se puede hacer un CRON que ejecute un Script que llame a la consola de psql o algo así y ejecute las consultas una vez a la semana, pero no sé si es posible y hasta ahora no tengo el acceso a la BD de Oracle ya que debería llegar con la solución propuesta para poder implementarla.

Gracias de antemano por sus respuestas.
--
Luis D. García M.

Telf: (+58) 2418662663
Cel.: (+58) 4143482018

Re: [GENERAL] now i'm really confused. insert/update does autocast, where sometimes.

Am Dienstag, 6. Mai 2008 schrieb Daniel Schuchardt:
> so it depends on ? if i need an explicit cast?

A type cast can be attempted in three different contexts (see also CREATE CAST
reference page):

- implicitly
- storage assignment
- explicitly

The explicit case is if you call CAST() or ::. This is always allowed if an
appropriate cast routine is defined.

The implicit case is if an operator or function requires type A and the
expression is of type B. This cast is only performed if the cast routine is
defined and allowed for the implicit context. The change in 8.3 was
to "downgrade" many casting functions from implicit to assignment or
explicit.

The storage assignment case is if the value has type A and is about to be
stored into a column of type B. This is allowed if the cast routine is
allowed for the assignment context. This is, perhaps surprisingly, a
separate level between implicit and explicit casts. So in reference to your
subject line, yes, INSERT and UPDATE do have different casting behavior than
SELECT. (This is not really accurate, because the WHERE clause of an UPDATE
would follow the same rules as a WHERE clause in SELECT. The assignment
context only applies for values that are really going to be stored.)

This is all in line with the SQL standard.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Auto-updated fields

On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> David Fetter wrote:
> > Folks,
> >
> > A co-worker pointed out to me that MySQL has a feature that, properly
> > implemented and maybe extended, could be handy, namely what MySQL
> > calls a "timestamp" field, so here's a proposal:
> >
> > 1. Create a generic (possibly overloaded) trigger function, bundled
> > with PostgreSQL, which sets a field to some value. For example, a
> > timestamptz version might set the field to now().
> >
> > 2. Have some kind of pre-processing of CREATE and ALTER statements on
> > tables which would attach the above function to the field at hand,
> > something like:
> >
> > CREATE TABLE foo(
> > last_updated TIMESTAMPTZ_UPDATED(),
> > ...
> > );
> >
> > which would turn last_updated into a TIMESTAMPTZ with the expected
> > behavior on UPDATEs.
> >
> > What do folks think of this idea?
>
> Having the pre defined triggers at hand could be useful, especially
> for people not writing triggers so often to get used to it but I'm
> really not happy with the idea of magic preprocessing.
>
> I guess this is commonly used with timestamp fields so why not
> include a receipe to the docs under examples for timestamp which
> shows how to create and use a trigger?
>

I have a generic version of this in pagila.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] Updatable views

--On Donnerstag, Mai 08, 2008 14:42:50 +0100 Simon Riggs
<simon@2ndquadrant.com> wrote:

> That makes sense. I can't see how we would make LOCAL CHECK CONSTRAINTs
> work with rules anyhow.

One of the idea's that came up through the discussion was to make the
rewriter responsible for collecting check constraints such as the local
check condition. They would be pushed down to the executor then where the
correct constraints would be applied. However, i'm currently not in the
position to say if this is doable right now.

The original updatable views patch tracked the state of required and
applied rule conditions during rewrite. This way it applied only the rule
conditions of the specified view in cascading updates.

--
Thanks

Bernd

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgsql-es-ayuda] Funciones Sencillas: Problema con type casts

On Thu, May 8, 2008 at 4:55 PM, Juan Manuel Fernandez
<jmfernandez@unlu.edu.ar> wrote:
> Buenos días lista, estoy empezando con funciones, store procedures,
> etc con fin de optimizar la aplicacion y hacerla mas atómica, el tema
> es que estoy trabado con el siguiente problema:
>
> CREATE FUNCTION AGREGAR_DEPTO(codigo_depto INT, nombre_depto TEXT)
> RETURNS VOID AS
> $$
> BEGIN
> INSERT INTO T_DEPTOS_ACADEMICOS VALUES (codigo_depto, nombre_depto);
> END;
> $$
> language 'plpgsql';
>
> La crea sin problemas...
>
> juan=# select agregar_depto(5, 'JuanManue');
> ERROR: function agregar_depto(integer, unknown) does not exist
> LINE 1: select agregar_depto(5, 'JuanManue');
> ^
> HINT: No function matches the given name and argument types. You might need to
> add explicit type casts.
>
Que versión de PostgreSql estas utilizando?
Yo tengo la 8.3.1 trate de replicar tu error, cree tu tabla y
tambien tu función, repeti tu select y no me causo ningun problema.
Podrias poner la definición de la tabla?
> Es un problema de casteo pero no entiendo a que se debe, estuve
> buscando ejemplos pero no pude resolver esto que de seguro será una
> pavada.
>
> Ya probé con CHAR, VARCHAR, TEXT...
>
> Otra pregunta, lo hice en base a ejemplos pero... RETURNS VOID, indica
> que es un procedimiento o que?
Indica que tu función no esta retornando algo.
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

--
:: Jc3 ::
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

[COMMITTERS] libpqtypes - libpqtypes: updated groff2html (added #include support),

Log Message:
-----------
updated groff2html (added #include support), fixed tabs in libpqtypes.h

Modified Files:
--------------
libpqtypes:
groff2html (r1.6 -> r1.7)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/groff2html.diff?r1=1.6&r2=1.7)
libpqtypes/src:
libpqtypes.h (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/src/libpqtypes.h.diff?r1=1.2&r2=1.3)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [pgsql-es-ayuda] Esquema temporal en uso

Julio Cesar Rodriguez Dominguez escribió:
> On Thu, May 8, 2008 at 10:25 AM, Oswaldo Hernández <listas@soft-com.es> wrote:
>> Hola,
>>
>> Tengo una funcion que necesita comprobar si se han creado previamente unas
>> tablas temporales para regenerarlas si es necesario.
>>
>> Para verificar si existe una tabla suelo hacer una lectura en pg_class
>> buscando tabla y esquema, pero en el caso de las tablas temporales no se que
>> esquema esta utilizando la sesion actual.
>>
>> ¿Como puedo averiguar cual es el esquema temporal que esta utilizando la
>> sesion?
> A ver si entendi bien, quieres saber en que tabla del sistema se esta
> guardando el nombre de tu tabla temporal, para poder consultar si
> existe o no, y de ahí decidir si debes crearla?
> Si fuera eso, puedes consultar pg_statio_user_tables.

una funcion crea una tabla temporal:
create temp table tabla_temporal (.......)

Al ser una tabla temporal postgres la crea en un schema llamado pg_temp_X, donde X es un numero que
le asigna postgres.

En otro momento, y siempre dentro de la misma sesion, otra funcion necesita verificar la existencia
de esta tabla. El nombre de la tabla lo sabe, pero lo que no sabe es el nombre que le ha asignado
postgres al esquema temporal.

pg_statio_user_tables no me vale porque si esta accion se realiza desde mas de una sesion me muestra
todas las tablas temporales activas de *todas* las sesiones, y no puedo averiguar cual es la que
corresponde a la sesion actual.

Puedo intentar crear de nuevo la tabla y capturar el error si ya existiera, pero me gustaria poder
hacerlo consultando los catálogos.

Espero haberme explicado un poco mejor.

Saludos,

--
*****************************************
Oswaldo Hernández
oswaldo (@) soft-com (.) es
*****************************************
PD:
Antes de imprimir este mensaje, asegúrese de que es necesario.
El medio ambiente está en nuestra mano.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [GENERAL] auto-vacuum questions

On Thu, 8 May 2008 10:54:32 -0400
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> John Gateley wrote:
> > Hi, I have a couple of questions on the auto-vacuum daemon:
> >
> > 1) How do I know it is running.
>
> Open a session and run "SHOW autovacuum". If it says "on", it's
> vacuuming. Keep an eye on the autovacuum_naptime setting too.

Thank you,

j

--
John Gateley <gateley@jriver.com>

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-www] [pgsql-advocacy] National community sites @ postgresql.org?

On Thu, May 8, 2008 at 3:52 PM, Marc G. Fournier <scrappy@hub.org> wrote:
> > So how do you decide who gets to run the PUG site?
>
> We aren't talking about PUGs here, or at least that wasn't my impression ... we
> were talking about community sites, under which several pugs could exist ...

There is a very blurred line between PUG and community 'group' in my
experience. Given there are two 'groups' in Italy, how would we decide
which was in control of the it.postgresql.org community site?

--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[pgsql-es-ayuda] Funciones Sencillas: Problema con type casts

Buenos días lista, estoy empezando con funciones, store procedures,
etc con fin de optimizar la aplicacion y hacerla mas atómica, el tema
es que estoy trabado con el siguiente problema:

CREATE FUNCTION AGREGAR_DEPTO(codigo_depto INT, nombre_depto TEXT)
RETURNS VOID AS
$$
BEGIN
INSERT INTO T_DEPTOS_ACADEMICOS VALUES (codigo_depto, nombre_depto);
END;
$$
language 'plpgsql';

La crea sin problemas...

juan=# select agregar_depto(5, 'JuanManue');
ERROR: function agregar_depto(integer, unknown) does not exist
LINE 1: select agregar_depto(5, 'JuanManue');
^
HINT: No function matches the given name and argument types. You might need to
add explicit type casts.

Es un problema de casteo pero no entiendo a que se debe, estuve
buscando ejemplos pero no pude resolver esto que de seguro será una
pavada.

Ya probé con CHAR, VARCHAR, TEXT...

Otra pregunta, lo hice en base a ejemplos pero... RETURNS VOID, indica
que es un procedimiento o que?
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [GENERAL] auto-vacuum questions

John Gateley wrote:
> Hi, I have a couple of questions on the auto-vacuum daemon:
>
> 1) How do I know it is running. I suspect it has not been, and
> I carefully checked the documentation and found a variable that
> wasn't set (stats_row_level defaults to off in 8.1, should be
> "on"). So I changed that and restarted, but how do I *know* that
> is or isn't vacuuming?

Open a session and run "SHOW autovacuum". If it says "on", it's
vacuuming. Keep an eye on the autovacuum_naptime setting too.

> 2) Every night I do
>
> pg_dump -c mydb | psql -d mydbtest
>
> so I create a copy of the database in a different name for testing
> purposes. But the new database, mydbtest, always has slow queries.
> I run an analyze and they speed up. There are NO transactions in
> mydbtest until I come in and start testing, does this mean
> auto-vacuum won't analyze it? Is this maybe related to question
> 1 where I think auto-vacuum actually wasn't running?

It might mean it hasn't been analyzed _yet_. If there are too many
databases, it may take a while.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [SQL] Index to enforce non-overlapping ranges?

James Robinson <jlrobins@socialserve.com> writes:
> Given a table with a pair of any sort of line-segment-esqe range
> delimiter columns, is it possible to build a unique index to enforce
> non-overlapping ranges?

Nope, sorry. Unique indexes enforce non-equality, but there's no way
to pretend that "overlaps" is an equality condition (hint: it's not
transitive).

I don't say that it'd be impossible to construct an index type that
could do this, but you won't get there with the pieces we have.

regards, tom lane

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [pgsql-www] [pgsql-advocacy] National community sites @ postgresql.org?

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

- --On Thursday, May 08, 2008 13:07:42 +0100 Dave Page <dpage@pgadmin.org> wrote:

> On Thu, May 8, 2008 at 1:04 PM, Marc G. Fournier <scrappy@hub.org> wrote:
>
>> But, to your point about 'more then one group', I though we were talking
>> about national communities (ie. umbrellas), not individual user groups?
>>
>> For instance, with Italy, there would obviously be a link to the seperate
>> user groups expected off of the site ...
>
> So how do you decide who gets to run the PUG site?

We aren't talking about PUGs here, or at least that wasn't my impression ... we
were talking about community sites, under which several pugs could exist ...

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkgjE5MACgkQ4QvfyHIvDvO8OwCdEkeKIKaEXH+msi4/bXSoWTMz
yqUAnArNW40JRMEuthWuSpyZnqGcRhxy
=VA6j
-----END PGP SIGNATURE-----


--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] curso de administración de postgres

Hola Lista!
Para ese curso de darse, en Venezuela habemos muchos interesados.
Gracias y que se pueda consolidar.
Rolando

El día 8 de mayo de 2008 6:35, Raul Andres Duque <ra_duque@yahoo.com.mx> escribió:
Si es en línea también me apunto ya que estoy en Bogotá, Colombia.
 
Atentamente,
 
RAUL DUQUE
Bogotá, Colombia

Sent: Wednesday, May 07, 2008 6:26 PM
Subject: Re: [pgsql-es-ayuda] curso de administración de postgres

si es en linea yo tambien me apunto

El día 7 de mayo de 2008 9:35, Guillermo Munoz <munozgb@gmail.com> escribió:
El 7/05/08, Martin Marques <martin@marquesminen.com.ar> escribió:
> mariana chagra escribió:
> >
> > Tambien me apunto al curso, desde Argentina.
> >
>
> Para los que están en Argentina, la Universidad Nacional del Litoral va a
> dar un curso de administración de PostgreSQL en el segundo semestre de este
> año en la modalidad a distancia (http://www.unlvirtual.edu.ar).
>
> Cuando comience la difusión, les envío un mail por la lista.
> --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
>

1+, lo seguire de cerca

--
Saludos
Guillermo Muñoz
--
TIP 7: no olvides aumentar la configuración del "free space map"



--

-----------------------
MVJR



--
=================================
WILMER ROLANDO
MENDOZA BRICEÑO. T.S.U INFORMATICA
Proyecto LIBRUM
wilmerm@gmail.com / librumweb@gmail.com
Visita: http://www.meridatuya.com
Visita: http://www.librumweb.com
=================================

Re: [GENERAL] regexp_replace in two times?

Luca Ferrari <fluca1978@infinito.it> writes:
> I used the regexp_replace function to make a substitution over a table, but I
> got a strange behaviour (please consider I'm not an expert of regex). The
> idea is to remove the final part of a code, that could be TIF, ISTTIF, tif,
> isttif, and at the same time consider only the records depending on the join
> with another table. Now, the strange thing is that the first query updated
> the most of records, but then 4 records are still there, and in fact
> executing again the same update provides me another substitution. What could
> be the reason?

Maybe the original strings had more than one instance of 'TIF'?

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [COMMITTERS] pgsql: Make the new pg_stat_get_activity use OUT parameters, so you

mha@postgresql.org (Magnus Hagander) writes:
> Make the new pg_stat_get_activity use OUT parameters, so you don't have to
> specify the column names and types. Also simplifies the view.

The buildfarm says you forgot to update rules.out :-(

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[GENERAL] auto-vacuum questions

Hi, I have a couple of questions on the auto-vacuum daemon:

1) How do I know it is running. I suspect it has not been, and
I carefully checked the documentation and found a variable that
wasn't set (stats_row_level defaults to off in 8.1, should be
"on"). So I changed that and restarted, but how do I *know* that
is or isn't vacuuming?

2) Every night I do

pg_dump -c mydb | psql -d mydbtest

so I create a copy of the database in a different name for testing
purposes. But the new database, mydbtest, always has slow queries.
I run an analyze and they speed up. There are NO transactions in
mydbtest until I come in and start testing, does this mean
auto-vacuum won't analyze it? Is this maybe related to question
1 where I think auto-vacuum actually wasn't running?

Thanks,

j

--
John Gateley <gateley@jriver.com>

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-es-ayuda] Curso

juan jaimes escribió:
> perdon pero yo ayudaria a realizar los tutoriales, y estoy dispuesto aunque
> esto siga siendo una calentura ya que la pagina que se propuso el año pasado
> no se ha realizado (almenos eso pienso) ya que sigo la lista y espero que no
> se me haya pasado nada

Eres bienvenido a realizar todos los tutoriales que seas capaz.

http://wiki.postgresql.org/wiki/Espa%C3%B1ol

Nos falta contenido en español.

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [BUGS] BUG #4053: libpq documentation should express clearly, that integers are passed in network octet order

Bruce Momjian wrote:
> This brings up a good question. Exactly how do users know what format
> _binary_ is? int4 is network byte order, but what about int8, float4,
> inet?

This is exactly what libpqtypes solves. Not only do we handle
formatting of binary formats, we provide a level of protection from
internal format changes for libpq users. See the example here:
http://libpqtypes.esilo.com/.

So, documentation of binary formats
(including network byte ordering) are not required.

merlin

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-es-ayuda] Cluster

Santiago del Castillo escribió:
> A ver permitanme meterme en este hilo, ya que este tema me apaciona, a mi
> tambien me gustaria saber como hacer un cluster, en mi caso seria para mover
> grandes grantidades de datos y poder recuperarlos en un tiempo
> extremadamente corto, saludos

Para eso no necesitas un cluster, solo un servidor suficientemente
potente, no?

A menos que quieras hacer OLAP, en cuyo caso quizas te interese
GreenPlum o Bizgres.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [HACKERS] Bogosity in contrib/xml2/Makefile

Tom, did we come to any conclusion on this?

---------------------------------------------------------------------------

Tom Lane wrote:
> Whilst fooling with bug #4058 I noticed that xml2's .c files were being
> compiled without -g or any of the various warning flags we normally use.
> I saw this:
>
> gcc -I/usr/include/libxml2 -fpic -I. -I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o xpath.o xpath.c
>
> when I expected something like this:
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -fpic -I. -I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o xpath.o xpath.c
>
> The reason is apparently this line in its Makefile:
>
> override CFLAGS += $(shell xml2-config --cflags)
>
> It seems the "override" locks down the value so that the subsequent
> assignment in Makefile.global does nothing. I didn't try the PGXS
> case but I imagine it doesn't do the right thing either.
>
> Now, in HEAD and 8.3 I think we could just remove this line, because
> configure knows how to pull the needed -I and -L flags out of
> xml2-config's output and stick them into appropriate flag variables
> (neither of which is CFLAGS btw...). I am not sure what to do in older
> branches though --- there doesn't seem to be any real nice solution.
>
> Even though xml2 is deprecated and may go away for 8.4, I think this is
> important to fix in the back branches. Failing to use the -f flags for
> instance could be resulting in outright wrong code, and we'd be unlikely
> to notice since there's no regression test at all for this module.
>
> Thoughts?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [PATCHES] Updatable views

On Thu, 2008-05-08 at 14:56 +0200, Peter Eisentraut wrote:
> Am Donnerstag, 8. Mai 2008 schrieb Simon Riggs:
> > CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ...
> >
> > which seems straightforward, no?
>
> Double evaluation is the key word. The conclusion was more or less that you
> can't implement check constraints using the rules system. You need to check
> them in the executor.

That makes sense. I can't see how we would make LOCAL CHECK CONSTRAINTs
work with rules anyhow.

So that means WITH CHECK CONSTRAINT is going to end up executed in a
similar place to constraint evaluation on underlying tables.

That leaves me in a difficult position with MERGE though. MERGE does
something similar with conditional-WHEN clause evaluation, plus
transformation of the sub-statements is only sensible when we have
updatable views. :-(

--
Simon Riggs
2ndQuadrant

http://www.2ndQuadrant.com


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS] Internal design of MERGE, with Rules

On Wed, 2008-04-30 at 16:58 +0100, Simon Riggs wrote:
> The main query will then look like this
>
> select target.ctid
> ,case when-not-matched (as above)
> ,case when-matched (as above)
> ,(all other columns required for side queries)
> from <source-query> left outer join <target> on <join-condition>
> where (<when-matched-condition-0>
> or <when-matched-condition-1>
> ...
> or <when-matched-condition-N>)
> or (<when-not-matched-condition-0>
> or <when-not-matched-condition-1>
> ...
> or <when-not-matched-condition-N>)
>
> The WHERE clause is likely required in case we get queries like this
>
> MERGE target t
> USING (select * from source) s
> ON (s.pkey = t.pkey)
> WHEN MATCHED AND s.pkey = $1
> UPDATE SET col = $2;
>
> which would be perfectly valid, even if we might hope that they had
> coded like this
>
> MERGE target
> USING (select * from source WHERE index-column = $1)
> ON (join-condition)
> WHEN MATCHED
> UPDATE SET col = $2;

Peter has just jogged my memory about double evaluation of volatile
functions, so the above transformation isn't correct.

We would not be able to fully optimise a MERGE statement like this

MERGE target t
USING (select * from source) s
ON (s.pkey = t.pkey)
WHEN MATCHED AND s.key = $1
UPDATE SET col = $2;

since we won't be able to pass the clause "s.pkey = $1" down into the s
query so it would use an index. The following statement will be faster,
but will in all cases give an identical result:

MERGE target t
USING (select * from source WHERE key = $1) s
ON (s.pkey = t.pkey)
WHEN MATCHED
UPDATE SET col = $2;

I don't think its too important, since the latter is the way people
would have used MERGE in SQL:2003 anyway.

--
Simon Riggs
2ndQuadrant

http://www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[SQL] Index to enforce non-overlapping ranges?

Academic question here:

Given a table with a pair of any sort of line-segment-esqe range
delimiter columns, is it possible to build a unique index to enforce
non-overlapping ranges? Such as:

create table test
(
id int not null primary key,
low_value int not null,
high_value int not null
);

Can one build an index to enforce a rule such that no (low_value,
high_value) range is identical or overlaps with another (low_value,
high_value) range described by the table? And, more interestingly,
what about for ranges of dates / timestamps as opposed to simple
integers?

I can see how a trigger on insert or update could enforce such a
constraint [ probe the table for an existing overlapping row, and
raise exception one exists ], but can such an activity be performed
with fewer lines using some sort of r-tree index?

----
James Robinson
Socialserve.com


--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [PATCHES] Updatable views

--On Donnerstag, Mai 08, 2008 13:28:14 +0100 Simon Riggs
<simon@2ndquadrant.com> wrote:

> On Thu, 2008-05-08 at 13:48 +0200, Bernd Helmle wrote:
>> --On Mittwoch, Mai 07, 2008 20:38:59 +0100 Simon Riggs
>> <simon@2ndquadrant.com> wrote:
>>
>> >> Where are we on this feature?
>> >
>> > Any update, Bernd?
>>
>> I've merged the patch into current -HEAD and updated some parts. My
>> current *working* state can be reviewed at
>>
>> <http://git.postgresql.org/?p=~psoo/postgresql.git;a=shortlog;h=updatabl
>> e_views>
>>
>> I'm still not sure how to implement a reliable CHECK OPTION, but short
>> on time i haven't done a very deep investigation yet. Next idea was to
>> look at the updatable cursor stuff, maybe something there can be reused.
>
> Your earlier patch seemed to add two rules if the view had a with check
> option? One with a pass through and another one with a do-nothing and a
> where clause.
>
> As I understand it
>
> CREATE VIEW x AS SELECT * FROM foo WHERE where-clause WITH CHECK OPTION
>
> should generate an INSERT rule like this
>
> CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ...
>

This was indeed the implementation i've proposed. We have rejected this
idea then because it doesn't work with volatile functions reliable due to
double evaluation:

<http://archives.postgresql.org/pgsql-patches/2006-08/msg00483.php>

Tom's example even demonstrates a serious constraint in rule based updates,
since you get side effects in such conditions you won't expect, even
without a CHECK OPTION.

> which seems straightforward, no?
>
> The SQLStandard default is CASCADED and it seems easier not to worry too
> much about the LOCAL option until we have the basics working. I'm not
> even sure that we *want* the LOCAL option anyway having read what it
> means, plus it isn't supported by many other DBMS.
>
> Do you store anything in the catalog to mark the view as updatable or
> not? I couldn't see that but it seemed easier than trying to resolve all
> of the updatability characteristics at run-time.

I'm not sure want you mean, but pg_rewrite.ev_kind stores the nature of the
rule. Updatability is determined by the checkTree() function internally.
It's easy to query pg_rewrite to examine wether a view is updatable or not.

>
> I may be able to help some with the patch, if you'd like?
>

You're welcome ;)

> --
> Simon Riggs
> 2ndQuadrant

http://www.2ndQuadrant.com

--
Thanks

Bernd

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgadmin-hackers] Comment about pgAdmin Internals wiki



On Thu, May 8, 2008 at 3:46 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote:
Luis Ochoa a écrit :

Hi everyone, I just want to comment about a wiki in what I've been working on a little. This wiki try to be a quick guide for developers introduction inside pgAdmin Internals (now it's a stub only), if someone wants to contribute the address is:

http://wiki.postgresql.org/wiki/PgAdmin_Internals
( First P is capital letter because wiki restriction)


Wow, that's really great ! It's been some time that I wanted to work on such a thing. To be honest, my main idea was to merge all tips given by Dave on a single page, something like the "Developer Notes" part of this page. I sure want to contribute to your work. I'll try to do something on it this week.

The only issue I see is that only one page for this will make it hard to read. Perhaps we can split this page ?

Anyways, thanks a lot.

Regards.


--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com


Hi, yes the page can be split in an easy way and that it's a very good idea for organization.
The process it's simple: just add a link like this in the wiki where you like it.

[[PageName/PageTitle]] for example:

[[pgAdmin_Internals/New_Page|Title new Page]]

And then go again to wiki and click on the link to add new content.

Regards, Luis.

Re: [PATCHES] Updatable views

Am Donnerstag, 8. Mai 2008 schrieb Simon Riggs:
>  CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ...
>
> which seems straightforward, no?

Double evaluation is the key word. The conclusion was more or less that you
can't implement check constraints using the rules system. You need to check
them in the executor.

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgsql-www] [pgsql-advocacy] National community sites @ postgresql.org?

On Thu, May 8, 2008 at 1:07 AM, Dave Page <dpage@pgadmin.org> wrote:

>> Selena, we can easily setup a 'ru.postgresql.org' subdomain pointing to the
>> pugs.postgresql.org VPS (ie. use it for both) ... no reason not to make the
>> resource available to those that need it, without limiting those that don't ...
>
> Not without playing favourites in areas where there may be more than
> one group - eg. Italy.
>
> Besides, we agreed long ago that <country code>.postgresql.org
> hostnames were strictly reserved for mirror use.

Ah. Sorry about that. Didn't know that was the case.

Perhaps they could be subdomains of pugs.postgresql.org? Is that too obscure?

-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[GENERAL] regexp_replace in two times?

Hi all,
I used the regexp_replace function to make a substitution over a table, but I
got a strange behaviour (please consider I'm not an expert of regex). The
idea is to remove the final part of a code, that could be TIF, ISTTIF, tif,
isttif, and at the same time consider only the records depending on the join
with another table. Now, the strange thing is that the first query updated
the most of records, but then 4 records are still there, and in fact
executing again the same update provides me another substitution. What could
be the reason?

db=> begin;
BEGIN
raydb=> update elementi_dettagliset codice = regexp_replace(
upper(codice), '(IST)*TIF$', '')
where id_elemento in (
select ed.id_elemento
from elementi_dettagli ed, elementi e
where ed.id_elemento = e.id_elemento
and e.categoria = 'bozzetti'
and ed.codice ~* '(IST)*TIF$'
);
UPDATE 4679

db=> select ed.id_elemento,ed.codice from elementi_dettagli ed, elementi e
where ed.codice like '%TIF' and ed.id_elemento = e.id_elemento and
e.categoria='bozzetti';
id_elemento | codice
-------------+--------------
68904 | 0M0809532TIF
67732 | Y07236TIF
67608 | 0D0731744TIF
65687 | 0M0708711TIF
(4 rows)

db=> update elementi_dettagliset codice = regexp_replace(
upper(codice), '(IST)*TIF$', '')
where id_elemento in (
select ed.id_elemento
from elementi_dettagli ed, elementi e
where ed.id_elemento = e.id_elemento
and e.categoria = 'bozzetti'
and ed.codice ~* '(IST)*TIF$'
);
UPDATE 4

db=> select version();
version
----------------------------------------------------------------------------------------------------------------------
PostgreSQL 8.2.7 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.3
20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
(1 row)


Thanks,
Luca

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [PATCHES] Updatable views

On Thu, 2008-05-08 at 13:48 +0200, Bernd Helmle wrote:
> --On Mittwoch, Mai 07, 2008 20:38:59 +0100 Simon Riggs
> <simon@2ndquadrant.com> wrote:
>
> >> Where are we on this feature?
> >
> > Any update, Bernd?
>
> I've merged the patch into current -HEAD and updated some parts. My current
> *working* state can be reviewed at
>
> <http://git.postgresql.org/?p=~psoo/postgresql.git;a=shortlog;h=updatable_views>
>
> I'm still not sure how to implement a reliable CHECK OPTION, but short on
> time i haven't done a very deep investigation yet. Next idea was to look at
> the updatable cursor stuff, maybe something there can be reused.

Your earlier patch seemed to add two rules if the view had a with check
option? One with a pass through and another one with a do-nothing and a
where clause.

As I understand it

CREATE VIEW x AS SELECT * FROM foo WHERE where-clause WITH CHECK OPTION

should generate an INSERT rule like this

CREATE RULE somename AS ON INSERT TO x WHERE where-clause DO INSERT ...

which seems straightforward, no?

The SQLStandard default is CASCADED and it seems easier not to worry too
much about the LOCAL option until we have the basics working. I'm not
even sure that we *want* the LOCAL option anyway having read what it
means, plus it isn't supported by many other DBMS.

Do you store anything in the catalog to mark the view as updatable or
not? I couldn't see that but it seemed easier than trying to resolve all
of the updatability characteristics at run-time.

I may be able to help some with the patch, if you'd like?

--
Simon Riggs
2ndQuadrant

http://www.2ndQuadrant.com


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [GENERAL] Cannot update table with OID with linked server in SQl Server

Yes the table does have a primary key defined.

-----Original Message-----
From: Adrian Klaver [mailto:aklaver@comcast.net]
Sent: Tuesday, May 06, 2008 7:07 PM
To: Ken Allen; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Cannot update table with OID with linked server
in SQl Server

-------------- Original message ----------------------
From: "Ken Allen" <KenA@BarrettXplore.com>
> I have a linked server on SQL server 2005. I can update or write to a
> table in Postgres that does not have a OID. But the Table I have has
an
> OID and I cannot write or update to that table. Anyone have any
ideas.
>

Does the table with the OID have a primary key defined?


--
Adrian Klaver
aklaver@comcast.net


--
This message has been scanned by MailScanner


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-www] [pgsql-advocacy] National community sites @ postgresql.org?

On Thu, May 8, 2008 at 1:04 PM, Marc G. Fournier <scrappy@hub.org> wrote:

> But, to your point about 'more then one group', I though we were talking about
> national communities (ie. umbrellas), not individual user groups?
>
> For instance, with Italy, there would obviously be a link to the seperate user
> groups expected off of the site ...

So how do you decide who gets to run the PUG site?


--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] [pgsql-advocacy] National community sites @ postgresql.org?

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

- --On Thursday, May 08, 2008 09:07:18 +0100 Dave Page <dpage@pgadmin.org> wrote:

> On Thu, May 8, 2008 at 12:30 AM, Marc G. Fournier <scrappy@hub.org> wrote:
>
>> > I think for those communities who want to operate their own sites (Fr, DE,
>> > Br, IT, etc) we should redirect to them.* For communities who don't want
>> > to operate their own sites (as, I guess, RU doesn't), we should host them
>> > on postgresql.org.
>>
>> Selena, we can easily setup a 'ru.postgresql.org' subdomain pointing to the
>> pugs.postgresql.org VPS (ie. use it for both) ... no reason not to make the
>> resource available to those that need it, without limiting those that don't
>> ...
>
> Not without playing favourites in areas where there may be more than
> one group - eg. Italy.
>
> Besides, we agreed long ago that <country code>.postgresql.org
> hostnames were strictly reserved for mirror use.

Good point ... so we'll need to come up with a similar naming convention to the
pugs themselves ...

But, to your point about 'more then one group', I though we were talking about
national communities (ie. umbrellas), not individual user groups?

For instance, with Italy, there would obviously be a link to the seperate user
groups expected off of the site ...

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkgi7GsACgkQ4QvfyHIvDvMqFACfe+abRd9L3a9YbCqbVrJDfwJs
HcYAoOiGBGsbD+abW2ZWDxVs1IHHrO0C
=nzpk
-----END PGP SIGNATURE-----


--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

Re: [pgsql-es-ayuda] Algún manual de pl/pgsql

En esta direccion hay un buen manual

http://www.dbrunas.com.ar/article.php/724.18768377992

El día 8 de mayo de 2008 4:49, PRiNCiPiTo <el-PRiNCiPiTo@terra.es> escribió:
       Hola a todos,
he conseguido hacer mi primer trigger, con la ayuda de la lista, y ahora estoy intentando documentarme sobre el lenguaje pl/pgsql para lograr que la función haga lo que necesito.
Concretamente lo que quiero hacer es que extraiga de un campo date los dos últimos dígitos del año y luego concatenarlo con otros e insertarlo en otro campo.

Ahora mismo tengo esto:

CREATE OR REPLACE FUNCTION codigo_barras()
 RETURNS "trigger" AS
$BODY$BEGIN
       new.codigobarras := '08'||( new.idformato * 10^9)+( new.idmarca * 10^7)+ new.idproducto::integer;
       return new;
END;
$BODY$
 LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION codigo_barras() OWNER TO postgres;


Entonces lo que quiero hacer es que el 08 lo extraiga del campo fechaproduccion (2008-05-09)
No se si plpgsql soporta legth o comandos como tail de unix o si para poder sacar esos dos caracteres tendré que hacerlo con un puntero o lo que sea..

Si alguien me puede orientar con este tema en concreto o informarme sobre donde buscar un buen manual de plpgsql se lo agradecería mucho.

Un saludo a todos



--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [GENERAL] Custom Base Type in C

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

Hi,

Le 8 mai 08 à 01:06, Toby Chavez a écrit :

> My custom type needs to have one biginteger and one text value...
> pretty straight forward. I guess my first question is if there are
> any examples out there that do something similar. I have looked
> extensively through the contrib directory and can't find anything
> very helpful.

You could have a look at the prefix module, which defines a varlena
prefix_range datatype, which is a C struct containing two char and a
char* elements.

http://pgfoundry.org/projects/prefix

But maybe you just don't need to define the type in C, this I can't say.

- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkgi7BsACgkQlBXRlnbh1bnqcgCfQhuzXrmRIc/k65w4Jb5mCHs6
OBgAn1h6g5eadNPetCBs59nnh5TGs+2Z
=F2OW
-----END PGP SIGNATURE-----

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Import German Decimal Numbers

Hi,

Le 7 mai 08 à 15:57, Tino Wildenhain a écrit :
> There is also http://pgfoundry.org/projects/pgloader/
> and if not already implemented it should be fairly
> easy to implement a data filter within this one.

pgloader indeed support user reformating modules, and comes with a
mysql to pgsql timestamp reformater. Adding a python .py module
containing one function to handle the change should be easy, the
documentation has needed details if you look for "reformat_path" and
"reformat" options.

http://pgloader.projects.postgresql.org/

Plus, pgloader supports setting the DateStyle before running copy,
maybe this will be enough in your case? (didn't read all the thread).

If you need more help than current documentation to setup your
reformating module, please just ask!

Regards,
--
dim
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Is this a bug? (changing sequences in default value)

Pg 8.1.11, I try to change sequences as default value of a table, then
remove old sequence:

# \d table1
Table "table1"
Column | Type | Modifiers
--------+---------+---------------------------------------------------------------
id | integer | not null default nextval('table1_id_seq'::regclass)
nombre | text | not null
Indexes:
"table1_pkey" PRIMARY KEY, btree (id)

# ALTER TABLE table1 alter column id set default nextval('newseq_id_seq');
ALTER TABLE

# \d table1
Table "table1"
Column | Type | Modifiers
--------+---------+---------------------------------------------------------------
id | integer | not null default nextval('newseq_id_seq'::regclass)
nombre | text | not null
Indexes:
"table1_pkey" PRIMARY KEY, btree (id)

# drop SEQUENCE table1_id_seq ;
ERROR: cannot drop sequence table1_id_seq because table
table1 column id requires it
HINT: You may drop table table1 column id instead.

Am I doing something wrong?

Thanks!

Fernando.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [ADMIN] Converting from 7.4.19 To 8.3.1 & want to use autovacuum

Oh I have to look at the other parameters. Once the database is up and it's
not vacuuming like we want how do we make changes to the conf file while the
database is running? Some signal?

Guillaume Lelarge wrote:
> Hi,
>
> Barbara Stephenson a écrit :
> > We are new about autovacuum launcher on 8.3.1 and we are not sure what
> > the parameters should be set to. Is setting them to default ok until we
> > can monitor if it's vacumming too much?
>
> You can do that. But the default are, as always with PostgreSQL, really
> conservative. So you'll probably need to change them because it will not
> vacuum enough.
>
> > Below are the parameters that we think are the only params we need to do
> > a basic vacuum and analyze to our entire database.
> >
> > autovacuum=true
> > track_counts=ture
> > log_autovacuum_min_duration=1000ms
> > autovacuum_max_workers=3(default)
> > autovacuum_naptime=60
> > autovacuum_vacuum_threshold=50(default)
> >
> > Are the above settings all we need to start auto vacuuming?
>
> ISTM you forgot autovacuum_vacuum_scale_factor and the analyze parameters.
>
> Regards.
>
>
> --
> Guillaume.
>

http://www.postgresqlfr.org
>

http://dalibo.com

--
Regards,

Barbara Stephenson
EDI Specialist/Programmer
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville, GA 30507
tel: (678)989-3020 fax: (404)935-6171
barbara@turbocorp.com
www.ohlogistics.com

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [PATCHES] Updatable views

--On Mittwoch, Mai 07, 2008 20:38:59 +0100 Simon Riggs
<simon@2ndquadrant.com> wrote:

>> Where are we on this feature?
>
> Any update, Bernd?

I've merged the patch into current -HEAD and updated some parts. My current
*working* state can be reviewed at

<http://git.postgresql.org/?p=~psoo/postgresql.git;a=shortlog;h=updatable_views>

I'm still not sure how to implement a reliable CHECK OPTION, but short on
time i haven't done a very deep investigation yet. Next idea was to look at
the updatable cursor stuff, maybe something there can be reused.

--
Thanks

Bernd

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [ODBC] Can't create DSN using SSPI authentication WinXP toWinXP

Hiroshi,

Thank you very much.
The new psqlODBC 08.03.0200 release fixes the issue.

Roger

Roger M. Quincy, PG
Hydrologist
Texas Water Development Board
Ground Water Technical Assistance Section
phone: 512-936-0833
email: rquincy@txwin.net
web: http://www.twdb.state.tx.us/GwRD/waterwell/well_info.asp

>>> "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> 4/30/2008 5:16 PM >>>
Hi.

Sorry, It is my misstake.
I will repackage psqlODBC with libpq of version 8.3.
However, I have no spere time now..It is weekend.

Regerds,
Hiroshi Saito

"Roger Quincy"
>So what you are saying is that I will have to wait for future versions of PG and PsqlODBC to be released before I will be able to get SSPI to work?
>
>Thanks,
>Roger
>
>Roger M. Quincy, PG
>Hydrologist
>Texas Water Development Board
>Ground Water Technical Assistance Section
>phone: 512-936-0833
>email: rquincy@txwin.net
>web: http://www.twdb.state.tx.us/GwRD/waterwell/well_info.asp

>
>
>--
>Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-odbc


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: [pgsql-advocacy] Bolder vision of pg certification

On May 8, 2008, at 2:30 AM, Mudy Situmorang wrote:

> Just consider please...


We have many things to consider. We also have many talkers.

What we do not have enough of are the doers.

--
Dan Langille -- http://www.langille.org/
dan@langille.org

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[COMMITTERS] libpqtypes - libpqtypes: removed libpqtypes.h comments since they are

Log Message:
-----------
removed libpqtypes.h comments since they are now in man pages

Modified Files:
--------------
libpqtypes/src:
libpqtypes.h (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/libpqtypes/libpqtypes/src/libpqtypes.h.diff?r1=1.1&r2=1.2)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [pgsql-es-ayuda] Cluster

A ver permitanme meterme en este hilo, ya que este tema me apaciona, a mi tambien me gustaria saber como hacer un cluster, en mi caso seria para mover grandes grantidades de datos y poder recuperarlos en un tiempo extremadamente corto, saludos


Santiago


2008/5/7 Alvaro Herrera <alvherre@commandprompt.com>:
Neil Peter Braggio escribió:
> ¿Por qué no nos hablas de esas _opciones_ y nos describes tus dudas
> para ver si podemos ayudarte en algo?

La otra variable importante es _para que_ quieres el cluster.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
TIP 7: no olvides aumentar la configuración del "free space map"



--
Santiago del Castillo
M: sdelcastillo@asimox.com
http://www.asimox.com
Cel: 15-6127-1540
Tel: 4765-3676

[pgsql-es-ayuda] Re: [pgsql-es-ayuda] curso de administración de postgres

Si es en línea también me apunto ya que estoy en Bogotá, Colombia.
 
Atentamente,
 
RAUL DUQUE
Bogotá, Colombia

Sent: Wednesday, May 07, 2008 6:26 PM
Subject: Re: [pgsql-es-ayuda] curso de administración de postgres

si es en linea yo tambien me apunto

El día 7 de mayo de 2008 9:35, Guillermo Munoz <munozgb@gmail.com> escribió:
El 7/05/08, Martin Marques <martin@marquesminen.com.ar> escribió:
> mariana chagra escribió:
> >
> > Tambien me apunto al curso, desde Argentina.
> >
>
> Para los que están en Argentina, la Universidad Nacional del Litoral va a
> dar un curso de administración de PostgreSQL en el segundo semestre de este
> año en la modalidad a distancia (http://www.unlvirtual.edu.ar).
>
> Cuando comience la difusión, les envío un mail por la lista.
> --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
>

1+, lo seguire de cerca

--
Saludos
Guillermo Muñoz
--
TIP 7: no olvides aumentar la configuración del "free space map"



--

-----------------------
MVJR

Re: [pgsql-es-ayuda] Instalar PG

El día 8 de mayo de 2008 3:22, L. Barzi <developower@hotmail.com> escribió:
>
> Hola amigos soy nuevo en PG y quisiera saber lo sgte:
>
> - Como instalar PG en una pc WinXP ?(para hacer unas pruebas, luego se
> implementara aun servidor)

Es un instalador comun y silvestre tipo Microsoft, que por defecto va
a oir en el puerto 5432.

> - Me podrian dar el enlace exacto para descargar el instalador de PG para
> WinXP?

PostgreSQL 8.3.1: http://www.postgresql.org/ftp/binary/v8.3.1/win32/

Cliente Grafico para manipulacion de los datos, etc.:
http://www.postgresql.org/ftp/pgadmin3/release/v1.8.2/win32/

> - Existe algun modelador de base de datos para PG?

No entiendo expresamente a que te referis, podrias ser mas explicito? Disculpas!


Saludos,

Juan
--
TIP 8: explain analyze es tu amigo

Re: [GENERAL] Problems with memory

Pau Marc Munoz Torres wrote:
> Hi
>
> maybe i should give you some more explanations of my problem.
>
> The reason for which i think that postgresql run out of memory is that: I
> have a relation with 6 fields, 29 indexes and 32000 registers, the registers
> where made up using a pgsql language to save disk space, and they "work"
> (see the table schema under those lines)

You have 29 indexes on a table with 6 columns?
But only 32000 rows?

> Column | Type | Modifiers
> --------+--------------+-----------
> id | integer |
> p1 | character(1) |
> p4 | character(1) |
> p6 | character(1) |
> p7 | character(1) |
> p9 | character(1) |
> Indexes:
> "h2iab" btree (idr(p1, p4, p6, p7, p9, 'H-2*IAb'::character varying))
> "h2iad" btree (idr(p1, p4, p6, p7, p9, 'H-2*IAd'::character varying))
> "h2iak" btree (idr(p1, p4, p6, p7, p9, 'H-2*IAk'::character varying))
> "h2ied" btree (idr(p1, p4, p6, p7, p9, 'H-2*IEd'::character varying))
etc.

OK, so you have 29 different functional indexes which use your columns
and then a fixed parameter. Looks odd to me, but I suppose you might
have good reason.

Oh - and it's not necessarily saving you any disk space - the index
values need to be stored.

> when i do a query as:
>
> select * from precalc where idr(p1, p4, p6, p7, p9, 'HLA-DRB1*0101')<-2; it
> works and return 128030 registers
>
> if i do
>
> select * from precalc where idr(p1, p4, p6, p7, p9, 'HLA-DRB1*0101')>-2;
> 3071970 registers, it don't work
> ERROR: relation "pssms" does not exist
> CONTEXT: SQL statement "select score from PSSMS where AA= $1 and POS=1 and
> MOLEC= $2 "
> PL/pgSQL function "idr" line 11 at SQL statement

Do you have a table/view called pssms in your search-path? Because
that's what the error is about. Might it be a case-sensitive issue - do
you have a table called PSSMS instead?

> if i ask for explanation for both queries works:
>
> mhc2db=> explain select count(*) from precalc where idr(p1, p4, p6, p7, p9,
> 'HLA-DRB1*0101')<-2;
[snip]

> mhc2db=> explain select count(*) from precalc where idr(p1, p4, p6, p7, p9,
> 'HLA-DRB1*0101')>-2;
[snip]

> and the index used are the correct ones
>
> If for that reason that i think that my machine runs out of memory, by the
> way, this is not the biggest table that i have others have more than
> 503000000 registers, so if I try to do a cross select between tables it
> could be worse.

For what reason? I still don't see any out-of-memory errors.

--
Richard Huxton
Archonet Ltd

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] statistics collector process is thrashing my cpu

> >
> > Any ideas why this might be happening, and how I can stop it?
>
> It'd be interesting to know what the stats collector is actually doing.
> Could you, using Process Explorer or a debugger, get a stack trace from
> that process while it's in the trashing state?
>
> //Magnus
>

Certainly, but I'll have to wait 'til it does it again, it doesn't
happen all the time.
What would you like to know from Process Explorer?

Will T

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[ADMIN] [Fwd: performance: view or function?]

Hello,

I have one question - what is the difference between the view and a
function returning a data set? I mean the performance. Which is better
to use? If its the same, I would use functions, because I could use
other languages not just SQL to get the results I want.

Thank you in advance.

--
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050


--
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [pgadmin-support] Editing Views with EditGrid

On Tue, May 6, 2008 at 9:05 PM, Andreas Neumann <a.neumann@carto.net> wrote:
> Hi Dave,
>
> Thank you for letting me know about the situation. Can you estimate how
> much work it would be to implement editable views? Maybe based on the
> experience with the editable tables? Maybe we can find a few interested
> parties paying for the development of this feature?

The problem with editing views is not the editing (the code for the
tables will do the job just fine with a few minor changes in most
cases). The problem comes where you have rules which implement
non-trivial updates - for example; consider a view with a total
column, an item price, and a quantity. If you update the quantity,
there is no straightforward way for pgAdmin to understand that the
total price will be automatically updated. In fact, it won't even know
that the total column cannot be manually edited.

This gets even worse, because the rules may easily affect different
rows from that being edited, or even entirely unrelated data. The only
safe way to manage that that I can see would be to refresh the entire
data set following each edit - and that would be unusably slow.

I'm happy to entertain proposals that might work, but this a
non-trivial problem, caused largely by Postgres' superior flexibility
compared to most other DBMSs. It isn't gonna be easy to fix.


--
Dave Page
EnterpriseDB UK:

http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Re: [HACKERS] Auto-updated fields

Zoltan Boszormenyi írta:
> Martijn van Oosterhout írta:
>> On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
>>
>>> 1. Create a generic (possibly overloaded) trigger function, bundled
>>> with PostgreSQL, which sets a field to some value. For example, a
>>> timestamptz version might set the field to now().
>>>
>>
>> Doesn't the SQL standard GENERATED BY functionality work for this? Or
>> won't that handle updates?
>>
>
> You mean GENERATED ALWAYS AS (expression)?
> Yes, they should be updated on every UPDATE as the expression
> may include other fields in the same row.
>
> A GENERATED column implemented as a stored column would
> work for this but a virtual column would not. A virtual column
> would return different values for "now()" in every SELECT.
>
> However we can argue for use cases of a virtual column and implement
> it similarly as VIEWs, i.e an ON SELECT rule can expand the original
> expression of the column definition.
>
> I suggest using these syntaxes if we decide to implement them:
>
> GENERATED ALWAYS AS (expression) -- SQL standard stored GENERATED column
> GENERATED VIRTUAL AS (expression) -- virtual column, obviously

Or, as found in Oracle 11g:

GENERATED ALWAYS AS (expr) VIRTUAL

>
>> Have a nice day,
>>
>
> Best regards,
> Zoltán Böszörményi
>


--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-es-ayuda] Algún manual de pl/pgsql

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

PRiNCiPiTo escribió:
> Hola a todos,
> he conseguido hacer mi primer trigger, con la ayuda de la lista, y ahora
> estoy intentando documentarme sobre el lenguaje pl/pgsql para lograr que
> la función haga lo que necesito.
> Concretamente lo que quiero hacer es que extraiga de un campo date los
> dos últimos dígitos del año y luego concatenarlo con otros e insertarlo
> en otro campo.
>
> Ahora mismo tengo esto:
>
> CREATE OR REPLACE FUNCTION codigo_barras()
> RETURNS "trigger" AS
> $BODY$BEGIN
> new.codigobarras := '08'||( new.idformato * 10^9)+( new.idmarca *
> 10^7)+ new.idproducto::integer;
> return new;
> END;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE;
> ALTER FUNCTION codigo_barras() OWNER TO postgres;
>
>
> Entonces lo que quiero hacer es que el 08 lo extraiga del campo
> fechaproduccion (2008-05-09)
> No se si plpgsql soporta legth o comandos como tail de unix o si para
> poder sacar esos dos caracteres tendré que hacerlo con un puntero o lo
> que sea..
>
> Si alguien me puede orientar con este tema en concreto o informarme
> sobre donde buscar un buen manual de plpgsql se lo agradecería mucho.
>
> Un saludo a todos

Puedes formatear la salida. Fijate:

# SELECT current_date;
date
- ------------
2008-05-08
(1 fila)

# SELECT to_char(current_date, 'yy');
to_char
- ---------
08
(1 fila)

Substituyes current_date por el campo de la tabla y listo.

Espero que te sirva. :-D


- --


< ¡¡Nos vemos!! >
----------------------------
\
\
.::!!!!!!!:.
.!!!!!:. .:!!!!!!!!!!!!
~~~~!!!!!!. .:!!!!!!!!!UWWW$$$
:$$NWX!!: .:!!!!!!XUWW$$$$$$$$$P
$$$$$##WX!: .<!!!!UW$$$$" $$$$$$$$#
$$$$$ $$$UX :!!UW$$$$$$$$$ 4$$$$$*
^$$$B $$$$\ $$$$$$$$$$$$ d$$R"
"*$bd$$$$ '*$$$$$$$$$$$o+#"
"""" """""""
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIIs5yK7lGsMchFswRAtVbAJ0TyhQrFEVc2EF0XgJtd1/APcryDgCfUiF6
OmqtaGWYWMDyp8Yi7zPKwfg=
=AsZS
-----END PGP SIGNATURE-----
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

[ANNOUNCE] reproducible database crash with simple sql command

hi all,

first i create a table
create table regions (id integer, name varchar);

then i want to set a default value for a column, e.g.
alter table regions alter column name set default 'bavaria';

at this point crashes the database with the message

PANIK: ERROR_STACK_SIZE exceeded

the rest of the message is unfortunately in german
then i have to restart the postgres-service manually
this error is very easy reproducible at my environment

is this a problem of my installation or can anybody reproduce this error
at his environment

thanks and greetings from munich
christian

p.s. os windows xp, sp2
postgres 8.3.1, visual c++, build 1400

---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

pgsql-announce-unsubscribe@postgresql.org