On Aug 20, 2012 5:19 PM, "Phil Sorber" wrote:
>
> On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote:
> >
> > 2012/8/20 Robert Haas :
> > > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote:
> > >> I am providing a patch to allow you
On Aug 20, 2012 5:11 PM, "Pavel Stehule" wrote:
>
> 2012/8/20 Robert Haas :
> > On Sun, Aug 19, 2012 at 12:02 PM, Phil Sorber wrote:
> >> I am providing a patch to allow you to change the output of a boolean
> >> value in psql much like you can do with NU
Hello all,
I am providing a patch to allow you to change the output of a boolean
value in psql much like you can do with NULL. A client requested this
feature and we thought it may appeal to someone else in the community.
The patch includes updated docs and a regression test. The code
changes the
On Mon, Jun 25, 2012 at 3:45 PM, Florian Pflug wrote:
> On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
>> Magnus Hagander writes:
>>> Or that it takes less code/generates cleaner code...
>>
>> So we're talking about some LZO things such as snappy from google, and
>> that would be another run
On Thu, Jun 14, 2012 at 10:14 AM, Florian Pflug wrote:
> On Jun14, 2012, at 15:28 , Euler Taveira wrote:
>> On 14-06-2012 02:19, Tom Lane wrote:
>>> I still think that pushing this off to openssl (not an ssh tunnel, but
>>> the underlying transport library) would be an adequate solution.
>>> If yo
On Thu, Dec 22, 2011 at 3:19 PM, Robert Haas wrote:
> On Thu, Dec 22, 2011 at 2:02 PM, Phil Sorber wrote:
>> On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
>>> Robert Haas writes:
>>>> I'm wondering if we oughta just return NULL and be done with it.
>>
On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm wondering if we oughta just return NULL and be done with it.
>
> +1. There are multiple precedents for that sort of response, which we
> introduced exactly so that "SELECT some_function(oid) FROM some_catalog"
> wouldn
On Mon, Dec 19, 2011 at 1:27 PM, Phil Sorber wrote:
> On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber wrote:
>> Attached is a patch that addresses the todo item "Improve relation
>> size functions such as pg_relation_size() to avoid producing an error
>> when called a
On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber wrote:
> Attached is a patch that addresses the todo item "Improve relation
> size functions such as pg_relation_size() to avoid producing an error
> when called against a no longer visible relation."
>
> http://archives.pos
Attached is a patch that addresses the todo item "Improve relation
size functions such as pg_relation_size() to avoid producing an error
when called against a no longer visible relation."
http://archives.postgresql.org/pgsql-general/2010-10/msg00332.php
Instead of returning an error, they now ret
On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug wrote:
> On Oct20, 2011, at 01:19 , Tom Lane wrote:
>> Florian Pflug writes:
>>> Taking this even further, why do we bother with non-immutable (i.e.,
>>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
>>> at all?
>>
>> Y
On Wed, Oct 12, 2011 at 3:48 PM, Robert Haas wrote:
> On Wed, Oct 12, 2011 at 2:27 PM, Phil Sorber wrote:
>> I am going to remove that patch from the commit fest because we all
>> agree that it does not solve the problem satisfactorily. I would like
>> to re-iterate a few
On Mon, Oct 10, 2011 at 11:54 AM, Robert Haas wrote:
> On Thu, Aug 4, 2011 at 2:04 PM, Robert Haas wrote:
>> On Thu, Aug 4, 2011 at 1:53 PM, Phil Sorber wrote:
>>> Ok, here is the patch that just moves the ALTER/SET pieces to the end.
>>> Can we get this inclu
On Tue, Aug 2, 2011 at 5:05 PM, Tom Lane wrote:
> Phil Sorber writes:
>> I have included two patches in this email. The first
>> (dump_user_config_last_with_set_role.patch) is an extension of my
>> first patch. In addition to moving the ALTER ROLE statements after the
>
I have included two patches in this email. The first
(dump_user_config_last_with_set_role.patch) is an extension of my
first patch. In addition to moving the ALTER ROLE statements after the
CREATE ROLE statements it also inserts a SET ROLE after every connect.
It takes the role parameter from the -
Hello,
The attached patch changes the location of the dumpUserConfig call in
the dumpRoles function of pg_dumpall.
This is related to this thread:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
Currently if you use 'ALTER ROLE rolename SET ROLE', pg_dumpall will
dump an 'ALTER
101 - 116 of 116 matches
Mail list logo
