Hi Karl,
Sorry for the slow reply ...
Excerpt from Karl O. Pinc On Mon, Dec 10, 2012 at 5:00 AM:
> I was thinking along the same lines, that case 2) stderr to a file
> or pipe needs addressing. I think it's necessary to address the
> issue now. Otherwise we risk cluttering up the syntax in
>
On Thu, Dec 27, 2012 at 5:39 PM, Peter Bex wrote:
> On Thu, Dec 27, 2012 at 12:31:08PM -0300, Claudio Freire wrote:
>> On Thu, Dec 27, 2012 at 11:46 AM, Peter Bex wrote:
>> >
>> > Implementing a more secure challenge-response based algorithm means
>> > a change in the client-server protocol. Per
Hi Karl,
I have given the patch a quick review and read the related mails
following its initial submission.
I agree with that functionality along these lines is desirable. The
ability to manage output from within psql at least as richly as is
possible with shell redirection - and change it betwee
Patch for the changes discussed in
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
attached (eventually ...)
In summary: If the input file (-f) doesn't exist or the ouput or log
files (-o and -l) can't be created psql exits before prompting for a
password.
Regards,
Alastair.
On Thu, May 31, 2012 at 9:11 PM, Magnus Hagander wrote:
> On Thu, May 31, 2012 at 9:04 PM, Bruce Momjian wrote:
>> On startup, psql shows the SSL information:
>>
>> $ psql 'sslmode=require host=localhost'
>> psql (9.2beta1)
>> SSL connection (cipher: DHE-RSA-AES256-SHA, bits:
Excerpts from Kohei KaiGai wrote on Fri, May 25,
2012 at 11:08 PM:
> If we assume RLS is applied when user has
> no privileges on tables, the current ExecCheckRTEPerms()
> always raises an error towards unprivileged users, prior to
> execution of queries.
> Isn't it preferable behavior to allow un
On Wed, May 23, 2012 at 5:09 PM, Tom Lane wrote:
> Kohei KaiGai writes:
>> Let me have a discussion to get preferable interface for row-level security.
>> My planned feature will perform to append additional conditions to WHERE
>> clause implicitly, to restrict tuples being visible for the curren
On Fri, Apr 29, 2011 at 8:11 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne
>> wrote:
>>> The "bike shedding" that I'd rather have would involve enclosing
>>> prompts with /* comments */ so that cut'n'paste could be expected to
>>> generate outpu
On Thu, Apr 7, 2011 at 6:49 AM, Andrew Dunstan wrote:
>
> On 04/07/2011 12:29 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>>>
>>> On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
>
> The surprising (to me) consequence was that
On Tue, Nov 30, 2010 at 9:24 PM, Marko Tiikkaja
wrote:
>> On 11/30/2010 02:12 PM, Kevin Grittner wrote:
>>>
>>> Daniel Loureiro wrote:
>>>
to me the key its security - its a anti-DBA-with-lack-of-attention
feature.
>>>
>>> Well, it seems pretty weak to me for that purpose. You still t
Excerpt from Hitoshi Harada - Thu, Oct 14, 2010
at 4:32 PM:
> Just for information, did you pick this topic from TODO
> list? If so, could you attach links to the entry or to some related
> former thread? And in general it is encouraged that you'd better send
> one feature per a patch, in order fo
On Thu, Oct 14, 2010 at 4:05 PM, Tom Lane wrote:
> Alastair Turner writes:
>> I am proposing altering psql to raise certain errors and exit before
>> prompting for a password. These errors would have to be on items which
>> didn't leak any information, my current lis
Hi
I am a keen Postgres user and I run my local PUG (JNBPUG in Gauteng,
South Africa), but I have found the idea of contributing on a code
level daunting.
Having read the many warnings along the lines of "It's still on the
todo because it isn't trivial" I have identified what I believe is a
manag
A suggestion, based on what I believe would be ideal default settings
for a fully developed SR capability. The thought being that as long as
the default behaviour was stable additional knobs could be added
across version boundaries without causing trouble.
Per slave the master needs to know:
- Th
On Tue, May 25, 2010 at 6:28 PM, Simon Riggs wrote:
...
>
> The best parameter we can specify is the number of servers that we wish
> to wait for confirmation from. That is a definition that easily manages
> the complexity of having various servers up/down at any one time. It
> also survives m
2010/3/5 François Pérou :
> Thanks for your answers.
>
> To speak frankly:
>
> * I wrote the Drupal guide for porting from MySQL to PostgreSQL.
>
> * I am also the author of remarks about people should use PostgreSQL to
> write portable SQL.
>
> * I am very surprised by the SQL level of Php develop
On Tue, Jan 26, 2010 at 1:23 PM, Alastair Turner wrote:
> .
>
> Given that it potentially produces a delimited list, not a straight
> conacatenation (and that list is unacceptable since it would be
> descriptive as a noun but not as a verb) would implode_agg not be the
> mos
On Tue, Jan 26, 2010 at 1:08 PM, David E. Wheeler wrote:
.
>
> Because it's an aggregate that cocatenates values. It's not an aggregate
> that lists things. I also like concat_agg better than string_agg because
> it's not limited to acting on strings.
>
.
Given that it potentially prod
18 matches
Mail list logo
