Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Manual de instalación

El día 30 de agosto de 2008 22:41, Gabriel Hermes Colina Zambra
<hermeszambra@yahoo.com> escribió:
>
>
>
> --- El vie 29-ago-08, Sergio Valdes Hurtado <svh.pgsql@gmail.com> escribió:
>
>> De: Sergio Valdes Hurtado <svh.pgsql@gmail.com>
>> Asunto: Re: [pgsql-es-ayuda] Manual de instalación
>> A: "Edwin Quijada" <listas_quijada@hotmail.com>
>> Cc: "mAyErLiNg .M." <mmayerling4@hotmail.com>, pgsql-es-ayuda@postgresql.org
>> Fecha: viernes, 29 agosto, 2008, 11:16 am
>> Edwin, te pidió ayuda en "Español".
>> ¿Podrías traducirle el manual?
>>
>> atte.
>>
>> El día 28 de agosto de 2008 17:12, Edwin Quijada
>> <listas_quijada@hotmail.com> escribió:
>> >
>> > Aca hay uno
>> > Run Installer
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> > Por si acaso
>> > NEXT
>> > NEXT
>> > NEXT
>> > NEXT
>> >
>> > :P)
>> >
>> *-------------------------------------------------------*
>> > *-Edwin Quijada
>> > *-Developer DataBase
>> > *-JQ Microsistemas
>> > *-809-849-8087
>> >
>> > * " Si deseas lograr cosas excepcionales debes de
>> hacer cosas fuera de lo comun"
>> >
>> *-------------------------------------------------------*
>> >
> Edwin, disculpame por lo que te voy a decir.
>
> Pero llenar la lista de este tipo de correos me parece pelotudo
> mejor abstenerce.
>
> No aporta nada, con decirle a nuestro amigo que no se si existe y que pregunte las dudas que tenga a quienes usamos tambien windows, me parece mejor idea.
>
> Y que vos sergio lo festejes me parece aun peor, por que no se lo traducis vos.

Adhiero en todo lo que dice Gabriel.

> Disculpen pero me parece que la persona que pregunta tiene una necesidad seria y no tiene sentido mofarse.

Siempre nos distinguimos de las demás listas en la cordialidad que
teniamos hacia los newbies, y estas bromas no hacen mas que irritar y
alejar a la gente nueva.

> Con gusto quien pregunto puede escribirme para tratar de resolver los
> problemas e inquietudes y por ahi elaborar un manual para esto.

Idem yo.

> Un abrazo a todos y disculpen no me enojo con ustedes si no con la actitud

Lo mismo.

> Atte.
> Gabriel Colina

Saludos,

Juan

> ____________________________________________________________________________________
> Yahoo! MTV Blog & Rock >¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
>
--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] Attaching error cursor position to invalid constant values

Tom Lane wrote:
>I'm fooling around with getting the parser to report an error cursor
>location if input conversion fails for a constant in a SQL command.

>This seems like it'd be a pretty useful thing to have in long queries,
>but in short queries it looks a bit like overkill. And it affects

I wanted to have this many times, actually I considered it a bug that
it didn't report the position.
--
Sincerely,
Stephen R. van den Berg.
Several ways to kill a programmer: kill -15, fair trial; kill -1, death by
hanging; kill -2, suicide; kill -3, euthanasia; kill -9, execution.

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

[HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

 

Reference: Bruce Momjian writes: -> http://archives.postgresql.org/pgsql-committers/2007-09/msg00402.php

Other references: Boyer Moore?? -> http://www.cs.utexas.edu/users/moore/best-ideas/string-searching/fstrpos-example.html

 

 

As a first time hacker of postgresql I’ve decided to attempt something that does not go too deep in to the heart of the software.

 

Before I make an attempt at writing a patch, I’ve decided to start benchmarking outside of Postgres. On reading the link underneath the Boyer Moore item in the in the new TODO list wiki, I learned that someone else had a shot at speeding up strpos around this time last year using KMP algotithm. On looking a little deeper into Boyer Moore’s algorithm it’s quite obvious that there is some overhead involved with preprocessing the search key (needle). My target has been to not have any trade offs with this possibly to be patch.  I didn’t want smaller searches to suffer.

 

I’d like to receive some feedback on the various functions in the attached before I go ahead and work on this any more. I’ve written 8 different versions of the function. Version 8 seems to be the fastest out of them, however I’ve not tested with multi byte chars.

 

Please note that these are just some initial ideas. For example startpos is not yet implemented, but there is very little overhead to that anyway.

 

For comparision sake I mocked up the current postgresql 8.3’s strpos() from varlena.c. I’ve no idea how accuratly this will be to the real version. Probably find out once I write the patch. I replaced strncmp with my own version as I was having problems with my compilers optimizer, it optimized too much and I was unable to benchmark. I felt running without and optimization was unfair as strncmp is. Perhaps if someone else wants to benchmark with –O2 on gcc they should first replace pg_strncmp with strncmp.

 

 

Currently I have a single file which can be compiled itself that contains benchmarks for the functions I’ve tested so far. All of these implement a stripped out version of the Boyer Moore algotithm. I’ve done away with one of the character maps in a bid to reduce the overhead involved creating them.

 

The position calculation will likely need changed for multi byte characters. I’m suspecting I’m not meant to be doing length calculations on pointers. Can someone confirm?

 

To keep this email short I’ve put most of the information required in as comments into the source of the program.

 

I’ve uploaded some benchmark results using the attached program. The benchmarking was done on windows…

Please see http://www.unixbeast.com/~fat/test1.html  there are 10 tests in total, in each I attempt to exploit weaknesses, some with my functions and some with the existing function.

 

My method for version 8 of the function probably looks quite unusual as it does some simple cost based optimisation

 

I look forward to receiving feedback on this.

 

David.

 

 

 

 

 

 

 

[NOVICE] Date Of Entry and Date Of Change

I need to be able to establish the Date of Entry (INSERT) and Date of
Change (UPDATE) of a row to a table. I have added to my table two
columns, named 'doe' and 'doc' respectively. For sake of
discussion, let's call the Table 'instr'. What would be the best
method of added the current timestamp (date and time) to each of
these two new columns. In my mind, the timestamp would need to be
added just before the row was INSERTed or UPDATEd to prevent any
"race" condition.

I have looked at Triggers and Functions in the pgAdmin helps, but it
is confusing at best, how to arrive at a solution. Any help would be
appreciated. Perhaps, a simple example to get me headed in the right
direction.

Regards,

Dale Seaburg

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

[pgadmin-hackers] SVN Commit by guillaume: r7452 - trunk/pgadmin3

Author: guillaume

Date: 2008-08-30 22:39:27 +0100 (Sat, 30 Aug 2008)

New Revision: 7452

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7452&view=rev

Log:
Forgot the changelog.

Modified:
trunk/pgadmin3/CHANGELOG

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

[pgadmin-hackers] SVN Commit by guillaume: r7451 - in trunk/pgadmin3/pgadmin: dlg include/dlg

Author: guillaume

Date: 2008-08-30 22:37:21 +0100 (Sat, 30 Aug 2008)

New Revision: 7451

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7451&view=rev

Log:
SQL text field can be enabled to allow SQL changes on properties dialog.

Modified:
trunk/pgadmin3/pgadmin/dlg/dlgProperty.cpp
trunk/pgadmin3/pgadmin/include/dlg/dlgProperty.h

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

Re: [GENERAL] ERROR: relation . . . does not exist

> You have made clear to me why my attempt for a RFE for COPY FROM CVS
> has found some technical resistance/disagreement, but I still think my
> idea even if not so popular for concrete and cultural reasons makes at
> least sense to some people

It's a perfectly reasonable problem to want to solve; the question is
whether COPY is the right place to solve it. I would think that a tool
that reads the CSV data and produces a proposed schema definition for
the table would be a more generally-useful approach.

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

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Dave Page a écrit :
> On Sat, Aug 30, 2008 at 9:44 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
>> The current values could be the settings ones or the table ones. If we
>> put the current values in the main textboxes, we will have to first
>> check that at least one textbox value is different from the current
>> value. If we find a difference, we could save the table settings.
>>
>> This is a bit hard, but not impossible.
>
> Oh, OK. I guess we'll just leave it as-is for now.
>
>

OK. I'll just commit the "Enabling SQL field" patch.

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

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

[pgsql-es-ayuda] default current_time

Hola, como muchos d ustedes saben soy d República Dominicana, y necesito ver insertar la hora en un camo de una tabla.

Este ejemplito :

create table tabla
(
codigo integer primary key,
hora time default current_time
);

A la hora insertar registros hago esto:

insert into tabla(codigo)
values(1),(2);

Y me despliega estos datos

codigo | hora
--------+--------------
1 | 16:27:36.375
2 | 16:27:36.375
(2 rows)

sin embargo la hora actual de mi computadora es: 16:57:36.375

Estoy utilizando Postgresql 8.3.3 bajo Windows XP

El time zone d mi pais en windows es el d Caracas/La Paz.

Aq se debera esto??

_________________________________________________________________
Get Windows Live and get whatever you need, wherever you are. Start here.
http://www.windowslive.com/default.html?ocid=TXT_TAGLM_WL_Home_082008--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

On Sat, Aug 30, 2008 at 9:44 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:

> The current values could be the settings ones or the table ones. If we
> put the current values in the main textboxes, we will have to first
> check that at least one textbox value is different from the current
> value. If we find a difference, we could save the table settings.
>
> This is a bit hard, but not impossible.

Oh, OK. I guess we'll just leave it as-is for now.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [pgsql-es-ayuda] Problema insertando datos (TIME)

Hola, gracias por tu respuesta, estaba escribiendo ahora mismo este mensaje:


YA está solucionado, era otro problema, comilla simple en la fecha (me he ofuscado con el time, y era problema de no leer bien el mensaje de error).

Siento las molestias que haya podido ocasionar. (Ciempre me pasa lo mismo, varios días dándole vueltas, y cuando pregunto, es cuando encuentro yo solo la solución)

Gracias

El 30 de agosto de 2008 22:48, Alvaro Herrera <alvherre@alvh.no-ip.org> escribió:

Clemente López Giner escribió:

> INSERT INTO comentarios VALUES('20','editor',30/08/2008,CURRENT_TIME,'');
>
> , me da error, (ERROR: la columna «fecha» es de tipo date pero la expresión
> es de tipo integer
> HINT: Necesitará reescribir la expresión o aplicarle una conversión de
> tipo.)

Necesitas poner comillas en torno al valor de fecha:

INSERT INTO comentarios VALUES('20','editor','30/08/2008',CURRENT_TIME,'');

--
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.

RE: [pgsql-es-ayuda] Problema insertando datos (TIME)

Prueba esto:

INSERT INTO comentarios VALUES('20','editor','2008-08-30',CURRENT_TIME,null);

ing. José Fermín Francisco Ferreras San Francisco de Macorís, Rep. Dom.

________________________________
> Date: Sat, 30 Aug 2008 22:42:28 +0200
> From: clemenlg@gmail.com
> To: pgsql-es-ayuda@postgresql.org
> Subject: [pgsql-es-ayuda] Problema insertando datos (TIME)
>
> Hola,
> Lo primero de todo, saludar a los usuarios de la lista, y daros las gracias por todo lo que hacéis, y por echarnos una mano con nuestras dudas...
> Lo segundo, es que tengo un problemilla con una tabla...
>
> CREATE TABLE comentarios (
> id_art INTEGER NOT NULL,
> usuario VARCHAR(10) NOT NULL,
> fecha DATE NOT NULL,
> hora TIME NOT NULL,
> texto VARCHAR(300) NOT NULL,
>
> CONSTRAINT cp_comentarios PRIMARY KEY(id_art, usuario, fecha, hora),
> CONSTRAINT ca_comentarios_usu FOREIGN KEY(usuario)
> REFERENCES usuarios
> ON DELETE RESTRICT
> ON UPDATE CASCADE,
> CONSTRAINT ca_comentarios_art FOREIGN KEY(id_art)
>
> REFERENCES articulos
> ON DELETE RESTRICT
> ON UPDATE CASCADE);
>
> El problema es que no sé como insertar datos, ya que no sé como insertar el dato time.
> Si hago un
>
> SELECT CURRENT_TIME;
>
> , me muestra lo que quiero (22:28:03.469333+02), pero si lo intento insertar
>
>
> INSERT INTO comentarios VALUES('20','editor',30/08/2008,CURRENT_TIME,'');
>
> , me da error, (ERROR: la columna «fecha» es de tipo date pero la expresión es de tipo integer
> HINT: Necesitará reescribir la expresión o aplicarle una conversión de tipo.)
>
> No sé como he de insertar ese tipo de datos...
>
> ¿Alguien sabe como puedo solucionar el problema?
>
> Gracias

_________________________________________________________________
Get Windows Live and get whatever you need, wherever you are. Start here.
http://www.windowslive.com/default.html?ocid=TXT_TAGLM_WL_Home_082008--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [pgsql-es-ayuda] Problema insertando datos (TIME)

Clemente López Giner escribió:

> INSERT INTO comentarios VALUES('20','editor',30/08/2008,CURRENT_TIME,'');
>
> , me da error, (ERROR: la columna «fecha» es de tipo date pero la expresión
> es de tipo integer
> HINT: Necesitará reescribir la expresión o aplicarle una conversión de
> tipo.)

Necesitas poner comillas en torno al valor de fecha:

INSERT INTO comentarios VALUES('20','editor','30/08/2008',CURRENT_TIME,'');

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Dave Page a écrit :
> On Sat, Aug 30, 2008 at 9:28 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>> Dave Page a écrit :
>>> On Sat, Aug 30, 2008 at 5:52 PM, Guillaume Lelarge
>>> <guillaume@lelarge.info> wrote:
>>>
>>>>> Oh, yes - of course. I wonder if we should give the static text boxes
>>>>> a thin border so it's obviously they are there, even when empty? At
>>>>> the moment it just looks odd.
>>>>>
>>>> I tried many things but didn't manage to get a border, thin or fat.
>>>> Perhaps wa can just put an N/A text on each static box? See attached patch.
>>> Maybe use a disabled text box instead?
>>>
>> I thought about it too but wondered how many users will try to find a
>> way to enable them.
>>
>> If you still thinks it's a better idea, I'll work on it asap.
>
> Is there any reason why we don't just stick the current values in the
> main textboxes?
>

The current values could be the settings ones or the table ones. If we
put the current values in the main textboxes, we will have to first
check that at least one textbox value is different from the current
value. If we find a difference, we could save the table settings.

This is a bit hard, but not impossible.

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

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

Re: [GENERAL] ERROR: relation . . . does not exist

> ... are times local or UTC
~
this is a rather semantic, not a syntactic issue that some code could
NOT decide based on the data it reads
~
> Should we assume integer or float?
~
is a dot anywhere in the data you read in for that particular column? ...
~
> Varchar or text?
~
Is the length of the data read in always less than 255 bytes ( or
characters?)? ...
~
You have made clear to me why my attempt for a RFE for COPY FROM CVS
has found some technical resistance/disagreement, but I still think my
idea even if not so popular for concrete and cultural reasons makes at
least sense to some people
~
DBAs ussualy have a mental map of the data they have on each table,
etc; whereas as a data analyst you find yourself constantly reading
in, cleasing and marshaling data from which you have no prior
knowledge
~
lbrtchx

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

[pgsql-es-ayuda] Problema insertando datos (TIME)

Hola,
Lo primero de todo, saludar a los usuarios de la lista, y daros las gracias por todo lo que hacéis, y por echarnos una mano con nuestras dudas...
Lo segundo, es que tengo un problemilla con una tabla...

CREATE TABLE comentarios (
	id_art INTEGER NOT NULL,
	usuario VARCHAR(10) NOT NULL,
	fecha DATE NOT NULL,
	hora TIME NOT NULL,
	texto VARCHAR(300) NOT NULL,
 	CONSTRAINT cp_comentarios PRIMARY KEY(id_art, usuario, fecha, hora),
	CONSTRAINT ca_comentarios_usu FOREIGN KEY(usuario)
		REFERENCES usuarios
			ON DELETE RESTRICT
			ON UPDATE CASCADE,
	CONSTRAINT ca_comentarios_art FOREIGN KEY(id_art)
 		REFERENCES articulos
			ON DELETE RESTRICT
			ON UPDATE CASCADE);

El problema es que no sé como insertar datos, ya que no sé como insertar el dato time.
Si hago un

SELECT CURRENT_TIME;

, me muestra lo que quiero (22:28:03.469333+02), pero si lo intento insertar

 INSERT INTO comentarios VALUES('20','editor',30/08/2008,CURRENT_TIME,'');

, me da error, (ERROR: la columna «fecha» es de tipo date pero la expresión es de tipo integer
HINT: Necesitará reescribir la expresión o aplicarle una conversión de tipo.)

No sé como he de insertar ese tipo de datos...

¿Alguien sabe como puedo solucionar el problema?

Gracias

Re: [pgsql-es-ayuda] traduccion documentacion

Jaime Casanova escribió:

> Hasta donde se eso se estanco...

Ese se murió cuando Mario González encontró trabajo en una distribución
de Linux, y dejó de tener relación con proyectos que involucran
Postgres.

> hace un tiempo hablando con Alvaro me
> menciono que le habian recomendado Pootle
> (http://translate.sourceforge.net/wiki/pootle/index) como una
> alternativa viable. aunque el mismo aun no habia hecho la prueba. Y
> tambien esta aun en mi lista de pendientes (que cada vez se hace mas
> larga ;)

Idem :-(

> Alvaro se iba a poner en contacto con un grupo de Perú que iban a
> iniciar una traducción al español de la documentación... seria
> interesante saber en que quedo eso...

Bueno, acabamos de recibir el anuncio de Moisés, que es dicho grupo :-)

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
Si no sabes adonde vas, es muy probable que acabes en otra parte.
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

On Sat, Aug 30, 2008 at 9:28 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Dave Page a écrit :
>> On Sat, Aug 30, 2008 at 5:52 PM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>>
>>>> Oh, yes - of course. I wonder if we should give the static text boxes
>>>> a thin border so it's obviously they are there, even when empty? At
>>>> the moment it just looks odd.
>>>>
>>> I tried many things but didn't manage to get a border, thin or fat.
>>> Perhaps wa can just put an N/A text on each static box? See attached patch.
>>
>> Maybe use a disabled text box instead?
>>
>
> I thought about it too but wondered how many users will try to find a
> way to enable them.
>
> If you still thinks it's a better idea, I'll work on it asap.

Is there any reason why we don't just stick the current values in the
main textboxes?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Dave Page a écrit :
> On Sat, Aug 30, 2008 at 5:52 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
>>> Oh, yes - of course. I wonder if we should give the static text boxes
>>> a thin border so it's obviously they are there, even when empty? At
>>> the moment it just looks odd.
>>>
>> I tried many things but didn't manage to get a border, thin or fat.
>> Perhaps wa can just put an N/A text on each static box? See attached patch.
>
> Maybe use a disabled text box instead?
>

I thought about it too but wondered how many users will try to find a
way to enable them.

If you still thinks it's a better idea, I'll work on it asap.

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

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

[HACKERS] Attaching error cursor position to invalid constant values

I'm fooling around with getting the parser to report an error cursor
location if input conversion fails for a constant in a SQL command.
For instance:

regression=# select 42 = 'foo';
ERROR: invalid input syntax for integer: "foo"
LINE 1: select 42 = 'foo';
^
regression=# select '2000-jax-01'::date;
ERROR: invalid input syntax for type date: "2000-jax-01"
LINE 1: select '2000-jax-01'::date;
^
regression=#

This seems like it'd be a pretty useful thing to have in long queries,
but in short queries it looks a bit like overkill. And it affects
the expected output of a whole lot of the regression tests.

Does anyone think this might be "too chatty"?

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

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

On Sat, Aug 30, 2008 at 5:52 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:

>> Oh, yes - of course. I wonder if we should give the static text boxes
>> a thin border so it's obviously they are there, even when empty? At
>> the moment it just looks odd.
>>
>
> I tried many things but didn't manage to get a border, thin or fat.
> Perhaps wa can just put an N/A text on each static box? See attached patch.

Maybe use a disabled text box instead?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

On Sat, Aug 30, 2008 at 5:28 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Dave Page a écrit :
>> On Thu, Aug 28, 2008 at 8:56 AM, Guillaume Lelarge
>> [...]
>>> I'll first work on the server status window (remember the first part:
>>> Replace the wxNotebook widget with the wxAuiNotebook so users can close
>>> tabs and rearrange tabs order via drag-and-drop.) When the first part
>>> will be done, I'll have a better understanding of the AUI stuff.
>>
>> OK, cool. It's not a major issue though - I'd like to redesign the
>> table dialogue (time allowing), and the design I have in mind would be
>> landscape rather than portrait anyway.
>>
>
> Great, this is something I'm waiting for :)
>
> To get back to my patch, do you have any issue with it or can I commit?

No, please commit.

BTW, I just noticed the minimum height for dlgServer is a little too small.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Re: [ODBC] Need a developer contact

Hi Hiroshi-san,

On Sun, 2008-08-31 at 00:30 +0900, Hiroshi Saito wrote:

> Sound good to me. However, I don't have much spare time now...
> But but, it may be useful if your help occurs. what do you think?

Ahem, I'm setting up this list to make my life easier ;)

When you will release a new version, all you need is to send another
e-mail to the new list. It should take < 2 minutes.

Cheers,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [pgsql-www] Download links

On Sat, Aug 30, 2008 at 5:50 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On Saturday 30 August 2008 15:59:41 Dave Page wrote:
>> The ordering intentionally puts the easy to use, one size fits all
>> above the platform specific packaging. Experience tells us that the
>> people that have most trouble figuring out what to download tend to be
>> the ones for whom the one-click point and drool packages are the most
>> appropriate. The more experienced users are generally able to find the
>> 'exact-fit' packages for their distro.
>
> What is concerning me is that the one-click installer is essentially a
> proprietary product and it is put into the prominent spot PostgreSQL ->
> Download -> Linux -> first choice.

It's not proprietary - everything in it is open source, and 'as it
comes'. The fact that it is where it is, is the result of numerous
conversations amongst members of the web team, and even -core (bar
Marc) who agreed in Ottawa that it should be added alongside the
platform specific packages.

> At the very least, the whole thing should be moved to a
> community-hosted infrastructure

I originally wanted to host it on postgresql.org, but was talked out
of it by other members of the webteam who disagreed. A large part of
the reason was that most other packages do not come from
postgresql.org, including those from the yum repo for example.

> an open development model,

The only non-open aspect of it is my failure to publish the build
scripts in a timely fashion. I will try to find some time for that
early next week if it's important to you.

> and no company advertisement.
>
> (For related reasons, I think the company names on the download pages should
> be deleted altogether.)

They were added also following discussion, as credit for those people
and companies who give up their time and resources.

> Also, I would personally never recommend anyone using a non-distro packaged
> binary, which is why I am concerned that we are putting this into the
> prominent spot. There are good technical reasons for that recommendation.
> For example, if you install a nonpackaged version of libpq, none of the other
> packages available in your distro that depend on libpq will work. The
> explanation you give above is acknowledged but I don't believe it is
> accurate. The distro packaging should be the default even for the
> non-superguru user.
>

In an ideal Linux world I agree, but there is no way to get a
consistent and simple installation across different distros due the
variety of packaging systems in use and their maintainers unfortunate
habit of picking and choosing what to package, how to package it, and
when to package it. This is what confuses newbies and drives many
people away from choosing PostgreSQL as we have discovered from others
that I cannot name here.

You will note, that the description beside the one-click package makes
a point of stating that the problem you mention exists for precisely
this reason:

---
Note: The one click installers do not integrate with platform-specific
packaging systems. If you need RPM, APT or Portage integration, please
use the packages below.
---

I'm happy to make reasonable adjustments to that wording if you would
care to suggest improvements.

--
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: [GENERAL] ERROR: relation . . . does not exist

On Aug 30, 2008, at 10:33 AM, Albretch Mueller wrote:
> well, yeah! I would totally agree with you, but since I doubt very
> much "COPY FROM CSV" is part of the SQL standard to beging with, why
> not spice it up a little more?

I'd guess that coming up with a general algorithm to guess the type
from a column of CSV text would satisfy no one, since we'd always
miss a particular case that is important to someone (are times local
or UTC? Should we assume integer or float? Varchar or text?), and the
option is a forest of switches that would be extremely complex and
error prone.

This sounds very much like an application-domain problem, best solved
in the application domain.

--
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] DUPS in tables columns ERROR: column ". . . " does not exist

On Sat, Aug 30, 2008 at 01:36:25PM -0400, Albretch Mueller wrote:
> > The system is smart enough to only do the count() once.
> ~
> But not smart enough to make a variable you declare point to that
> internal variable so that things are clearer/ easier ;-)

The SQL standard has pretty clear rules about what variables can be
referenced from where, and this is one of those places (the rationale
is probably in there too).

Have a nice day
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Re: [GENERAL] ERROR: relation . . . does not exist

On Saturday 30 August 2008 9:42:19 am Adrian Klaver wrote:
> On Saturday 30 August 2008 5:23:25 am Albretch Mueller wrote:
> > On Thu, Aug 28, 2008 at 7:50 PM, Adrian Klaver <aklaver@comcast.net>
wrote:
> > > Define easily.
> >
> > ~
> > OK, let me try to outline the approach I would go for:
> > ~
> > I think "COPY FROM CSV" should have three options, namely:
> > ~
> > 1) the way we have used it in which you create the table first
> > ~
> > 2) another way in which defaults are declared, generally as:
> > ~
> > 2.1) aggressive: data type, value and formatting analysis is done; if
> > only 1 or 0 are found declare then a BOOLEAN, if repeated data is
> > found (say state codes) and the stratification nodes cover the rest of
> > the data, stratify the data out to other extra table (they have a name
> > I can't recall now), index it ..., if data is kind of numeric with
> > front slashes and/or hyphen could they possibly be dates? if they are
> > definitelly dates convert them to bigint (and do the formatting in the
> > presentation code (also this a win-win situation with i18n code)) ...
> > ~
> > 2.2) conservative: data type and value, but no formatting analysis is
> > done and the greater encompassing data type is selected, say for 1 or
> > 0 data use bytes [0, 255], for bytes use int, if something could be
> > encoded as char(2), use varchar instead, . . .
> > ~
> > 2.3) dumn: just use the coarsest data type possible; bigint for
> > anything that looks like a number and varchar for the rest
> > ~
> > the "dumn" option should suggest to the DBA the option they are
> > using, quantified consequences for their desicions (larger DBs for no
> > reason, approx. reduction in speed, . .) and how not to be "dumn"
> > ~
> > 3) or you could define "import templates" declaring which specific
> > data types to use for data in a certain way, which could be declared
> > per column using regexps
> > ~
> >
> > > I could go on, but the point is that table data types require some
> > > thought on the part of the DBA.
> >
> > ~
> > Well, it still requires their minds and input, but they will have
> > jobs even if they get some help, don't you think so ;-)
> > ~
> > lbrtchx
>
> This is a combination of more work then necessary and putting the cart
> after the horse. All I can see happening is delaying the point of decision

Lets try this again. The cart before the horse.
Memo to self:
1) Drink sufficient coffee.
2) Answer email.

> to a later time and or dumping the decision process on someone else. There
> is already a "dumb" solution that has been brought many times on this list.
> It involve creating a holding table that has text only fields and copying
> the data into and then moving the data from there to a final table. As far
> as import templates I suggest looking at:
> http://pgloader.projects.postgresql.org/
> It also addresses some of your other suggestions. It does not automatically
> create a table though.
>
>
>
> --
> Adrian Klaver
> aklaver@comcast.net

--
Adrian Klaver
aklaver@comcast.net

--
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] DUPS in tables columns ERROR: column ". . . " does not exist

> The system is smart enough to only do the count() once.
~
But not smart enough to make a variable you declare point to that
internal variable so that things are clearer/ easier ;-)
~
Thanks
lbrtchx

--
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] ERROR: relation . . . does not exist

> spreadsheet programs (generally; I'm sure there are exceptions) don't have the notion of a schema; each cell can hold its own particular type.
~
Oh, now I see what Martin meant!
~
> that's not a traditional part of a database engine.
~
well, yeah! I would totally agree with you, but since I doubt very
much "COPY FROM CSV" is part of the SQL standard to beging with, why
not spice it up a little more?
~
> This is probably one of those classic "twenty lines of Perl" problems.
~
java since 1.5 comes with a full blown, PERL-like regexp engine
~
> I suggest looking at: http://pgloader.projects.postgresql.org/
> [1] A validator (regex) for each data type . . .
~
that sort of things was what i was talking about, but I would go
quite a bit farther
~
Thanks
lbrtchx

--
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] indexes on functions and create or replace function

On Thu, Aug 28, 2008 at 7:45 PM, Matthew Dennis <mdennis@merfer.net> wrote:

Another question though.  Since I could potentially start transaction, drop indexes/checks, replace function, create indexes/checks, commit tranasaction could I deal with the case of the constant folding into the cached plan by flushing the entire cache in the same transaction?  Is cache flushing transactional?  The cases I have for this are infrequent in time and the overhead of reindexing things, rechecking checks/unique indexes already dwarf the performance lost to flushing the cache.

On a related note, if I had a maintenence window where I can shutdown all DB access, make the referenced changes to the functions/indexes/caches/checks and restart PG - in your opinion, are there other likely problems to changing an immutable function under those circumstances, or should that be pretty safe?  In other words, I have a function that has indexes on it that does the wrong thing - what do I do to replace it?

In the thread below, we kind of got side tracked on some other stuff and I never got an answer to the questions above.  Does anyone have any insight/suggestions about the best way to replace a function that is used by an index?

http://groups.google.com/group/pgsql.general/browse_thread/thread/92289ef0c2f5a109/8f96fb24bdd668e8

Re: [GENERAL] DUPS in tables columns ERROR: column ". . . " does not exist

"Albretch Mueller" <lbrtchx@gmail.com> writes:
> thank you Stefan your SQL worked, but still; I am just asking and my
> programming bias will certainly show, but aren't you effectivly
> "calling" count on the table three times if you go:

The system is smart enough to only do the count() once.

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: [GENERAL] DUPS in tables columns ERROR: column ". . . " does not exist

thank you Stefan your SQL worked, but still; I am just asking and my
programming bias will certainly show, but aren't you effectivly
"calling" count on the table three times if you go:
~
SELECT md5, COUNT(md5)
FROM jdk1_6_0_07_txtfls_md5
GROUP BY md5
HAVING COUNT(md5) > 1
ORDER BY COUNT(md5) DESC;
~
Shouldn't
~
SELECT md5, COUNT(md5) AS CNT
FROM jdk1_6_0_07_txtfls_md5
GROUP BY md5
HAVING CNT > 1
ORDER BY CNT DESC;
~
work?
~
jpk=# SELECT md5, COUNT(md5) AS CNT
FROM jdk1_6_0_07_txtfls_md5
GROUP BY md5
HAVING CNT > 1
ORDER BY CNT DESC;
jpk-# jpk-# jpk-# jpk-# ERROR: column "cnt" does not exist
LINE 4: HAVING CNT > 1
~
Thanks
lbrtchx

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

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Index: pgadmin/dlg/dlgTable.cpp
===================================================================
--- pgadmin/dlg/dlgTable.cpp (révision 7450)
+++ pgadmin/dlg/dlgTable.cpp (copie de travail)
@@ -970,6 +970,19 @@
stFactorAnCurr->SetLabel(NumToStr((tableAnlFactor == -1) ? settingAnlFactor : tableAnlFactor));
stVacDelayCurr->SetLabel(NumToStr((tableCostDelay == -1) ? settingCostDelay : tableCostDelay));
stVacLimitCurr->SetLabel(NumToStr((tableCostLimit == -1) ? settingCostLimit : tableCostLimit));
+
+ if (stBaseVacCurr->GetLabel().Length() == 0)
+ stBaseVacCurr->SetLabel(wxT("N/A"));
+ if (stBaseAnCurr->GetLabel().Length() == 0)
+ stBaseAnCurr->SetLabel(wxT("N/A"));
+ if (stFactorVacCurr->GetLabel().Length() == 0)
+ stFactorVacCurr->SetLabel(wxT("N/A"));
+ if (stFactorAnCurr->GetLabel().Length() == 0)
+ stFactorAnCurr->SetLabel(wxT("N/A"));
+ if (stVacDelayCurr->GetLabel().Length() == 0)
+ stVacDelayCurr->SetLabel(wxT("N/A"));
+ if (stVacLimitCurr->GetLabel().Length() == 0)
+ stVacLimitCurr->SetLabel(wxT("N/A"));

if (connection->BackendMinimumVersion(8, 2))
{
Index: pgadmin/ui/dlgTable.xrc
===================================================================
--- pgadmin/ui/dlgTable.xrc (révision 7450)
+++ pgadmin/ui/dlgTable.xrc (copie de travail)
@@ -349,7 +349,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stBaseVacCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -369,7 +369,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stBaseAnCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -389,7 +389,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stFactorVacCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -409,7 +409,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stFactorAnCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -429,7 +429,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stVacDelayCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -449,7 +449,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stVacLimitCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -469,7 +469,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stFreezeMinAgeCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTER_VERTICAL|wxTOP|wxLEFT|wxRIGHT</flag>
<border>4</border>
@@ -489,7 +489,7 @@
</object>
<object class="sizeritem">
<object class="wxStaticText" name="stFreezeMaxAgeCurr">
- <label></label>
+ <label>N/A</label>
</object>
<flag>wxALIGN_CENTRE_VERTICAL|wxALL</flag>
<border>4</border>
Dave Page a écrit :
> On Wed, Aug 27, 2008 at 9:10 AM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
>
>> It seems at the right place to me. There are three columns on this tab:
>> first one for the labels, second one for the text box, and third one for
>> static texts showing current values.
>
> Oh, yes - of course. I wonder if we should give the static text boxes
> a thin border so it's obviously they are there, even when empty? At
> the moment it just looks odd.
>

I tried many things but didn't manage to get a border, thin or fat.
Perhaps wa can just put an N/A text on each static box? See attached patch.

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

Re: [pgsql-www] Download links

On Saturday 30 August 2008 15:59:41 Dave Page wrote:
> The ordering intentionally puts the easy to use, one size fits all
> above the platform specific packaging. Experience tells us that the
> people that have most trouble figuring out what to download tend to be
> the ones for whom the one-click point and drool packages are the most
> appropriate. The more experienced users are generally able to find the
> 'exact-fit' packages for their distro.

What is concerning me is that the one-click installer is essentially a
proprietary product and it is put into the prominent spot PostgreSQL ->
Download -> Linux -> first choice. Now, basically everyone who wants free
advertisement has to make their own one-click installer and fight with you
for that spot. At the very least, the whole thing should be moved to a
community-hosted infrastructure, an open development model, and no company
advertisement.

(For related reasons, I think the company names on the download pages should
be deleted altogether.)

Also, I would personally never recommend anyone using a non-distro packaged
binary, which is why I am concerned that we are putting this into the
prominent spot. There are good technical reasons for that recommendation.
For example, if you install a nonpackaged version of libpq, none of the other
packages available in your distro that depend on libpq will work. The
explanation you give above is acknowledged but I don't believe it is
accurate. The distro packaging should be the default even for the
non-superguru user.

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

Re: [GENERAL] ERROR: relation . . . does not exist

On Aug 30, 2008, at 9:19 AM, Christophe wrote:

>
> On Aug 30, 2008, at 6:26 AM, Albretch Mueller wrote:
>> Well, then obviously there is the need for it and you were not
>> successful enough at convincing these developers that they were
>> "confusing postgresql with a spreadsheet program"
>
> The behavior you are looking for is typical of a spreadsheet,
> because spreadsheet programs (generally; I'm sure there are
> exceptions) don't have the notion of a schema; each cell can hold
> its own particular type. That being said, the automatic type-
> guessing that Excel, say, provides is far from foolproof; I've
> probably spent more time cleaning up Excel's bad guesses than would
> have been saved by my just specifying a type for each column.
>
> As has been noted, text representation of values are extremely
> ambiguous as of which Postgres type they mean... and, of course, you
> could have user-defined domains and types as well. It's true that
> it could take a wild guess, but that's not a traditional part of a
> database engine.
>
> That being said, it would not be too hard to write a client that
> accepted a CSV or tab-delimited file, parsed the header into column
> names, and then scanned the values of the columns to take a
> reasonable guess as to the column type from a highly limited set of
> possibilities. This is probably one of those classic "twenty lines
> of Perl" problems.

About 150 line of perl[1]. It can actually work quite well, but is
entirely a client-side problem. None of that sort of heuristics should
go anywhere near COPY in.

> It doesn't seem as though COPY INTO is the right place for that,
> since the particular guesses and set of types that one would make
> strike me as very closely tied to your particular application domain.

Cheers,
Steve

[1] A validator (regex) for each data type, then for each column track
which data types it may be, as you scan through the file. Use the
relative priorities of different data types to assign something
appropriate for each column, then do a second pass translating the
format into something Postgresql is comfortable with and feed it into
pg_putcopydata.

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

[ADMIN] Configure DB

Hi List,
I'm working with Postgres,  I'm  storing spatial information, but I have any problems when I try to acces to my data..from php, visual basic and postgis too...

This is the message error:

Warning: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "???" and accepting TCP/IP connections on port 5432? in C:\Program Files\ms4w\Apache\htdocs\conexion.php on line 4

I read that I need to configure these files:
pg_hba.conf
postgresql.conf


I hope your help..
Thanks...

Re: [GENERAL] ERROR: relation . . . does not exist

On Saturday 30 August 2008 5:23:25 am Albretch Mueller wrote:
> On Thu, Aug 28, 2008 at 7:50 PM, Adrian Klaver <aklaver@comcast.net> wrote:
> > Define easily.
>
> ~
> OK, let me try to outline the approach I would go for:
> ~
> I think "COPY FROM CSV" should have three options, namely:
> ~
> 1) the way we have used it in which you create the table first
> ~
> 2) another way in which defaults are declared, generally as:
> ~
> 2.1) aggressive: data type, value and formatting analysis is done; if
> only 1 or 0 are found declare then a BOOLEAN, if repeated data is
> found (say state codes) and the stratification nodes cover the rest of
> the data, stratify the data out to other extra table (they have a name
> I can't recall now), index it ..., if data is kind of numeric with
> front slashes and/or hyphen could they possibly be dates? if they are
> definitelly dates convert them to bigint (and do the formatting in the
> presentation code (also this a win-win situation with i18n code)) ...
> ~
> 2.2) conservative: data type and value, but no formatting analysis is
> done and the greater encompassing data type is selected, say for 1 or
> 0 data use bytes [0, 255], for bytes use int, if something could be
> encoded as char(2), use varchar instead, . . .
> ~
> 2.3) dumn: just use the coarsest data type possible; bigint for
> anything that looks like a number and varchar for the rest
> ~
> the "dumn" option should suggest to the DBA the option they are
> using, quantified consequences for their desicions (larger DBs for no
> reason, approx. reduction in speed, . .) and how not to be "dumn"
> ~
> 3) or you could define "import templates" declaring which specific
> data types to use for data in a certain way, which could be declared
> per column using regexps
> ~
>
> > I could go on, but the point is that table data types require some
> > thought on the part of the DBA.
>
> ~
> Well, it still requires their minds and input, but they will have
> jobs even if they get some help, don't you think so ;-)
> ~
> lbrtchx

This is a combination of more work then necessary and putting the cart after
the horse. All I can see happening is delaying the point of decision to a
later time and or dumping the decision process on someone else. There is
already a "dumb" solution that has been brought many times on this list. It
involve creating a holding table that has text only fields and copying the
data into and then moving the data from there to a final table. As far as
import templates I suggest looking at:
http://pgloader.projects.postgresql.org/
It also addresses some of your other suggestions. It does not automatically
create a table though.

--
Adrian Klaver
aklaver@comcast.net

--
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] traduccion documentacion

2008/8/30 Manuel <jmgonbar@gmail.com>:
> Hubo un grupo hace no mucho que se encargaba de eso. Yo participé durante un
> tiempo
> y luego la página desapareció. Su dirección era:
> http://l10n.postgresql.cl/es/
> No se si alguien podrá dar más información sobre ese proyecto.
>

Hasta donde se eso se estanco... hace un tiempo hablando con Alvaro me
menciono que le habian recomendado Pootle
(http://translate.sourceforge.net/wiki/pootle/index) como una
alternativa viable. aunque el mismo aun no habia hecho la prueba. Y
tambien esta aun en mi lista de pendientes (que cada vez se hace mas
larga ;)

Alvaro se iba a poner en contacto con un grupo de Perú que iban a
iniciar una traducción al español de la documentación... seria
interesante saber en que quedo eso...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

Dave Page a écrit :
> On Thu, Aug 28, 2008 at 8:56 AM, Guillaume Lelarge
> [...]
>> I'll first work on the server status window (remember the first part:
>> Replace the wxNotebook widget with the wxAuiNotebook so users can close
>> tabs and rearrange tabs order via drag-and-drop.) When the first part
>> will be done, I'll have a better understanding of the AUI stuff.
>
> OK, cool. It's not a major issue though - I'd like to redesign the
> table dialogue (time allowing), and the design I have in mind would be
> landscape rather than portrait anyway.
>

Great, this is something I'm waiting for :)

To get back to my patch, do you have any issue with it or can I commit?

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

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

Re: [GENERAL] ERROR: relation . . . does not exist

On Aug 30, 2008, at 6:26 AM, Albretch Mueller wrote:
> Well, then obviously there is the need for it and you were not
> successful enough at convincing these developers that they were
> "confusing postgresql with a spreadsheet program"

The behavior you are looking for is typical of a spreadsheet, because
spreadsheet programs (generally; I'm sure there are exceptions) don't
have the notion of a schema; each cell can hold its own particular
type. That being said, the automatic type-guessing that Excel, say,
provides is far from foolproof; I've probably spent more time
cleaning up Excel's bad guesses than would have been saved by my just
specifying a type for each column.

As has been noted, text representation of values are extremely
ambiguous as of which Postgres type they mean... and, of course, you
could have user-defined domains and types as well. It's true that it
could take a wild guess, but that's not a traditional part of a
database engine.

That being said, it would not be too hard to write a client that
accepted a CSV or tab-delimited file, parsed the header into column
names, and then scanned the values of the columns to take a
reasonable guess as to the column type from a highly limited set of
possibilities. This is probably one of those classic "twenty lines
of Perl" problems.

It doesn't seem as though COPY INTO is the right place for that,
since the particular guesses and set of types that one would make
strike me as very closely tied to your particular application domain.

--
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] Is it really such a good thing for newNode() to be a macro?

"Stephen R. van den Berg" <srb@cuci.nl> writes:
> Tom Lane wrote:
>> ({ Node *__result__; \

> Please avoid identifiers starting with __ .

Yeah, I had misremembered which way that rule went. It's "_result"
as committed.

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

Re: [ODBC] Need a developer contact

Hi Devrim.

Sound good to me. However, I don't have much spare time now...
But but, it may be useful if your help occurs. what do you think?
P.S)
anyhow, the environment of ODBC of a check test is extensive.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Devrim GÜNDÜZ" <devrim@gunduz.org>
To: "pgsql-odbc" <pgsql-odbc@postgresql.org>

> Hello ODBC Developers,
>
> For the RPM Building Project, I am about to setup a mailing list -- one
> developer from each PostgreSQL related project will be subscribed to
> that list, so that we all can be informed about the release schedule for
> each project. Even though I first thought that it would be good for
> scheduling packaging, but it will also be a good source for PostgreSQL
> Weekly News (PWN). I am packaging about 50 PostgreSQL related software,
> but very few of them are announced on PWN
>
> Anyway, who wants to be on this list for odbc?
>
> Regards,
> --
> Devrim GÜNDÜZ, RHCE
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org
>

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

[pgadmin-hackers] SVN Commit by guillaume: r7450 - in trunk/pgadmin3/pgadmin: agent include/agent ui

Author: guillaume

Date: 2008-08-30 16:18:05 +0100 (Sat, 30 Aug 2008)

New Revision: 7450

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7450&view=rev

Log:
dlgSchedule is now growable.

Modified:
trunk/pgadmin3/pgadmin/agent/dlgSchedule.cpp
trunk/pgadmin3/pgadmin/include/agent/dlgSchedule.h
trunk/pgadmin3/pgadmin/ui/dlgSchedule.xrc
trunk/pgadmin3/pgadmin/ui/xrcDialogs.cpp

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

Re: [ADMIN] PITR with MS-DOS shell

On Fri, 2008-08-29 at 12:31 -0700, Richard Broersma wrote:
> Reading the manual for PITR, I see the backup commands are tar, cpio, and rsync.
>
> What DOS shell commands recommended: copy, xcopy? Is there something better?

Any command that copies files. Or an integrated backup product.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

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

Re: [GENERAL] DUPS in tables columns ERROR: column ". . . " does not exist

Albretch Mueller wrote:
> Hi,
> ~
> I am trying to get dups from some data from files which md5sums I
> previously calculated
> ~
> Here is my mere mortal SQL
> ~
> SELECT md5, COUNT(md5) AS md5cnt
> FROM jdk1_6_0_07_txtfls_md5
> WHERE (md5cnt > 1)
> GROUP BY md5
> ORDER BY md5cnt DESC;

I think you are looking for HAVING as in:

SELECT md5, COUNT(md5)
FROM jdk1_6_0_07_txtfls_md5
GROUP BY md5
HAVING count(md5) > 1

Stefan

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

[JDBC] Need a developer contact

Hello PG-JDBC Developers,

For the RPM Building Project, I am about to setup a mailing list -- one
developer from each PostgreSQL related project will be subscribed to
that list, so that we all can be informed about the release schedule for
each project. Even though I first thought that it would be good for
scheduling packaging, but it will also be a good source for PostgreSQL
Weekly News (PWN). I am packaging about 50 PostgreSQL related software,
but very few of them are announced on PWN

Anyway, which developer wants to be on this list?

Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

[ODBC] Need a developer contact

Hello ODBC Developers,

For the RPM Building Project, I am about to setup a mailing list -- one
developer from each PostgreSQL related project will be subscribed to
that list, so that we all can be informed about the release schedule for
each project. Even though I first thought that it would be good for
scheduling packaging, but it will also be a good source for PostgreSQL
Weekly News (PWN). I am packaging about 50 PostgreSQL related software,
but very few of them are announced on PWN

Anyway, who wants to be on this list for odbc?

Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [GENERAL] ERROR: relation . . . does not exist

> I think you're confusing postgresql with a spreadsheet program.
~
I wonder what makes you think so
~
> There are client programs which will do this for you, perhaps you wan one of those?
~
Well, then obviously there is the need for it and you were not
successful enough at convincing these developers that they were
"confusing postgresql with a spreadsheet program"
~
> PostgreSQL has 60+ types and many look like eachother. How do you propose to differentiate?
~
Data Types are basically about value ranges (how many bits do you
need to hold the value) and formatting. IMHO, finding an optimal
[im|ex]port reasoning among 60+ types should not be that much of a big
deal. In fact as a data analyst I have exported and imported CSV data
a whole lot and in many occasions it required some extra custom
coding. I may as well consolidate my code as a whole jcsvport library
in java and start an OS project when I find the time to so
~
lbrtchx

--
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] DUPS in tables columns ERROR: column ". . . " does not exist

Also I know there is a DISTINCT keyword, but I also need to know how
many times the particular data in the column is repeated if it is,
that is why I need to go:
~
SELECT md5, COUNT(md5) AS md5cnt
FROM jdk1_6_0_07_txtfls_md5
WHERE (md5cnt > 1)
GROUP BY md5
ORDER BY md5cnt DESC;
~
Thanks
lbrtchx

--
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] Download links

On Fri, Aug 29, 2008 at 9:36 PM, Chander Ganesan
<chander.ganesan@gmail.com> wrote:

> I just noticed this. I'm a little surprised that the "Release Candidate"
> all-in-one-binaries are situated such that they're the first thing selected.
> I would think that RC type stuff would remain somewhere other than the
> download pages until it's "released", or at least indicated in a
> hard-to-miss manner that they're release candidate.

The ordering intentionally puts the easy to use, one size fits all
above the platform specific packaging. Experience tells us that the
people that have most trouble figuring out what to download tend to be
the ones for whom the one-click point and drool packages are the most
appropriate. The more experienced users are generally able to find the
'exact-fit' packages for their distro.

The RC label is more of a disclaimer for the installers themselves
than anything else (the content is all release standard). They are
completely production ready imo - the ratio of downloads to issues
reported has been insanely high. I will be removing the RC label for
the next builds in a week or two.

--
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: [GENERAL] ERROR: relation . . . does not exist

On Sat, Aug 30, 2008 at 08:23:25AM -0400, Albretch Mueller wrote:
> OK, let me try to outline the approach I would go for:
> ~
> I think "COPY FROM CSV" should have three options, namely:

I think you're confusing postgresql with a spreadsheet program. A
database is designed to take care of your data and ensure its
integrity. As such it requires a little more thought.

There are client programs which will do this for you, perhaps you wan
one of those?

What's so hard about:

create table foo (a text, b text);

After which your COPY will complete fine.

> 2.1) aggressive: data type, value and formatting analysis is done; if
> only 1 or 0 are found declare then a BOOLEAN, if repeated data is
> found (say state codes) and the stratification nodes cover the rest of
> the data, stratify the data out to other extra table (they have a name
> I can't recall now), index it ..., if data is kind of numeric with
> front slashes and/or hyphen could they possibly be dates? if they are
> definitelly dates convert them to bigint (and do the formatting in the
> presentation code (also this a win-win situation with i18n code)) ...

PostgreSQL has 60+ types and many look like eachother. How do you
propose to differentiate?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

[ANNOUNCE] Benetl, free ETL tool, version 2.3 out !

Dear all,

A new version of Benetl, the ETL tool for files working with postgreSQL
8.3, is out !

You can freely download at : www.benetl.net

Regards,

--
Benoît Carpentier
www.benetl.net
Founder of Benetl & Java Developer

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

pgsql-announce-unsubscribe@postgresql.org