Hello Alfranio,
alfranio correia junior wrote:
Of course not...
It is impossible to build a replication system entirely by only using
triggers...
Hm, I don't think it's impossible, just unpractical. Anyway, if you say
so yourself, I really doubt the use of GAPI. If you need to create your
Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
I like the idea of a package being a schema. I imagine that a package
would put its own schema name first in the 'search_path' before
referencing an object. I think anything more complex is going to be too
hard to use.
Or we could just add
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like a shared variable
3. Packaging - installation/dependency handling
Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
Namespaces
Given that we already have search_path it makes sense to use it. So, we
could have something like:
1. A PRIVATE modifier for objects that mean they are only accessible
if their schema is
On Tue, 2006-08-08 at 22:14, Tom Lane wrote:
So some kind of override for statistical guesses doesn't seem completely
silly to me. But it needs to be declarative information that's stored
somewhere out of view of the actual SQL queries. IMHO anyway.
The real problem is that sometimes there's
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like a shared variable
3. Packaging - installation/dependency handling
and 4. support more languages:
4a) binary incompatibility between
-- Forwarded message --From: Gourish Singbal [EMAIL PROTECTED]Date: Aug 9, 2006 12:25 PM
Subject: unsubscribeTo: pgsql-performance@postgresql.org
-- Forwarded message --From: Gourish Singbal
[EMAIL PROTECTED]Date: Aug 9, 2006 12:24 PM Subject: unsubscribeTo:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
ISTM theat the easiest way would be to introduce a sort of predicate
like so:
SELECT * FROM foo, bar WHERE pg_selectivity(foo.a = bar.a, 0.1);
The one saving grace of Florian's proposal was that you could go hack
the
On Mon, 2006-08-07 at 13:05 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've implemented this for BTree, GIN, GIST using an additional rmgr
functionbool rm_safe_restartpoint(void)
...
Recovery checkpoints are now renamed restartpoints to avoid
confusion with
On Sat, 2006-08-05 at 23:57 -0400, Tom Lane wrote:
I also made the new user-level functions a bit
more orthogonal, so that filenames could be extracted from the
existing functions like pg_stop_backup.
Something Hannu wrote has just reminded me that
pg_current_xlog_location() returns the
On Wed, Aug 09, 2006 at 12:57:39PM +0200, Florian G. Pflug wrote:
Fixing the generic problem is surely the best _if_ there is a fix for
the generic problem at all. But if your where-conditions involves fields
from 10 different tables, then IMHO there is no way to _ever_ guarantee
that postgres
Quoth [EMAIL PROTECTED] (Joshua D. Drake):
Josh Berkus wrote:
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3 months pass
B comes to
Josh Berkus wrote:
Zdenek,
However what happened? I think that following scenarios occurred.
Postmaster listen only in one process and there are many clients run
really parallel. T2000 server has 32 threads ( 8 core and each has 4
threads). These clients generate more TCP/IP request at one
Zdenek Kotala wrote:
Josh Berkus wrote:
Zdenek,
However what happened? I think that following scenarios occurred.
Postmaster listen only in one process and there are many clients run
really parallel. T2000 server has 32 threads ( 8 core and each has 4
threads). These clients generate more
Am Freitag, 4. August 2006 04:50 schrieb Tom Lane:
I'd like to see us refactor the docs as necessary to reflect that idea.
Peter is right that this needs some discussion in syntax.sgml as well as
in the reference pages --- but I'm still not very clear on how the
presentation should go.
I'm
Christopher Browne wrote:
Quoth [EMAIL PROTECTED] (Joshua D. Drake):
Josh Berkus wrote:
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3
Florian G. Pflug [EMAIL PROTECTED] writes:
Image a complex, autogenerated query with looks something like this
select
from t1
join t2 on ...
join t3 on ...
join t4 on ...
...
...
where
big, complicated expression derived from some user input.
This big, complicated expression
stark [EMAIL PROTECTED] writes:
I think the ideal combination is having every type have precisely one
implicit cast up the type tree and assignment casts down the
tree.
No, because for example in the case of the numeric datatypes, that would
result in *every* cross-type operation being done in
Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
On Sat, 2006-08-05 at 23:57 -0400, Tom Lane wrote:
I also made the new user-level functions a bit
more orthogonal, so that filenames could be extracted from the
existing functions like pg_stop_backup.
Something Hannu
Richard Huxton wrote:
Packaging
I'd guess we'd need a pg_package and pg_package_items system tables. We
could track:
- package name (different from schema)
- version number
- install/uninstall functions
- start-session/end-session functions
- dependencies (is pg_depend enough)
There's a LOT of unnecessary overhead in that process: having a
simple web app that lists who claimed what todo and when, any
status updates if they've voluntarily provided them, and links to
archive discussions, we could reduce the above to a 3-step process
making it vastly
Is there a way to determine which datatypes take a length argument (eg.
varchar, time, etc...) by looking in the system catalogs? pg_type doesnt seem
to have the info... or is there a single place in the back end code that
contains this info?
--
Robert Treat
Build A Brighter LAMP ::
Joshua D. Drake [EMAIL PROTECTED] writes:
My point was, I was going to work on some todos before feature freeze. I
asked about two specific todos. One of them was badly worded and one of
them did not represent (except in the smallest of ways) what it actually
was.
Well, it's certainly the
On Wed, Aug 09, 2006 at 10:44:22AM -0400, Robert Treat wrote:
Is there a way to determine which datatypes take a length argument (eg.
varchar, time, etc...) by looking in the system catalogs? pg_type doesnt seem
to have the info... or is there a single place in the back end code that
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like a
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
My point was, I was going to work on some todos before feature freeze. I
asked about two specific todos. One of them was badly worded and one of
them did not represent (except in the smallest of ways) what it actually
was.
What this story does do for me is reinforce the notion that it's
critical for newbie developers to work in the open, getting feedback
from the lists at an early stage about what they are doing. If you go
off in a corner and develop a patch for a TODO item, you risk having it
rejected because
Well, it would be nice to have some clarification about the expected
scope and lifetimes of these variables. If two different sessions
change the values, what's supposed to happen?
Right, I am confused whether these are session or schema-local
variables. What does Oracle support?
Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.
We say that clearly in the developer's FAQ, but it seems it is not
enough.
I just read the developer's FAQ, and
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like
Joshua D. Drake wrote:
Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.
We say that clearly in the developer's FAQ, but it seems it is not
enough.
I
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and clean up.
Or better yet, if editing the TODO is
SELECT * FROM foo, bar WHERE pg_selectivity(foo.a = bar.a, 0.1);
ISTM that you introduced the Oracle silliness again, putting the hint into the
query.
My suggestion would be to tell about it separately. Something like
CREATE HINT FOR JOIN foo, bar ON foo.a=bar.b AS some hint;
This way hints
We now have URLs on the TODO list to the archives, and the next FAQ item
is:
H3 id=item1.41.4) What do I do after choosing an item to
work on?/H3
PSend an email to pgsql-hackers with a proposal for what you want
to do (assuming your contribution is not trivial). Working in
so
Jim C. Nasby wrote:
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and clean up.
Or better yet, if
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
bruce wrote:
bruce wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
Let me add that anyone who has CVS commit access or wants
Simon Riggs [EMAIL PROTECTED] writes:
Something Hannu wrote has just reminded me that
pg_current_xlog_location() returns the current Insert pointer rather
than the current Write pointer.
That would not be useful for streaming xlog records would it?
Good point.
Methinks it should be the
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
Methinks it should be the Write pointer all of the time, since I can't
think of a valid reason for wanting to know where the Insert pointer is
*before* we've written to the xlog file.
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
To be fair, Bruce has offered to allow that to happen even on his home
machine (Bruce that is a bad idea btw) and ANYONE can submit a
Joshua D. Drake wrote:
Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
To be fair, Bruce has offered to allow that to happen even on his home
machine (Bruce that is a bad idea btw) and ANYONE can submit a patch.
It may not be a
Jim C. Nasby wrote:
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and clean up.
Or better
Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2006-08-09%2010:05:01
Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2006-08-09%2009:05:01
is the first
Joshua D. Drake wrote:
We now have URLs on the TODO list to the archives, and the next FAQ item
is:
H3 id=item1.41.4) What do I do after choosing an item to
work on?/H3
PSend an email to pgsql-hackers with a proposal for what you want
to do (assuming your
Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and
Jim C. Nasby wrote:
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
bruce wrote:
bruce wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
Let me add that anyone who
On Wed, Aug 09, 2006 at 10:55:30AM -0400, Bruce Momjian wrote:
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO
Andrew Dunstan wrote:
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
To be fair, Bruce has offered to allow that to happen even on his home
machine (Bruce that is a bad idea btw) and ANYONE can
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can actually make approved
todos versus
Joshua D. Drake wrote:
Hi, I am a C developer, PostgreSQL Rocks... I would like to take the
Enums todo. Here are my specific questions regarding your feature
requirements at URL ---
Well, few have shown any interest in improving the TODO list, so who is
going to be motivated to do
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can actually
Jim C. Nasby wrote:
Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2006-08-09%2010:05:01
Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
On Wed, Aug 09, 2006 at 03:05:02PM +0200, Peter Eisentraut wrote:
Am Freitag, 4. August 2006 04:50 schrieb Tom Lane:
I'd like to see us refactor the docs as necessary to reflect that
idea. Peter is right that this needs some discussion in
syntax.sgml as well as in the reference pages ---
Bruce Momjian wrote:
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can
On Wed, Aug 09, 2006 at 11:48:41AM +0200, Pavel Stehule wrote:
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like a shared variable
3. Packaging - installation/dependency handling
A number of people have asked me about this, so I'll just post the info
publicly.
On August 1st I started work for Anchorage Capital LLC as a Senior
Software Engineer. I am currently doing some urgent infrastructure work,
but in the longer term this job will involve some quite heavy lifting
On Wed, Aug 09, 2006 at 06:34:16AM +0200, Pavel Stehule wrote:
Is it would be nice , if packages have been ;
1. Package level variables (Public variables)
is very hard for imlementation, and it's actually impossible. Needs large
changes in code
2. Package member level variables
Joshua D. Drake wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't
;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as
1. Better descriptions about the todo/feature? E.g; feature specification
I am not sure there is enough churn of TODO items to make larger
descriptions worth it. As it is, I have to link to new URLs as the TODO
item is clarified.
Are you kidding? Did you see the discussion just on the todo
Joshua D. Drake wrote:
1. Better descriptions about the todo/feature? E.g; feature specification
I am not sure there is enough churn of TODO items to make larger
descriptions worth it. As it is, I have to link to new URLs as the TODO
item is clarified.
Are you kidding? Did you see
Yesterday I suggested that we should redesign the PL plugin patch:
http://archives.postgresql.org/pgsql-patches/2006-07/msg00291.php
in view of the recently-committed patch to add initialization/
finalization support for all dynamic libraries loaded into the backend:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are
From: Jim C. Nasby [EMAIL PROTECTED]
To: Pavel Stehule [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal for PL packages for 8.3.
Date: Wed, 9 Aug 2006 11:27:01 -0500
On Wed, Aug 09, 2006 at 06:34:16AM +0200, Pavel Stehule wrote:
Is it
3. Heck *your portion* of the TODO would be easily satisfied by having a
single line with a link that points to the specific wiki page.
But who is going to do that if no one has done anything in the past for
the TODO list. I keep asking that.
I believe that Andrew and I as well as a few
David Fetter [EMAIL PROTECTED] writes:
However, there are some oddities:
postgres=# SELECT * FROM (VALUES (1,2)) AS foo(bar,baz);
[ works ]
postgres=# (VALUES (1,2)) AS foo(bar,baz);
ERROR: syntax error at or near AS
This is per spec. Effectively, AS is part of the FROM-clause syntax
not
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?
Jim C. Nasby wrote:
4. Syntax must be as closer as plpgsql (declaration, assingment etc)
rather than any syntax that we have to learn :-)
PostgreSQL support other languages than PL/pgSQL. We need universal syntax
for plperl and others too
Why? Don't those other languages have
On Wednesday 09 August 2006 10:53, Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 10:44:22AM -0400, Robert Treat wrote:
Is there a way to determine which datatypes take a length argument (eg.
varchar, time, etc...) by looking in the system catalogs? pg_type doesnt
seem to have the
Tom Lane wrote:
The other, probably more controversial bit of functionality is that there
needs to be a way to cause a backend to load a PL plugin shared library
without any cooperation from the connected client application. For
interactive use of a PL debugger it might be sufficient to tell
Hello Andrew,
On Wed, 2006-08-09 at 12:25 -0400, Andrew Dunstan wrote:
On August 1st I started work for Anchorage Capital LLC as a Senior
Software Engineer.
Congratulations for your new job.
Cheers,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication,
On Wed, Aug 09, 2006 at 01:20:41PM -0400, Robert Treat wrote:
Both time and varchar take an argument, but they have different typlen
values.
I don't think the docs are wrong here, I think they just don't tell me what I
am looking for.
Oh, you're referring to typmod values. All those are
On 8/9/06, Devrim GUNDUZ [EMAIL PROTECTED] wrote:
Congratulations for your new job.
Seconded!
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830
OK, so what do you want to do?
Oh, sure makes us deliver on our arguments. How very un open source of
you :).. Let me get with andrew and I will post back and actual
solidified idea.
Andrew and I are tabling this until I get back from LinuxWorld. We will
be discussing potential ideas to
On Wed, 2006-08-09 at 12:44 -0400, Tom Lane wrote:
A plugin such as a plpgsql debugger would do this in its _PG_init()
function:
static PLpgSQL_plugin my_plugin = { ... function addresses ... };
PLpgSQL_plugin **var_ptr;
var_ptr = (PLpgSQL_plugin **)
Jeff Davis [EMAIL PROTECTED] writes:
I know this is a trivial question, but is there some kind of lock that
would prevent the PG_fini for the plpgsql debugger from executing after
if(*plugin_ptr) and before ((*plugin_ptr)-function_field)(...)?
Backends are not multi-threaded.
On Mon, Aug 07, 2006 at 10:47:39PM +0200, Lukas Smith wrote:
Constantin Teodorescu wrote:
EXPLAIN VARIANTS SELECT .. (and so on) that will display the
different query plans analyzed by the planner and their estimated time
values , not just the best guess .
assuming that the EXPLAIN
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Image a complex, autogenerated query with looks something like this
select
from t1
join t2 on ...
join t3 on ...
join t4 on ...
...
...
where
big, complicated expression derived from some user input.
This big, complicated
On Wed, Aug 09, 2006 at 01:58:14PM -0400, Jonah H. Harris wrote:
On 8/9/06, Devrim GUNDUZ [EMAIL PROTECTED] wrote:
Congratulations for your new job.
Seconded!
We now have a quorum. ;)
I vote yes!
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778
On Wed, Aug 09, 2006 at 07:33:35AM +, Markus Schiltknecht wrote:
Hello Alfranio,
alfranio correia junior wrote:
Of course not...
It is impossible to build a replication system entirely by only using
triggers...
Hm, I don't think it's impossible, just unpractical. Anyway, if you say
On Wed, Aug 09, 2006 at 02:02:10PM +0200, Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 12:57:39PM +0200, Florian G. Pflug wrote:
Fixing the generic problem is surely the best _if_ there is a fix for
the generic problem at all. But if your where-conditions involves fields
from 10
Hello,
I will be basically unavailable from this Saturday until the 21st of
August. I will be spending a long week in SF at LinuxWorld West.
Please use email to contact me if it is important.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2006 at 02:02:10PM +0200, Martijn van Oosterhout wrote:
Perhaps the way to go would be to allow users to declare columns often
used together and have ANALYSE collect information on correlation which
can be used later...
One thing that
Joshua D. Drake [EMAIL PROTECTED] writes:
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
Tom's comments although valid (as usual :))
Jim C. Nasby wrote:
Been suggested before... the problem is actually doing something useful
with all that data that's collected, as well as how to collect it
without greatly impacting the system.
Identifying the best plan by means of actually running multiple plans and timing
them is useful.
(Not sure how we'd implement that, seeing that ANALYZE currently works
on one table at a time, but it's probably doable --- and it'd fix the
fundamental problem for correlation statistics, which is how not to try
to collect stats about an exponential number of combinations ...)
An exponential
On Wed, Aug 09, 2006 at 03:33:21PM -0400, Joshua Reich wrote:
(Not sure how we'd implement that, seeing that ANALYZE currently works
on one table at a time, but it's probably doable --- and it'd fix the
fundamental problem for correlation statistics, which is how not to try
to collect stats
Ühel kenal päeval, K, 2006-08-09 kell 13:56, kirjutas Jim C. Nasby:
On Wed, Aug 09, 2006 at 07:33:35AM +, Markus Schiltknecht wrote:
Hello Alfranio,
alfranio correia junior wrote:
Of course not...
It is impossible to build a replication system entirely by only using
triggers...
Csaba Nagy wrote:
On Tue, 2006-08-08 at 12:36, Constantin Teodorescu wrote:
We have tried PGStatement#setPrepareThreshold with 1 as the threshold
but it's not a good solution.
Actually is worst. Considering that you have 5 different query plans,
you are selecting approx. random one of them,
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
The other, probably more controversial bit of functionality is that there
needs to be a way to cause a backend to load a PL plugin shared library
without any cooperation from the connected client application.
A similar issue applies to
Bruce Momjian [EMAIL PROTECTED] writes:
! /* WaitForSingleObjectEx() uses milliseconds */
! waittime = timerCommArea.value.it_value.tv_usec
/ 1000 + timerCommArea.value.it_value.tv_sec * 1000;
Seems like this probably ought to round up
I am actually hoping that jabber.postgresql.org would help that in the
long run.
Jabber's ok, but why not go with SILC instead?
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Wed, Aug 09, 2006 at 12:17:44PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Platypus just started failing...
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2006-08-09%2010:05:01
Rest of the farm is looking pretty green, though, so I'm not sure what
to make of it... but
Tom Lane wrote:
I'd turn that around: I think you are arguing for a way to change GUC
settings on-the-fly for a single existing session, without cooperation
from the client.
Ok, implemented that way would solve it (partially)
Something like pg_set_guc(pid int4, varname text, value text)
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
Tom's comments although valid
Andrew Hammond wrote:
I am actually hoping that jabber.postgresql.org would help that in the
long run.
Jabber's ok, but why not go with SILC instead?
Because everything supports jabber, I only know of SILC and gaim that
support SILC :). Also Jabber is pretty much an accepted standard at
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote:
Well, either people post the changes publically or I trust a few people.
I don't trust everyone or the TODO becomes a dumping ground, which I am
afraid might happen with a wiki that anyone can update.
I think that's preventable,
ISTM there are two separate bits of functionality that the core backend
needs to provide in support of PL plugins. The first is that we need a
rendezvous facility whereby two separately-loaded shared libraries can
connect and exchange data (a struct of function pointers for the immediate
[ redirecting to -hackers, as this seems utterly off-topic for -general ]
Bruce Momjian [EMAIL PROTECTED] writes:
Shoaib Mir wrote:
If you remove inline the build process goes fine and if you dont, it first
gives a few warning and in the end quits the build process with a fatal
error.
OK,
1 - 100 of 150 matches
Mail list logo
