On Wed, 2009-10-28 at 00:25 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
OK, this is the genuine failure; the syntax is missing for column triggers:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE
KaiGai Kohei wrote:
Robert Haas wrote:
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that anything without pg_dump support would be even vaguely OK...
In my
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Robert Haas wrote:
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that anything without pg_dump support would be even
Greg Stark gsst...@mit.edu writes:
On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus j...@agliodbs.com wrote:
You're hearing from the people who are working on tools: requiring that
any tool parse a hand-written config file is a non-starter.
It can be done, pgadmin actually does it currently. But
On Tue, Oct 27, 2009 at 11:40 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/27/09 8:24 PM, Robert Haas wrote:
read the old postgresql.conf and
write it back out to a new file line by line. If, in the process of
doing this, you find a setting for the variable you're trying to
change, then
KaiGai Kohei wrote:
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Robert Haas wrote:
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that anything without pg_dump
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Robert Haas wrote:
2009/10/27 KaiGai Kohei kai...@ak.jp.nec.com:
- no statement support to specify security context.
(It makes impossible to add support in pg_dump. Is it really OK?)
I doubt that
KaiGai Kohei escribió:
There are two cases when we create a new object.
1) create a new object without any explicit security context.
If we don't have statement support, it is the only case.
In this case, SELinux computes a default security context to be assigned
on the new object. It
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-10-28 at 00:25 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
OK, this is the genuine failure; the syntax is missing for column triggers:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table [ FOR [ EACH ] {
Alvaro Herrera wrote:
KaiGai Kohei escribió:
There are two cases when we create a new object.
1) create a new object without any explicit security context.
If we don't have statement support, it is the only case.
In this case, SELinux computes a default security context to be assigned
on the
KaiGai Kohei escribió:
Alvaro Herrera wrote:
Now, let's assume that COPY data includes the security context for each
tuple in the output.
When we support row-level security, it will be necessary to backup and
restore the security context for each tuples.
Oh, right, that part is being left
Forgive me for jumping in again on discussion of a feature I might
never use, but as an outside observer something doesn't make sense
to me.
Josh Berkus j...@agliodbs.com wrote:
If you require that a tool (or SET PERISTENT) parse through a file
in order to change one setting, then you've
Greg Smith escribió:
I was thinking that the algorithm would be something like: Read
the old postgresql.conf and write it back out to a new file line
by line
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it sucks, and it's a pain to covert
Kevin Grittner wrote:
But I think that's where the rub is -- when you
have more than one source for information, what's the precedence?
This is not a problem nowadays because that info is in pg_settings.
File name and line number.
--
Alvaro Herrera
Alvaro Herrera wrote:
Greg Smith escribió:
I was thinking that the algorithm would be something like: Read
the old postgresql.conf and write it back out to a new file line
by line
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it
Alvaro Herrera alvhe...@commandprompt.com wrote:
Kevin Grittner wrote:
But I think that's where the rub is -- when you
have more than one source for information, what's the precedence?
This is not a problem nowadays because that info is in pg_settings.
File name and line number.
I'm
Is there any interest in expanding \dn+ to show schema size, similar
to table sizes using \dt+ in 8.4? We use separate schemas for each
user, so this would allow us to quickly look up the sizes of each
user's data.
I have little experience with C and none with the PostgreSQL code base
--
While I'm fooling with the FOR UPDATE code ...
Currently, you can't apply FOR UPDATE to a relation that's on the inner
side of an outer join, eg
regression=# select * from a left join b using(aa) for update;
ERROR: SELECT FOR UPDATE/SHARE cannot be applied to the nullable side of an
outer join
On Wed, 28 Oct 2009, Alvaro Herrera wrote:
Huh, isn't this code in initdb.c already?
The sketched out design I have for a contrib/pgtune in C presumes that I'd
start by refactoring the relevant bits from initdb into a library for both
programs to use. But the initdb code doesn't care about
Greg Smith gsm...@gregsmith.com writes:
The sketched out design I have for a contrib/pgtune in C presumes that I'd
start by refactoring the relevant bits from initdb into a library for both
programs to use. But the initdb code doesn't care about preserving
existing values when making
On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Greg Smith escribió:
This sounds familiar...oh, that's right, this is almost the same
algorithm pgtune uses. And it sucks,
It's also a blatant violation of packaging rules for Debian if not
every distribution.
On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
That's why I'm proposing the following API at file level:
That's exactly the same as putting them all in the same file, only a
different syntax. It still requires that any program understand what
every other program
On 10/27/09 9:25 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
OK, this is the genuine failure; the syntax is missing for column triggers:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE
Kevin,
I'm talking about how the decision should be made as to which takes
precedence. It's fine to document which one *was* chosen, but that
doesn't eliminate the problem of conflicting settings making a mess.
Someone else (Robert maybe?) gave an explicit example of how three
files could
On Wed, 28 Oct 2009, Tom Lane wrote:
Why in the world are you looking at initdb? The standard reference for
postgresql.conf-reading code, by definition, is guc-file.l. I think the
odds of building something that works right, without borrowing that same
flex logic, are about nil.
initdb
On Wed, 28 Oct 2009, Greg Stark wrote:
It's also a blatant violation of packaging rules for Debian if not
every distribution. If you edit the user's configuration file then
there's no way to install a modified default configuration file. You
can't tell the automatic modifications apart from the
Josh Berkus j...@agliodbs.com wrote:
The precedence issues you (and Robert) are citing are no different
from what we have currently in a single file.
I think that's *why* we're mentioning it. This would seem to be the
juncture to look for ways to improve that, not just settle for no
worse
Greg Smith gsm...@gregsmith.com writes:
If as you say the only right way to do this is to use the flex logic, that
just reinforced how high the bar is for someone who wants to write a tool
that modifies the file.
Yup, exactly. Personally I think that trying to auto-modify
postgresql.conf is
On Wed, Oct 28, 2009 at 10:28 AM, Greg Smith gsm...@gregsmith.com wrote:
The postgresql.conf file being modified is generated by initdb, and it's
already being customized per install by the initdb-time rules like detection
for maximum supported shared_buffers. It isn't one of the files
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean that. It *looks* easy in perl, and in fact *is* easy
for *your*
On Wed, 2009-02-11 at 11:22 -0500, Tom Lane wrote:
Asko Oja asc...@gmail.com writes:
Did this change hashtext() visible to users? We have been using it quite
widely for partitioning our databases. If so then it should be marked quite
visibly in release notes as there might be others who
On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus j...@agliodbs.com wrote:
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean
Josh Berkus j...@agliodbs.com writes:
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it for rhetorical effect.
I actually mean that. It *looks* easy in
Hannu Krosing ha...@2ndquadrant.com writes:
I had never checked the docs for hash functions, but I had assumed, that
internal functions are prefixed by pg_ and anything else is public, free
to use functionality.
Sure, it's free to use. It's not free to assume that we promise never
to change
On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
I had never checked the docs for hash functions, but I had assumed, that
internal functions are prefixed by pg_ and anything else is public, free
to use functionality.
Sure, it's free to
Kenneth Marshall k...@rice.edu writes:
On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote:
Hash indexes are so far from being production-grade that this argument
is not significant.
In addition that change from 8.3 - 8.4 to store only the hash and not
the value in the index means that
On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
Is at least the fact that they are undocumented, have changed in the
past, and are likely to change again in the future documented ?
That's a little confusing to me: how do we document that something is
undocumented? And where do we stop?
On Wed, 28 Oct 2009, Josh Berkus wrote:
It's the basic and unsolvable issue of how do you have a file which is
both perfectly human-readable-and-editable *and* perfectly
machine-readable-and-editable at the same time.
Let's see...if I remember correctly from the last two rounds of this
On Wed, Oct 28, 2009 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Kevin,
Perhaps the ease of writing something like that with sed or perl has
caused me to underestimate the effort required in C. I am curious
whether you actually mean that, or said it
Let's see...if I remember correctly from the last two rounds of this
discussion, this is the point where someone pops up and says that
switching to XML for the postgresql.conf will solve this problem.
Whoever does that this time goes into the ring with Kevin and I, but
they don't get a club.
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I regularly (several times a day) see five or six processes all with
pg_locks locktype=extend granted=f on the same table, waiting for a long
time.
I'm not sure what's causing that, but I *seriously* doubt that adding
On Wed, 2009-10-21 at 23:26 +0300, Peter Eisentraut wrote:
Alpha2 has been bundled and is available at
http://developer.postgresql.org/~petere/alpha/
Please check that it is sane.
Peter, could you please provide md5sum for alpha2 tarball? I know we
missed in alpha1. It would be better if
On Wed, Oct 28, 2009 at 4:24 PM, Josh Berkus j...@agliodbs.com wrote:
Let's see...if I remember correctly from the last two rounds of this
discussion, this is the point where someone pops up and says that
switching to XML for the postgresql.conf will solve this problem.
Whoever does that this
On Wed, 28 Oct 2009, Robert Haas wrote:
It would be completely logical to break up the configuration file into
subfiles by TOPIC. That would complicate things for tool-writers
because they would need to get each setting into the proper file, and
we currently don't have any infrastructure for
On Wed, Oct 28, 2009 at 4:52 PM, Greg Smith gsm...@gregsmith.com wrote:
On Wed, 28 Oct 2009, Robert Haas wrote:
It would be completely logical to break up the configuration file into
subfiles by TOPIC. That would complicate things for tool-writers
because they would need to get each setting
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
Is at least the fact that they are undocumented, have changed in the
past, and are likely to change again in the future documented ?
That's a little confusing to me: how do we
Greg Smith wrote:
On Wed, 28 Oct 2009, Josh Berkus wrote:
It's the basic and unsolvable issue of how do you have a file which is
both perfectly human-readable-and-editable *and* perfectly
machine-readable-and-editable at the same time.
Let's see...if I remember correctly from the last two
On Wed, 2009-10-28 at 15:31 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
I had never checked the docs for hash functions, but I had assumed, that
internal functions are prefixed by pg_ and anything else is public, free
to use functionality.
Sure, it's free to use.
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote:
new feature
One additional point that would be useful is a way to match up the usage
of custom_variable_classes with this new style of .conf file processing.
At the moment if you wish to add a custom variable class everybody needs
to edit the
Le mercredi 28 octobre 2009 à 15:11:31, Anders Steinlein a écrit :
Is there any interest in expanding \dn+ to show schema size, similar
to table sizes using \dt+ in 8.4? We use separate schemas for each
user, so this would allow us to quickly look up the sizes of each
user's data.
I have
In http://archives.postgresql.org/message-id/26545.1255140...@sss.pgh.pa.us
I suggested that we should push the actual execution (not just queuing)
of non-deferred AFTER triggers into the new ModifyTable plan node.
The attached patch does that, and seems like a nice improvement since it
removes
Tom Lane wrote:
So, before I go off and do that work: anybody have an objection to this
line of development? The main implication of changing to this approach
is that we'll be nailing down the assumption that each WITH (command
RETURNING) clause acts very much like a separate statement for
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Like we've discussed before, WITH (.. RETURNING ..) is probably most
useful for moving rows from one table to another. When you're moving a
lot of rows around, there's some point where I believe this execution
strategy will be a lot slower
On Wed, Oct 28, 2009 at 8:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
Like we've discussed before, WITH (.. RETURNING ..) is probably most
useful for moving rows from one table to another. When you're moving a
lot of rows around, there's some
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take over the work if there are no ones to do it.
I'm thinking
2009/10/29 Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp:
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So,
56 matches
Mail list logo
