"Joshua D. Drake" writes:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > What would it take to have it included in core,
>>
>> I don't think this really makes sense. There's basically no argument
>> for having it in core other than "I'm too lazy to install
Greg Stark writes:
> It'll always be another (set of) processes even if it's "in core". All
> it means to be "in core" is that it will be harder to make
> modifications and you'll be tied to the Postgres release cycle.
Another set of processes all right, but that postmaster is responsible
of, tha
Jeff Davis wrote:
libpq has a PQclientEncoding() function that takes a connection object.
However, the client encoding is, in some cases, a property of the result
object. For instance, if your client_encoding changes, but you keep the
result object around, you have no way to determine later wha
Greg Stark wrote:
So in principle I agree with this idea. I think a conservative value
for the constant would be more like 100x though. If I told you we had
an easy way to speed all your queries up by 10% by caching queries but
were just choosing not to then I think you would be unhappy. Whereas
Robert Haas writes:
> Probably. For one thing, you can't use fork(), because it won't work
> on Windows.
[...]
> query. IOW, we're going to need, well, a connection pool in core.
> *ducks, runs for cover*
Well, in fact, you're slowly getting to the interesting^W crazy part of
it.
Now that you
Hello,
* Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope
so I understand SQL/PSM well so I am able to write production quality
implementation. If you like, I can integrate it to core. It can share
about 40-50% code with plpgpsm. The behave of plpgpsm is same as
plpgsql - witho
Now that PostgreSQL 9.0 alpha4 is bundled (though apparently not quite
out the door yet), it seems like a good time to think about what we'll
need to do to get to beta. Any thoughts?
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
lists no open items, and the Hot Standby TODO
On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen wrote:
> I may have cut this out of my original email for brevity... my impression is
> that the planner's estimate is likely to err on the side of scalability, not
> best-case response time; and that this is more likely to happen than an
> optimis
On Sun, Feb 21, 2010 at 3:25 AM, Robert Haas wrote:
> What kinds of things would be
> sensible to hand off in this way? Well, you'd want to find nodes that
> are not likely to be repeatedly re-executed with different parameters,
> like subplans or inner-indexscans, because otherwise you'll get
>
Pavel Stehule wrote:
This reasoning just doesn't fly in the PostgreSQL world. PostgreSQL is
designed to be extensible, not a monolithic product. We're not going to
change that because some companies have insane corporate policies. The
answer, as Jefferson said in another context, is to "inform
Pavel Stehule writes:
> * Last two months I spent some time with preparing workshops about SQL
> injection. PostgreSQL has only one issue related to this topic. It
> allows multi queries. With this feature any successful injection can
> have much more destructive impact. Now we have a GUC per user
Robert Haas writes:
> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
> lists no open items,
um ... are we looking at the same page? I see 8 open items there,
not counting the links to the separate HS and SR pages.
> My suspicion is that the real situation is more complicate
Pavel Stehule wrote:
> 2010/2/21 Andrew Dunstan :
> >> ? ?I believe that "in core" may be "installed by default" in case of
> >> ? ?the pgAgent or similar solution...
> >>
> >> ? ?Many big companies does not allow the developers to configure and
> >> ? ?install components we need to request eve
Tom Lane wrote:
> Robert Haas writes:
> > http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
> > lists no open items,
>
> um ... are we looking at the same page? I see 8 open items there,
> not counting the links to the separate HS and SR pages.
>
> > My suspicion is that the r
2010/2/20 Andrew Dunstan
>
> We're not going to change that because some companies have
> insane corporate policies.
I agree, Andrew...
This is an outside benefit...
not a reason or justification...
I believe that a general purpose scheduler is similar to
the autovacuum... it is not really nee
Lucas wrote:
> I believe that "in core" may be "installed by default" in case of
Those seem like totally orthogonal concepts to me.
A feature may be "in core" but not "installed by default" (like many PLs).
A feature might not be "in core" but "installed" by many installers (say
postgis).
I
Robert Haas writes:
> On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
>> There is a very clear set of behaviors that CORL ought to have given
>> the precedents of our other COR commands. If we don't make it do
>> things that way then we are going to surprise users, and we are also
>> going to pain
Ron Mayer writes:
> Is the real need here for a convenient way to enable and/or
> recommend packagers to install some non-core modules by default?
It would certainly help us resist assorted requests to put everything
including the kitchen sink into core.
regards, tom lane
Hello
I am looking on code in pl_exec.c file.
I see one issue:
/* --
* exec_run_select Execute a select query
* --
*/
static int
exec_run_select(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, long maxtuples, Portal
*portalP
On Sun, Feb 21, 2010 at 9:26 AM, Tom Lane wrote:
> Robert Haas writes:
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
>> lists no open items,
>
> um ... are we looking at the same page? I see 8 open items there,
> not counting the links to the separate HS and SR pages.
I
On Sun, Feb 21, 2010 at 12:33 PM, Tom Lane wrote:
> Ron Mayer writes:
>> Is the real need here for a convenient way to enable and/or
>> recommend packagers to install some non-core modules by default?
>
> It would certainly help us resist assorted requests to put everything
> including the kitche
We've just rejected Knn-gist indexes as "not enough time for 9.0", which
is a considerable disappointment for many people.
We already have a pluggable index API, but not one that supports
recoverability.
It is a simple patch to add recoverability to the index API, if we have
the will to do so.
Robert Haas wrote:
On Sun, Feb 21, 2010 at 9:26 AM, Tom Lane wrote:
Robert Haas writes:
http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items currently
lists no open items,
um ... are we looking at the same page? I see 8 open items there,
not counting the links to the separate HS and SR
On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
> I wonder if the scheduler already existed before the
> implementation of the autovacuum, its implementation would
> not be a function executed by the in-core scheduler?
The real genius of autovacuum is that it works out when there has been
enough
Robert Haas writes:
> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>> I wonder if the scheduler already existed before the
>> implementation of the autovacuum, its implementation would
>> not be a function executed by the in-core scheduler?
> The real genius of autovacuum is that it works ou
On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
>>> There is a very clear set of behaviors that CORL ought to have given
>>> the precedents of our other COR commands. If we don't make it do
>>> things that way then we are
On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Dave Page writes:
> >> Why not just use pgAgent? It's far more flexible than the design
> >> you've suggested, and already exists.
>
> > What would it take to have it included in core,
>
> I don't think this reall
On Sun, Feb 21, 2010 at 1:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 21, 2010 at 10:17 AM, Lucas wrote:
>>> I wonder if the scheduler already existed before the
>>> implementation of the autovacuum, its implementation would
>>> not be a function executed by the in-core schedul
On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote:
> On Sat, 2010-02-20 at 18:19 -0500, Tom Lane wrote:
>> Dimitri Fontaine writes:
>> > Dave Page writes:
>> >> Why not just use pgAgent? It's far more flexible than the design
>> >> you've suggested, and already exists.
>>
>> > What would it tak
Simon Riggs writes:
> We already have a pluggable index API, but not one that supports
> recoverability.
> It is a simple patch to add recoverability to the index API, if we have
> the will to do so.
I suggest you go re-read the archives before asserting this is a simple
no-thought-required fix.
On Sun, Feb 21, 2010 at 12:54 PM, Simon Riggs wrote:
> We've just rejected Knn-gist indexes as "not enough time for 9.0", which
> is a considerable disappointment for many people.
>
> We already have a pluggable index API, but not one that supports
> recoverability.
>
> It is a simple patch to add
Robert Haas writes:
> Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
> regardless of whether it solves the current problem, but having said
> that, I'm not clear on whether it does in fact solve the current
> problem. When PL/pgsql is installed by default, is it going to en
On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
>> regardless of whether it solves the current problem, but having said
>> that, I'm not clear on whether it does in fact solve the current
>> problem.
Hi,
As you all know, Index Organized tables are a way by which we can
automatically cluster the data based on the primary key. While i was
thinking about an implementation for postgres, it looks like an impossible
with the current ideologies. In an IOT, if a record gets updated, we need to
mark
Tom Lane wrote:
> Robert Haas writes:
> > On Feb 20, 2010, at 10:56 PM, Tom Lane wrote:
> >> There is a very clear set of behaviors that CORL ought to have given
> >> the precedents of our other COR commands. If we don't make it do
> >> things that way then we are going to surprise users, and we
Simon Riggs writes:
> There is currently no way to run a separate daemon process that runs
> user code as part of Postgres, so that the startup code gets run
> immediately we startup, re-run if we crash and shut down cleanly when
> the server does. If there were some way to run arbitrary code in a
Robert Haas writes:
> On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane wrote:
>> It will be owned by the bootstrap superuser, so the case is exactly
>> the one that a non-superuser DBA would be faced with.
> Or even a superuser other than the bootstrap superuser, no? I dump
> out the DB on my 8.4 serv
Bruce Momjian writes:
> Tom Lane wrote:
>> Attached is a draft patch (no doc changes) that implements CREATE OR
>> REPLACE LANGUAGE
> How is pg_migrator affected by this? It always loads the the dump as
> the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE?
pg_dump would issue
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Attached is a draft patch (no doc changes) that implements CREATE OR
> >> REPLACE LANGUAGE
>
> > How is pg_migrator affected by this? It always loads the the dump as
> > the super-user. How will the pg_dump use CREATE OR REPLACE L
On Thu, Feb 18, 2010 at 01:51:08PM -0800, David Fetter wrote:
> Folks,
>
> While hacking on PL/Parrot, I ran across an issue where when trying
> to load PL/pgsql, it's done unconditionally and fails. How do we
> fix pg_regress to be a little more subtle about this?
For now, and for the archives,
It is currently 22:21:59 EST here. At 21:50 I committed a fix to
copydir.c that cleaned up a couple of thinkos by Greg, including
a misspelling that had been making all the builds fail for several
hours. I went to see if any of the buildfarm had gone green yet,
and indeed half a dozen members had
Fujii Masao writes:
> + Free(xldir);
> s/Free/FreeDir ?
Yeah, that too. I think it's all good now, but please test.
One thing I was wondering was whether the stat-wrong-file problem
could explain the buildfarm failures that we thought were evidence
of a portability issue. I was tempted to
On Fri, Feb 19, 2010 at 7:54 PM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Magnus Hagander wrote:
>>> Well, it's going to make the process that reads the WAL cause actual
>>> physical I/O... That'll take a chunk out of your total available I/O,
>>> which is likely to push you to the
Gokulakannan Somasundaram wrote:
> Hi,
> As you all know, Index Organized tables are a way by which we can
> automatically cluster the data based on the primary key. While i was
> thinking about an implementation for postgres, it looks like an impossible
> with the current ideologies. In an IOT
44 matches
Mail list logo
