On 28 April 2013 13:22, Ants Aasma wrote:
> I have updated the base patch. This is supposed to go under the
> cflags-vector patch that Jeff posted yesterday.
I've committed your patch, with two changes
* one comment extended
* adding the .h file from Jeff's last main patch
Please can Ants and
On Mon, Apr 29, 2013 at 7:31 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Is there any reason why do we want to check the functional dependencies
> at
> > the time of parsing and not after rewrite? Obviously, by doing so, we
> will
> > allow creation of certain views which will start throwin
On Mon, Apr 29, 2013 at 10:51 PM, Peter Eisentraut wrote:
> On Sun, 2013-04-28 at 22:55 -0700, Atri Sharma wrote:
>> If we add support for weighted graphs, we can probably add support for
>> some common graph algorithms, such as Djikstra's algorithm, Bellman
>> Ford algorithm, a MST making algorit
On Tue, Apr 30, 2013 at 12:58 AM, Tom Lane wrote:
> Noah Misch writes:
>> Note also that minor releases can readily fix bugs in C-language functions,
>> but we have no infrastructure to update sql-language functions after initdb.
>> That flexibility is unfortunate to lose, particularly for someth
On Sun, 2013-04-28 at 22:55 -0700, Atri Sharma wrote:
> If we add support for weighted graphs, we can probably add support for
> some common graph algorithms, such as Djikstra's algorithm, Bellman
> Ford algorithm, a MST making algorithm, network flow algorithms.
You might find that pgRouting alr
On Tue, Apr 30, 2013 at 12:46 AM, Noah Misch wrote:
> Note that while the sql procedural language is fair game, plpgsql currently is
> not. We install it by default, but the DBA is free to drop it.
Right. The "sql" procedural language was what I had in mind.
> Those existing functions give a mo
On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote:
> The reason I'm thinking it's a good idea is that it would expose any
> remaining places where we have nominally var-length arrays embedded in
> larger structs. Now that I've seen the failures with gcc 4.8.0, I'm
> quite worried that there might
On Mon, Apr 29, 2013 at 9:44 PM, Stephen Frost wrote:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> If they modified the heap files that way while the server was
>> running, the results would be somewhat unpredictable. If they did
>> it while the server was stopped, starting the server and att
On Sat, 2013-04-27 at 14:24 -0400, Tom Lane wrote:
> Yeah, this is not tolerable. We could think about improving the logic
> to have a stronger check on whether the old server is really there or
> not (ie it should be doing something more like pg_ping and less like
> just checking if the pidfile i
* Kevin Grittner (kgri...@ymail.com) wrote:
> If they modified the heap files that way while the server was
> running, the results would be somewhat unpredictable. If they did
> it while the server was stopped, starting the server and attempting
> to access the matview would generate:
Right, the
On Mon, Apr 29, 2013 at 7:58 PM, Tom Lane wrote:
> The long and the short of it here is that there isn't any very good
> reason to migrate any of the existing pg_dump-side functionality into
> server-side functions,
There are a number of good reasons to do just that, which have been
previous
On Mon, Apr 29, 2013 at 3:34 PM, Kevin Grittner wrote:
> The hysteria and FUD about using the currently-supported technique
> for unlogged tables to implement unlogged matviews are very
> discouraging. And the notion that we would release a matview
> feature which allowed false results (in the fo
On 30/04/13 12:33, Любен Каравелов wrote:
- Цитат от Christopher Browne (cbbro...@gmail.com), на 29.04.2013 в 23:18
-
The one place where I *could* see a special type having a contribution
is for there to be a data type that can contain an arbitrary number of
links. That means you have
- Цитат от Christopher Browne (cbbro...@gmail.com), на 29.04.2013 в 23:18
-
>
> The one place where I *could* see a special type having a contribution
> is for there to be a data type that can contain an arbitrary number of
> links. That means you have one tuple per node, and, instead o
> Hm. I defended that restriction earlier, but it now occurs to me to
> wonder if it doesn't create a dump/reload sequencing hazard. I don't
> recall that pg_dump is aware of any particular constraints on the order
> in which it dumps privilege-grant commands. If it gets this right,
> that's mo
Noah Misch writes:
> Note also that minor releases can readily fix bugs in C-language functions,
> but we have no infrastructure to update sql-language functions after initdb.
> That flexibility is unfortunate to lose, particularly for something that
> pg_dump depends on.
That alone would probabl
On Mon, Apr 29, 2013 at 10:16:22PM +0100, Joel Jacobson wrote:
> Existing:
>
> pg_get_constraintdef
> pg_get_indexdef
> pg_get_viewdef
> pg_get_triggerdef
> pg_get_functiondef
> pg_get_ruledef
>
> Missing:
>
> pg_get_ts_templatedef
> pg_get_ts_parserdef
> pg_get_ts_configdef
> pg_get_ts_dictdef
Noah Misch writes:
> The particular restriction at hand, namely that a role have CREATE rights on a
> schema before assigning role-specific default privileges, seems like needless
> paternalism. It would be akin to forbidding ALTER ROLE ... PASSWORD on a
> NOLOGIN role. I'd support removing it w
On Mon, Apr 29, 2013 at 01:25:47PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > On 04/29/2013 09:59 AM, Tom Lane wrote:
> >> As I pointed out to you last night, it does already say that.
> >> I think the problem here is that we're just throwing a generic
> >> permissions failure rather than id
It does seem to me that we should Poissonize the throttle time, then
subtract the average overhead, rather than Poissonizing the difference.
After thinking again about Jeff's point and failing to sleep, I think that
doing exactly that is better because:
- it is "right"
- the code is simple
Tom,
I'm also seeing that the DEFAULT PRIVs I get seem to be dependant on my
login role, not my current role. That is, if role "dba" has default
privs set, and role "josh", which is a member of "dba" does not, and
"josh" does "set role dba" before creating some tables, those tables do
NOT get dba
>> what happens when an admin figures out that they can 'hack' the
>> system to do what they want by truncating that file?
That can't possibly be a serious objection. DBAs who mess with DB files
are on their own, and should expect unpredictable behavior.
--
Josh Berkus
PostgreSQL Experts Inc.
Existing:
pg_get_constraintdef
pg_get_indexdef
pg_get_viewdef
pg_get_triggerdef
pg_get_functiondef
pg_get_ruledef
Missing:
pg_get_ts_templatedef
pg_get_ts_parserdef
pg_get_ts_configdef
pg_get_ts_dictdef
pg_get_databasedef
pg_get_namespacedef
pg_get_languagedef
pg_get_conversiondef
pg_get_castdef
On 4/28/13 7:50 AM, Craig Ringer wrote:
I find it frustrating that I've never seen an @paraccel email address here and
that few of the other vendors of highly customised Pg offshoots are
contributing back. It's almost enough to make me like the GPL.
FWIW, I think there's a pretty large barrie
Stephen Frost wrote:
> what happens when an admin figures out that they can 'hack' the
> system to do what they want by truncating that file?
If they modified the heap files that way while the server was
running, the results would be somewhat unpredictable. If they did
it while the server was s
On 4/28/13 7:00 PM, Tom Lane wrote:
Thoughts? Anybody know of a counterexample to the idea that no plug-ins
call query_planner()?
I would assume that anyone writing anything that calls such a low-level
function reads -hackers regularly and would easily be able to handle whatever
changes to t
On Mon, Apr 29, 2013 at 10:50 AM, Merlin Moncure wrote:
> On Mon, Apr 29, 2013 at 9:25 AM, Atri Sharma wrote:
> >>
> >> This is an interesting idea. Historically I've always decomposed
> >> graphs into relational structures because that's the only practical
> >> way to query them. Graphs are
* Kevin Grittner (kgri...@ymail.com) wrote:
> Many people weighed in on the need to differentiate between an
> empty matview and one which has not been populated. Many have also
> weighed in on the benefits of unlogged matviews.
Sure, I think I did that- we should be able to distinguish between t
On 4/29/13 2:20 PM, Florian Pflug wrote:
On Apr29, 2013, at 21:00 , Atri Sharma wrote:
I think we find work arounds or make shifts at the moment if we need
to use graphs in our database in postgres. If we have a datatype
itself, with support for commonly used operations built inside the
type it
On Monday, April 29, 2013, Atri Sharma wrote:
> On Mon, Apr 29, 2013 at 10:12 PM, Misa Simic
> >
> wrote:
> > Hi Atri,
> >
> > What is an example of custom internal representation and its JSON
> > representation (though and JSON and HStore represent its value as text)?
> >
> > I also think that
On 4/29/13 1:08 PM, Fabien COELHO wrote:
While I don't understand the part about his laptop battery, I think that
there is a good use case for this. If you are looking at latency
distributions or spikes, you probably want to see what they are like with a
load which is like the one you expect h
Tom Lane wrote:
> [ shrug... ] You and Kevin essentially repeated your claims that
> the current implementation is OK; nobody else weighed in.
Many people weighed in on the need to differentiate between an
empty matview and one which has not been populated. Many have also
weighed in on the ben
On Apr29, 2013, at 21:00 , Atri Sharma wrote:
> I think we find work arounds or make shifts at the moment if we need
> to use graphs in our database in postgres. If we have a datatype
> itself, with support for commonly used operations built inside the
> type itself, that will greatly simplify use
I'm having a hard time understanding the use-case for this feature.
Here is an example functional use case I had in mind.
Let us say I'm teaching a practice session about administrating
replication. Students have a desktop computer on which they can install
several instances or postgresql,
On Mon, Apr 29, 2013 at 10:12 PM, Misa Simic wrote:
> Hi Atri,
>
> What is an example of custom internal representation and its JSON
> representation (though and JSON and HStore represent its value as text)?
>
> I also think that the key question is: "what operations would you support
> on this
Kevin Grittner wrote:
> After reviewing the threads and thinking about the various
> historical behaviors, I'm suggesting that we apply the attached,
> back-patched to 9.0, to fix the unintended changes from historical
> behavior related to lack of statistics generation in some cases
> where stat
Hello Jeff,
While I don't understand the part about his laptop battery, I think that
there is a good use case for this. If you are looking at latency
distributions or spikes, you probably want to see what they are like with a
load which is like the one you expect having, not the load which is
> Right. I wonder if there's any good reason why we shouldn't extend
> aclerror() to, in all cases, add a DETAIL line along the lines of
>
> ERROR: permission denied for schema web
> DETAIL: This operation requires role X to have privilege Y.
>
> Is there any scenario where this'd
Hello Tom,
I'm having a hard time understanding the use-case for this feature.
Surely, if pgbench is throttling its transaction rate, you're going
to just end up measuring the throttle rate.
Indeed, I do not want to measure the tps if I throttle it.
The point is to generate a continuous but
Josh Berkus writes:
> On 04/29/2013 09:59 AM, Tom Lane wrote:
>> As I pointed out to you last night, it does already say that.
>> I think the problem here is that we're just throwing a generic
>> permissions failure rather than identifying the particular permission
>> needed.
> Yeah, a better err
On 04/29/2013 09:59 AM, Tom Lane wrote:
> Josh Berkus writes:
>> This moves the general brokenness of this feature from a bug to (a) a
>> documentation issue and (b) unusably fussy. For (a), I think we need
>> the following line in the docs:
>
>> DEFAULT PRIVILEGES may only be granted to a ROLE
Josh Berkus writes:
> This moves the general brokenness of this feature from a bug to (a) a
> documentation issue and (b) unusably fussy. For (a), I think we need
> the following line in the docs:
> DEFAULT PRIVILEGES may only be granted to a ROLE which already has
> CREATE permission on the spe
On Mon, Apr 29, 2013 at 8:27 AM, Tom Lane wrote:
> Fabien COELHO writes:
> > Please find attached a small patch to add a throttling capability to
> > pgbench, that is pgbench aims at a given client transaction rate instead
> > of maximizing the load. The throttling relies on Poisson-distributed
> rhaas=# create user bob;
> CREATE ROLE
> rhaas=# create schema we_like_bob;
> CREATE SCHEMA
> rhaas=# alter default privileges for role bob in schema we_like_bob
> grant select on tables to bob;
> ERROR: permission denied for schema we_like_bob
> rhaas=# grant create on schema we_like_bob to bo
Hi Merlin,
" Graphs are not currently able to be transported
out of the database currently via JSON"
What does it mean?
(I probably dont understand graphs well - but from my point of view - any
data can be transported out of DB via JSON)
Thanks,
Misa
2013/4/29 Merlin Moncure
> On Mon, Apr
Hi Atri,
What is an example of custom internal representation and its JSON
representation (though and JSON and HStore represent its value as text)?
I also think that the key question is: "what operations would you support
on this
data type?"
Or what kind of problems it will solve? (what can't
Fabien COELHO writes:
> Please find attached a small patch to add a throttling capability to
> pgbench, that is pgbench aims at a given client transaction rate instead
> of maximizing the load. The throttling relies on Poisson-distributed
> delays inserted after each transaction.
I'm having a
>
> I don't agree with this; JSON is not really designed to store graphs.
> You will probably need a customized internal representation, just like
> hstore, that expresses a graph like structure.
Yes, we will have a custom internal representation. I was thinking of
ways to export the graph into us
On Mon, Apr 29, 2013 at 9:25 AM, Atri Sharma wrote:
>>
>> This is an interesting idea. Historically I've always decomposed
>> graphs into relational structures because that's the only practical
>> way to query them. Graphs are not currently able to be transported
>> out of the database currentl
>
> This is an interesting idea. Historically I've always decomposed
> graphs into relational structures because that's the only practical
> way to query them. Graphs are not currently able to be transported
> out of the database currently via JSON so one of the areas to focus
> your research wi
Ashutosh Bapat writes:
> Is there any reason why do we want to check the functional dependencies at
> the time of parsing and not after rewrite? Obviously, by doing so, we will
> allow creation of certain views which will start throwing errors after the
> underlying table changes the primary key.
On Mon, Apr 29, 2013 at 12:55 AM, Atri Sharma wrote:
>> It's probably pretty easy to add this, but I think the question is
>> what would make it better than storing the same representation in a
>> text field.
>
> I completely agree. The main point in making a new datatype would be
> to add support
Hello,
Please find attached a small patch to add a throttling capability to
pgbench, that is pgbench aims at a given client transaction rate instead
of maximizing the load. The throttling relies on Poisson-distributed
delays inserted after each transaction.
I wanted that to test the impact
On Sun, Apr 28, 2013 at 9:39 PM, Josh Berkus wrote:
>> The fine manual notes that the target role has to already have CREATE
>> privileges on the target schema --- maybe that's what's biting you in
>> this case?
>
> Nope. That was the first thing I thought of. It really is that the
> target role
54 matches
Mail list logo
