Re: [HACKERS] generic copy options

2009-09-20 Thread Marcos Luis Ortiz Valmaseda
I think that it is a good idea, but do you can show to us what do you have in 
mind with a example?

Regards

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: Emmanuel Cecchet m...@frogthinker.org
Para: Robert Haas robertmh...@gmail.com
CC: Emmanuel Cecchet m...@asterdata.com, Tom Lane t...@sss.pgh.pa.us, 
Emmanuel Cecchet emmanuel.cecc...@asterdata.com, Josh Berkus 
j...@agliodbs.com, PostgreSQL-development pgsql-hackers@postgresql.org
Enviados: Domingo, 20 de Septiembre 2009 16:24:28 GMT -10:00 Hawai
Asunto: Re: [HACKERS] generic copy options

The easiest for both implementation and documentation might just be to 
have a matrix of options.
Each option has a row and a column in the matrix. The intersection of a 
row and a column is set to 0 if options are not compatible and set to 1 
if it is. This way we are sure to capture all possible combinations.
This way, each time we find a new option, we just have to check in the 
matrix if it is compatible with the already existing options. Note that 
we can also replace the 0 with an index in an error message array.

I can provide an implementation of that if this looks interesting to anyone.
Emmanuel

Robert Haas wrote:
 On Sun, Sep 20, 2009 at 2:25 PM, Emmanuel Cecchet m...@asterdata.com wrote:
   
 Tom Lane wrote:
 
 Emmanuel Cecchet m...@asterdata.com writes:
   
 Here you will force every format to use the same set of options
 
 How does this force any such thing?

   
 As far as I understand it, every format will have to handle every format
 options that may exist so that they can either implement it or throw an
 error.
 

 I don't think this is really true.  To be honest with you, I think
 it's exactly backwards.  The way the option-parsing logic works, we
 parse each option individually FIRST.  Then at the end we do
 cross-checks to see whether there is an incompatibility in the
 combination specified.  So if two different formats support the same
 option, we just change the cross-check to say that foo is OK with
 either format bar or format baz.  On the other hand, if we split the
 option into bar_foo and baz_foo, then the first loop that does the
 initial parsing has to support both cases, and then you still need a
 separate cross-check for each one.

   
 That would argue in favor of a format option that defines the format. Right
 now I find it bogus to have to say (csv on, csv_header on). If csv_header is
 on that should imply csv on.
 The only problem I have is that it is not obvious what options are generic
 COPY options and what are options of an option (like format options).
 So maybe a tradeoff is to differentiate format specific options like in:
 (delimiter '.', format csv, format_header, format_escape...)
 This should also make clear if someone develops a new format what options
 need to be addressed.
 

 I think this is a false dichotomy.  It isn't necessarily the case that
 every format will support a delimiter option either.  For example, if
 we were to add an XML or JSON format (which I'm not at all convinced
 is a good idea, but I'm sure someone is going to propose it!) it
 certainly won't support specifying an arbitrary delimiter.

 IOW, *every* format will have different needs and we can't necessarily
 know which options will be applicable to those needs.  But as long as
 we agree that we won't use the same option for two different
 format-specific options with wildly different semantics, I don't think
 that undecorated names are going to cause us much trouble.  It's also
 less typing.

   
 PS: I don't know why but as I write this message I already feel that Tom
 hates this new proposal :-D
 

 I get those feeling sometimes myself.  :-)  Anyway, FWIW, I think Tom
 has analyzed this one correctly...

 ...Robert

   


-- 
Emmanuel Cecchet
FTO @ Frog Thinker 
Open Source Development  Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet


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

-- 
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] Crypto

2009-09-19 Thread Marcos Luis Ortiz Valmaseda
I think the same, These are not arguments to include crypto on the core, due to 
then all users have to think on this aspect to build a simple database, so we 
would be obligating to the users to use this module.

I´d let this module on the contrib 

Regards 

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: Tom Lane t...@sss.pgh.pa.us
Para: David Fetter da...@fetter.org
CC: Andrew Dunstan and...@dunslane.net, PG Hackers 
pgsql-hackers@postgresql.org
Enviados: Sábado, 19 de Septiembre 2009 6:33:36 GMT -10:00 Hawai
Asunto: Re: [HACKERS] Crypto 

David Fetter da...@fetter.org writes:
 On Sat, Sep 19, 2009 at 11:50:35AM -0400, Andrew Dunstan wrote:
 What benefit would we  gain from making general crypto part of the
 core?

 People may wish to encrypt things in the database.

That is not an argument why it has to be in core rather than an add-on.

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

-- 
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] Hot Standby 0.2.1

2009-09-18 Thread Marcos Luis Ortiz Valmaseda
I want to help on this area, but I need a mentor for this.
For example, Heikki will be a excellent mentor for me.

Following the theme, I think that we have to wide all questions for the process 
of the acceptance of a patch on the same way that you Simon.

We could write new requirements with all these ideas. Don´t you think?

Regards

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: Simon Riggs si...@2ndquadrant.com
Para: Robert Haas robertmh...@gmail.com
CC: Heikki Linnakangas heikki.linnakan...@enterprisedb.com, Josh Berkus 
j...@agliodbs.com, pgsql-hackers@postgresql.org
Enviados: Jueves, 17 de Septiembre 2009 20:53:24 GMT -10:00 Hawai
Asunto: Re: [HACKERS] Hot Standby 0.2.1


On Thu, 2009-09-17 at 19:01 -0400, Robert Haas wrote:
 
  I'm going to put the index-only scans aside for now to focus on hot
  standby and streaming replication. Both are big patches, so there's
  plenty of work in those two alone, and not only for me.
 
 What is the best way to attack this?  Should I keep reviewing
 index-only scans so that you have feedback for when you get back to
 it, or should I move on to something else?  If something else, does it
 make more sense for me to look at HS since I did a bit of work with a
 previous version, or would it be better for me to just pick one of the
 other patches from the CommitFest and work on that?
 
 Also, stepping back from me personally, should we try to assign some
 additional reviewers to these patches?  Is there some way we can
 divide up review tasks among multiple people so that we're not
 repeating each others work?
 
 Thoughts appreciated, from Heikki, Simon, or others.

I think this is a great opportunity to widen the pool of people
contributing to reviews.

I suggest the creation of a second group of people, performing
round-robin testing of patches. These people would be able to verify
* documentation matches implemented features (does it do what it says on
the tin?)
* usability of explicit features (do the features work well?)
* usability gap of unimplemented features (what else do we need?)
* are there any bugs?

These questions are often quickly answered for smaller patches, but HS's
scope mean that such a task properly executed could take a full week, if
not longer.

Second group of people are just as skilled Postgres people as reviewers,
in some cases more so, apart from they have less detailed knowledge of
the codebase. We have many such people and it would be good to encourage
them to perform thorough reviews rather than tire kicking.

I'm not sure that Heikki needs additional reviewers. He now has
significant knowledge of the patch and is good at focusing on key
aspects of the internals. Other code reviewers are welcome, of course.

-- 
 Simon Riggs   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

-- 
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] Crypto

2009-09-18 Thread Marcos Luis Ortiz Valmaseda
David Do you can comment this altertatives or choices that we have?

We can support us in Bruce Schneier[1], Chief Security Technology Officer, BT 
(schne...@schneier.com)
who is one of the person that knows many topics about security in the world. Is 
a very nice person and allways is to able to help to people. One of his 
knowledge areas is the hashing algorithm's desing and study, and we can ask to 
him since his point of view which would be the best algoritm to do this.

Regards
   
[1] http://www.schneier.com


The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: David Fetter da...@fetter.org
Para: PG Hackers pgsql-hackers@postgresql.org
Enviados: Viernes, 18 de Septiembre 2009 15:14:29 GMT -10:00 Hawai
Asunto: [HACKERS] Crypto

Folks,

Here's what came out for Mozilla, which, I hope you'll pardon my
saying so, is a teensy tad more widely used than PostgreSQL has any
plans to become.

http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm

I suggest that we start by putting secure hashing algorithms into the
core distribution so, should MD5 ever break, we have real
alternatives, and not done in a panic.

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

-- 
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] PGCluster-II Progress

2009-09-17 Thread Marcos Luis Ortiz Valmaseda
Excellent news,Mitani. My personal intention if to help you with this work for 
the redesign of PGCluster-II, or on the coding of it. 

If we work like a team, we can release this new version of the project more 
quickly.
Do you have any sources repository of this new version? I work fine with CVS 
and Subversion but if you are working with Git, is better, because is my 
favorite SCM.

Regards, and I'll be waiting your answer. 

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: mit...@sraw.co.jp
Para: dev...@gunduz.org, Marc G. Fournier scra...@hub.org
CC: pgsql-hackers pgsql-hackers@postgresql.org
Enviados: Jueves, 17 de Septiembre 2009 15:13:43 GMT -10:00 Hawai
Asunto: Re: [HACKERS] PGCluster-II Progress

I'm sorry for late my response.
I already sent same contents to Marcos, but I did not cc to all of yours.
(I'll join pgsql-hackers ML).

1. Statement of PGCluster-II
The state of PGCluster-II is re designing.
I developed and demonstorated PGCluster-II as full data shared model in 2006.
It worked fine. 
However, perfomance point of view, it was not good at all.
Then, I improved it in 2007. Even so, it was absurdly slow.

I think that it was required redesigning to improve performanse.
The full data shread model is not difficult to build up (I developed the 1st 
PGCluster-II within 2 weeks),
but it is not easy to improve performanse.
Then, I chose partial data shared model as my conclusion.
I spend two years to decide it.

2. Prospects of PGCluster-II
Currentry, I'm developing the cluster server management tools as a part of the 
latest PGCluster.
It will be upcoming release.
After that, I will be back to the PGCluster-II project.

On comming Nov. 19, The International PostgreSQL Cluster Developper's Meeting 
(I'm not sure the proper name) will be held in Tokyo.
I'll discuss about a task of PGCluster-II as a part of PostgreSQL's cluster 
project at the meeting. 
Clustering is getting more important each day.
I'm expecting that PGCluster  PGCluster-II play a role in the solution.

Best regards,
---
At.Mitani


-- original message --
From: Devrim G?ND?Zdev...@gunduz.org
To: Marc G. Fournierscra...@hub.org
Cc: Marcos Luis Ortiz Valmasedamlor...@uci.cu;
 mitanimit...@sraw.co.jp;pgsql-hackerspgsql-hackers@postgresql.org
Sent: Tue, 15 Sep 2009 19:20:37 +0300
Subject: Re: [HACKERS] PGCluster-II Progress

On Tue, 2009-09-15 at 13:16 -0300, Marc G. Fournier wrote:
 Odd, I talked to him a couple of weeks ago and he was working on a
 new 
 release in preparation for some upcoming talks he was doing ... was 
 working on bringing it up to support 8.3.x ...
 
 But, I'm just prepareing new version of the PGCluster...

Mitani was probably talking about PGCluster, not PGCluster -II. Mitani?

Last time I heard about PGCluster-II was at Anniversary Summit(2006).
Oh, and I met with him at France at 2007, and no improvements since
then.

Regards,
-- 
Devrim G?ND?Z, RHCE
Command Prompt - http://www.CommandPrompt.com 
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
   http://www.gunduz.org



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

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


[HACKERS] PGCluster-II Progress

2009-09-15 Thread Marcos Luis Ortiz Valmaseda
I was searching info about PgCluster-II yesterday and there is not much 
information about it.
Do can give to me any report of this? Because I need to know the progress of 
the project.
On PgFoundry, only it talks about PgCluster-1.9, but not of the 2.x versions.

Who is the PgCluster-II´s developer?

Regards

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


-- 
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] PGCluster-II Progress

2009-09-15 Thread Marcos Luis Ortiz Valmaseda
Yeah, the problem here is that CyberCluster is based yet on PostgreSQL 8.1 and 
is a very old version to use it.

I found the developer of PgCluster-II: Atsushi MITANI - mit...@sraw.co.jp


The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: Serge Fonville serge.fonvi...@gmail.com
Para: Marcos Luis Ortiz Valmaseda mlor...@uci.cu
CC: pgsql-hackers pgsql-hackers@postgresql.org
Enviados: Martes, 15 de Septiembre 2009 1:32:37 GMT -10:00 Hawai
Asunto: Re: [HACKERS] PGCluster-II Progress


I had the same question a while a go. 
After a lot of googling I found http://www.cybertec.at/english/start_e.html 
This seems to be an active replacement for the dead? pg-cluster 

HTH 

Regards, 

Serge Fonville 


On Tue, Sep 15, 2009 at 1:29 PM, Marcos Luis Ortiz Valmaseda  mlor...@uci.cu  
wrote: 


I was searching info about PgCluster-II yesterday and there is not much 
information about it. 
Do can give to me any report of this? Because I need to know the progress of 
the project. 
On PgFoundry, only it talks about PgCluster-1.9, but not of the 2.x versions. 

Who is the PgCluster-II´s developer? 

Regards 

The hurry is enemy of the success: for that reason...Be patient 

Ing. Marcos L. Ortiz Valmaseda 
Línea Soporte y Despliegue 
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) 

Linux User # 418229 
PostgreSQL User 
http://www.postgresql.org 
http://www.planetpostgresql.org/ 
http://www.postgresql-es.org/ 


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


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


[HACKERS] New features on 8.5 !!!!

2009-09-13 Thread Marcos Luis Ortiz Valmaseda
Regards to all the list.
Where I can find the new feautures that will be implemented on the 8.5 version?

Is there included the posibility on a tablespace restrict to a user to use a 
certain space inside it?

For example in Oracle you can do this:
CREATE TABLESPACE tb_space1
LOCATION '/mnt/Data'
OWNER 'dbuser'
USER peter 20 MB
USER tom 50 MB

This would be very useful on PostgreSQL

Regards

The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


-- 
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] New features on 8.5 !!!!

2009-09-13 Thread Marcos Luis Ortiz Valmaseda
Thanks, for the your quick answer.
I'll study the way We can do this, to me is very important and very useful that 
PostgreSQL has this feature.

Regards


The hurry is enemy of the success: for that reason...Be patient

Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)

Linux User # 418229
PostgreSQL User
http://www.postgresql.org
http://www.planetpostgresql.org/
http://www.postgresql-es.org/


- Mensaje original -
De: Heikki Linnakangas heikki.linnakan...@enterprisedb.com
Para: Marcos Luis Ortiz Valmaseda mlor...@uci.cu
CC: pgsql-hackers@postgresql.org
Enviados: Domingo, 13 de Septiembre 2009 8:54:49 GMT -10:00 Hawai
Asunto: Re: [HACKERS] New features on 8.5 

Marcos Luis Ortiz Valmaseda wrote:
 Regards to all the list.
 Where I can find the new feautures that will be implemented on the 8.5 
 version?

See http://www.postgresql.org/developer/roadmap.

We're also doing preliminary developer-oriented alpha releases
throughout the 8.5 release cycle. You can look at the release notes of
those to see which features have been completed thus far, but for
features that haven't been completed yet, there is no authoritative list
of what will be included in the next release as that depends on what
individual developers decide to work on.

 Is there included the posibility on a tablespace restrict to a user to use a 
 certain space inside it?

No. If you search the archives, you'll find that that has been discussed
before but no-one has come up with a robust way to implement that.

Suggestions and patches are welcome, of course..

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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