Bruce Momjian wrote:
Alvaro Herrera wrote:
Would it make sense to instead of removing and deferring pieces bit by bit to
instead work the other way around? Extract just the part of the patch that
maps SELinux capabilities to Postgres privileges as a first patch? Then
discuss any other parts indi
"Joshua D. Drake" wrote:
> > So has anyone here done any experiments with live systems with different
> > block
> > sizes? What were your experiences?
>
> I tested with 4k once. The system tanked. This might be a good one for
> the performance lab.
I'm using 16k blocks for one system. There
Alvaro Herrera wrote:
> > Would it make sense to instead of removing and deferring pieces bit by bit
> > to
> > instead work the other way around? Extract just the part of the patch that
> > maps SELinux capabilities to Postgres privileges as a first patch? Then
> > discuss any other parts individ
Hi all,
I am using Postgres to build the prototype in a research project. I need
to create a new system catalog table with an auto-increment column. For
a ordinary table, CREATE SEQUENCE or a serial type can be used to
implement the auto-increment column, but it seems Postgres do not
support creati
Josh Berkus writes:
> Tom Lane wrote:
>> The question is why this should be tied to SET ROLE, which already has
>> well defined semantics that don't include any such behavior.
> Mostly because we don't have anywhere else to hang a "settings profile"
> than ROLEs.
So we should fix that, if we wa
Andrew Gierth writes:
> This is just the fix for hstore's silent truncation, including
> doc patch and regression test.
Thanks --- applied with minor editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Tom Lane wrote:
Josh Berkus writes:
As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
8K) and throwing an error. I'd also be fine with limiting keys to 255
bytes, although we'd have to warn people.
Yeah, 255 might well be more of a problem than the other limit. We
co
Tom Lane wrote:
Josh Berkus writes:
What I want to be able to do is to set different bunches of resource
management settings for various non-login inherited roles, and be able
to choose profiles via a SET ROLE. The reason to do this, btw, instead
of defining various login roles, is that diff
All,
For anyone who cares, we have some unscientific results on the system
views survey:
http://www.postgresql.org/community/survey.60
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
Brendan Jurd writes:
> Short version: I think using CC and AD/BC in combination with week
> dates would be downright weird, but I don't object to the patch.
I agree it's pretty weird, but I can't immediately see any reason that
it shouldn't (be allowed to) work. It would only get interesting if
10 matches
Mail list logo
