Re: [HACKERS] What Would You Like To Do?

2011-09-13 Thread Rodrigo Gonzalez

On 09/13/2011 03:51 PM, Michael Nolan wrote:

For example:


A fully integrated ability to query across multiple
databases,possibly
on multiple servers, something Oracle has had for nearly two
decades.



That isn't the approach to take. The fact that Oracle has it is
not a guarantee that it is useful or good. If you need to query
across databases (assuming within the same cluster) then you
designed your database wrong and should have used our SCHEMA
support (what Oracle calls Namespaces) instead.


This is the difference between developers and real world users.  Real 
world users may not have the ability, time or resources to redesign 
their databases just because that's the 'best' way to do something.  
Will it be the most efficient way to do it?  Almost certainly not.


I've been involved in a few corporate mergers, and there was a short 
term need to do queries on the combined databases while the tiger team 
handling the IT restructuring figured out how (or whether) to merge 
the dabases together.  (One of these happened to be an Oracle/Oracle 
situation, it was a piece of cake even though the two data centers 
were 750 miles apart and the table structures had almost nothing in 
common.  Another was a two week headache, the third was even worse!)


In a perfect world, it would be nice if one could do combined queries 
linking a PostgreSQL database with an Oracle one, or a MySQL one, 
too.  Because sometimes, that's what you gotta do.  Even something 
that is several hundred times slower is going to be faster than 
merging the databases together.  When I do this today, I have to write 
a program (in perl or php) that accesses both databases and merges it 
by hand.



Can't you do that with FDW that is present in 9.1?

Check http://wiki.postgresql.org/wiki/Foreign_data_wrappers



Re: [HACKERS] What Would You Like To Do?

2011-09-13 Thread Rodrigo Gonzalez

On 09/13/2011 04:52 PM, Tom Lane wrote:

Rodrigo Gonzalezrjgonz...@estrads.com.ar  writes:

In a perfect world, it would be nice if one could do combined queries
linking a PostgreSQL database with an Oracle one, or a MySQL one,

Can't you do that with FDW that is present in 9.1?

FDW provides the structure within which that will eventually be
possible, but there's no Oracle or MySQL wrapper today ... and there are
a lot of FDW restrictions that need to be worked on, too.

regards, tom lane


They are both listed at wiki
I know there are a lot of limitationsbut OP message says Even 
something that is several hundred times slower is going to be faster 
than merging the databases together.  When I do this today, I have to 
write a program (in perl or php) that accesses both databases and merges 
it by hand.

Am I wrong that this is currently possible using FDW?

Thanks

Rodrigo Gonzalez


--
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] Bad error message on valuntil

2013-06-07 Thread Rodrigo Gonzalez
On Fri, 07 Jun 2013 13:07:21 -0700
Joshua D. Drake j...@commandprompt.com wrote:

 
 On 06/07/2013 12:31 PM, Tom Lane wrote:
  Joshua D. Drake j...@commandprompt.com writes:
  On 06/07/2013 11:57 AM, Tom Lane wrote:
  I think it's intentional that we don't tell the *client* that
  level of detail.
 
  Why? That seems rather silly.
 
  The general policy on authentication failure reports is that we
  don't tell the client anything it doesn't know already about what
  the auth method is.  We can log additional info into the postmaster
  log if it seems useful to do so, but the more you tell a client,
  the more you risk undesirable info leakage to a bad guy.  As an
  example here, reporting the valuntil condition would be acking to
  an attacker that he had the right password.
 
 So security by obscurity? Alright, without getting into that argument 
 how about we change the error message to:
 
 FATAL: Authentication failed: Check server log for specifics
 
 And then we make sure we log proper info?

+1 


-- 
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] Kudos for Reviewers -- straw poll

2013-06-26 Thread Rodrigo Gonzalez
On Wed, 26 Jun 2013 09:14:07 -0400
Bruce Momjian br...@momjian.us wrote:

 On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
  On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
   How should reviewers get credited in the release notes?
  
   a) not at all
   b) in a single block titled Reviewers for this version at the
   bottom. c) on the patch they reviewed, for each patch
  
  A weak preference for (c), with (b) running a close second.  As
  others have suggested, a review that leads to significant
  commitable changes to the patch should bump the credit to
  co-authorship.
 
 As a reminder, I tried a variant of C for 9.2 beta release notes, and
 got lots of complaints, particularly because the line describing the
 feature now had many more names on it.

I am just someone that is thinking that maybe can review things...I am
not voting OK but I have a comment about your last email...
If people thinks (and with people I am not talking about myself but
regular committers and reviewers) think that option c is good, I think
that we should change the tool (or the way) that release notes are
doneI mean (and excuse my poor English) if people thing that it is
the way to go, we should make tools good enough for what people want
not change people thoughts cause tools are not good enough


 
 In my opinion, adding reviewer names to each feature item might result
 in the removal of all names from features.

Let's fix the way that release notes are done


 
 A poll is nice for gauging interest, but many people who vote don't
 understand the ramifications of what they are voting on.
 

I agree, but cost-benefit is what we should see here not just cost



-- 
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] Kudos for Reviewers -- straw poll

2013-06-26 Thread Rodrigo Gonzalez
On Wed, 26 Jun 2013 14:13:32 -0400
Bruce Momjian br...@momjian.us wrote:

 On Wed, Jun 26, 2013 at 03:12:00PM -0300, Rodrigo Gonzalez wrote:
  On Wed, 26 Jun 2013 09:14:07 -0400
  Bruce Momjian br...@momjian.us wrote:
  
   On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at
 the bottom. c) on the patch they reviewed, for each patch

A weak preference for (c), with (b) running a close second.  As
others have suggested, a review that leads to significant
commitable changes to the patch should bump the credit to
co-authorship.
   
   As a reminder, I tried a variant of C for 9.2 beta release notes,
   and got lots of complaints, particularly because the line
   describing the feature now had many more names on it.
  
  I am just someone that is thinking that maybe can review things...I
  am not voting OK but I have a comment about your last email...
  If people thinks (and with people I am not talking about myself but
  regular committers and reviewers) think that option c is good, I
  think that we should change the tool (or the way) that release
  notes are doneI mean (and excuse my poor English) if people
  thing that it is the way to go, we should make tools good enough
  for what people want not change people thoughts cause tools are not
  good enough
 
 Production of the release notes was not the problem;  it was the text
 in the release notes.  I don't see how we could modify the release
 note format.
 

Well...

Checking release notes for 9.2.4

you have Fix insecure parsing of server command-line switches
(Mitsumasa Kondo, Kyotaro Horiguchi)

What about (it people think that it is good) a second () with reviewed
by someone


-- 
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] Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters

2013-08-05 Thread Rodrigo Gonzalez
On Mon, 5 Aug 2013 15:53:01 -0400
Alvaro Herrera alvhe...@2ndquadrant.com wrote:

 The other issue is that currently you can only edit a server's config
 if you are logged in to it.  If we permit SQL-level access to that,
 and somebody who doesn't have access to edit the files blocks
 themselves out, there is no way for them to get a working system *at
 all*.
 

This is not a valid point, at least for mebasically all OSs should
disable any change to firewall if you are connected remotely cause you
can block yourselfgiving power to users does not mean being their
babysitterwe should smart enough to use the power we receive...if
we are not smart...we should start thinking about other profession

And excuse my English, I hope the point is clear...

Best regards

Rodrigo Gonzalez



-- 
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] enabling nestedloop and disabling hashjon

2015-02-12 Thread Rodrigo Gonzalez
On 12/2/15 18:29, Tom Lane wrote:
 Ravi Kiran ravi.kolanp...@gmail.com writes:
 I am sorry for the late reply, when I  disabled the hash join command
 enable_hashjoin=off in the postgresql.conf file, it was not working. But
 I when I used the command set enable_hashjoin=off command in the back
 end. It worked.
  I am not able to understand why it did not get disabled when I changed it
 in the postgresql file.
 
 The two plausible explanations for that are (1) you didn't do a reload
 or (2) you forgot to remove the '#' comment marker in the file's entry.

Or you changed the wrong postgresql.conf file

Regards

Rodrigo Gonzalez



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