Brendan Jurd dire...@gmail.com 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
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:
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Andrew Gierth and...@tao11.riddles.org.uk 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
Josh Berkus j...@agliodbs.com 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,
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
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 individually at
Joshua D. Drake j...@commandprompt.com 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
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
10 matches
Mail list logo
