On Thu, 4 Sep 2008, Alvaro Herrera [EMAIL PROTECTED] writes:
Cool, thanks. I had a look and you had some of the expected vs.
returned reversed.
I'll happy to fix the reversed ones if you can report them in more
details.
Regards.
--
Sent via pgsql-hackers mailing list
On Thu, 04 Sep 2008, Tom Lane [EMAIL PROTECTED] writes:
This is not ready to go: you've lost the ability to localize most of
the error message strings.
How can I make this available? What's your suggestion?
Also, char *msg should be const char *msg
Done.
if you're going to pass literal
Hello Stephen,
Stephen Frost wrote:
Comments welcome, apologies for it not being ready by 9/1. I'm
planning to continue working on it tomorrow, and throughout September
as opportunity allows (ie: when Josh isn't keeping me busy).
I'm trying to review this patch. I could at least
Simon Riggs wrote:
On Thu, 2008-09-04 at 11:07 +0300, Heikki Linnakangas wrote:
Scenario: The binary tree on a page is corrupt, so that the value of an
upper node is Max(leftchild, rightchild).
Consequence: Searchers will notice the corruption while trying to
traverse down that path, and
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The original proposal
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
contains two parts. First part is implementation of --footprint cmd
line switch which shows you page layout structures footprint. It is
useful for
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
Upps, I'm sorry I'm going to fix it and I will send new version asap.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via
Zdenek Kotala [EMAIL PROTECTED] writes:
Hmm, good question. For example ZFS is platform independent, you can take
disk
from SPARC machine and plug it into x86 and ZFS works perfectly.
FWIW as far as I know *all* filesystems are platform independent. (Of course
now someone is surely going
Gregory Stark napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Hmm, good question. For example ZFS is platform independent, you can take disk
from SPARC machine and plug it into x86 and ZFS works perfectly.
FWIW as far as I know *all* filesystems are platform independent. (Of course
now
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
I'm afraid I still fail to see the usefulness of this. gdb knows how
to deal with structs,
If I correct that GDB knows structure only if you have debug version.
But usually you don't have debug version on production system.
Using gdb
On Fri, 2008-08-08 at 11:47 +0900, Fujii Masao wrote:
On Thu, Aug 7, 2008 at 11:34 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-08-07 at 14:59 +0100, Simon Riggs wrote:
I'll do a patch. Thanks for your input.
Please review attached patch.
Thank you for your patch!
Would
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
snip
AFAICS you can get all the same information from pg_controldata. We have
a pretty good idea of the alignments of all the usual platforms anyway.
If someone says in a bug report that they're running on
Zdenek Kotala wrote:
OK. You convinced me that information could be collected from other
sources.
Great, I'm glad we're in agreement.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hi Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Comments welcome, apologies for it not being ready by 9/1. I'm
planning to continue working on it tomorrow, and throughout September
as opportunity allows (ie: when Josh isn't keeping me busy).
I'm trying to
Hi,
Stephen Frost wrote:
I would suggest you review the updated patch (linked off the wiki page)
here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
That's the patch I've been talking about: file
colprivs_wip.20080902.diff.gz, dated Sept, 2nd.
It includes my comments about
Regarding the patch listed on the commitfest 3 new functions into intarray
and intagg (which I just noticed has a reviewer listed -- doh):
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
I definitely like the int_array_append_aggregate function but I don't see
anything int[]
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several easy patches in the list, so
I can assign them to beginners.
It would be a reasonable rule that all patch
Hi,
Gregory Stark wrote:
Regarding the patch listed on the commitfest 3 new functions into intarray
and intagg (which I just noticed has a reviewer listed -- doh):
..well, just add your name as well, no?
I definitely like the int_array_append_aggregate function but I don't see
anything
Josh Berkus wrote:
Hackers,
We currently have 38 patches pending, and only nine people reviewing them.
At this rate, the September commitfest will take three months.
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several easy
That way, instead of just an appeal to the masses to volunteer for
$NEBULOUS_TASK, we can say something like Please volunteer to review
patches. Doing an initial patch review is easy, please see our guide
link to learn more.
+1. I'll review a patch if you like, but the patch I have in this
On Fri, 2008-09-05 at 12:18 +0100, Simon Riggs wrote:
It would be a reasonable rule that all patch submitters also have to
do patch reviews.
This is almost the only way to be accepted as a contributor to Fedora --
and I like it.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org,
Josh Berkus wrote:
Hackers,
We currently have 38 patches pending, and only nine people reviewing them.
At this rate, the September commitfest will take three months.
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several easy
Markus Wanner [EMAIL PROTECTED] writes:
Hi,
Gregory Stark wrote:
Regarding the patch listed on the commitfest 3 new functions into intarray
and intagg (which I just noticed has a reviewer listed -- doh):
..well, just add your name as well, no?
Yeah, people should feel free to comment on
Hi,
Gregory Stark wrote:
The naming 'bidx' seems a bit weired to me, but otherwise I'm also optimistic
about it.
If we wanted to put that in core
Uh.. ATM it's just a patch against contrib. I don't think 'bidx' needs
to go into core. Otherwise we'd have to move the whole intarr contrib
In the previous discussion there was mentioned that Postgres should
move to the SQL-MED direction in remote connection handling.
SQL-MED specifies that connections should have names and referenced
everywhere using names. PL/Proxy currently does not conform to that
standard - it uses connection
Hi,
Gregory Stark wrote:
I definitely like the int_array_append_aggregate function but I don't see
anything int[] specific about it. We should be able to have a generic
array_union() aggregate which uses the same IsA(fcinfo-context, AggState)
trick to scribble on its state variable. It don't
Volkan YAZICI wrote:
On Thu, 4 Sep 2008, Alvaro Herrera [EMAIL PROTECTED] writes:
Cool, thanks. I had a look and you had some of the expected vs.
returned reversed.
I'll happy to fix the reversed ones if you can report them in more
details.
Please use the patch I posted yesterday, as it
Michelle Caisse wrote:
Thanks, I'll take a look at these issues.
I have committed your patch with some rework that mainly addresses the
concerns also found by Alvaro with regard to cleaning and dependency
handling. I have renamed the out target to coverage-html, to be more in
line with our
Simon Riggs wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
If you are a postgresql hacker at all, or even want to be one, we need your
help reviewing patches! There are several easy patches in the list, so
I can assign them to beginners.
It would be a reasonable
Jorgen Austvik - Sun Norway wrote:
Alvaro Herrera wrote:
In my opinion, the need
for running tests outside the test dir is not very strong (or we would
have heard complaints before), and thus the solution is to remove
--inputdir and --outputdir.
Attached is a patch that removes --inputdir and
I would like to remove the PQpassThroughData and PQresultPassThroughData
functions.The passThrough pointer should be added as a 3rd argument
to the PGEventProc:
typedef int (*PGEventProc)(PGEventId evtId, void *evtInfo,
void *passThrough);
Having a public accessor function for the
Andrew Chernow wrote:
I think it got confused with the instanceData feature, which has nothing
to do with the event system and requires public functions. libpqtypes
happens to use the instanceData functions within its eventproc, but this
is not a requirement.
I forgot to mention that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I don't *want* the rule, I just think we *need* the rule because
otherwise sponsors/managers/etc make business decisions to exclude that
aspect of the software dev process.
How exactly would you even begin to enforce such a rule?
Hi,
Simon Riggs wrote:
On Fri, 2008-09-05 at 09:19 -0400, Andrew Dunstan wrote:
All this would do is to deter people from submitting patches. Hard rules
like this don't work in FOSS communities. I know it's like herding cats,
but persuasion is really our only tool.
+1
I don't *want* the
Hi Bruce and Team,
I have problems to setup SSL for PostgreSQL server. I did all the steps
which described in the documentation (17.8. Secure TCP/IP Connections
with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
me: could not start server. And nothing in the logs (I enabled
Peter Eisentraut [EMAIL PROTECTED] writes:
I have uploaded an example run here:
http://developer.postgresql.org/~petere/coverage/
Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies no tuplesorts are spilling to
On Fri, 2008-09-05 at 16:03 +0200, Markus Wanner wrote:
I don't *want* the rule, I just think we *need* the rule because
otherwise sponsors/managers/etc make business decisions to exclude that
aspect of the software dev process.
I agree that making sponsors/managers/etc aware of that
On 9/4/08, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
We currently have 38 patches pending, and only nine people reviewing them.
At this rate, the September commitfest will take three months.
If you are a postgresql hacker at all, or
Hi,
In PGCon 2008, I proposed synchronous log shipping replication.
Sorry for late posting, but I'd like to start the discussion
about its implementation from now.
http://www.pgcon.org/2008/schedule/track/Horizontal%20Scaling/76.en.html
First of all, I'm not planning to put the prototype which I
Hi,
Simon Riggs wrote:
Such as?
Dunno. Rules for sponsors? It would probably make sense to not only pay
a single developer to create and submit a patch, but instead plan for
paying others to review the code as well.
You might think those arguments exist and work, but I would say
they
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I have uploaded an example run here:
http://developer.postgresql.org/~petere/coverage/
Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies
I was testing a very complex statistical query, with (among other
things) many EXISTS and NOT EXISTS tests against a build of the source
snapshot from 3 September. (The query looks pretty innocent, but
those aren't tables, they're complicated views.) Under 8.3.3 this
query runs successfully, but
On 9/5/08, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 16:03 +0200, Markus Wanner wrote:
I don't *want* the rule, I just think we *need* the rule because
otherwise sponsors/managers/etc make business decisions to exclude that
aspect of the software dev process.
I
On Fri, 2008-09-05 at 17:19 +0300, Marko Kreen wrote:
I think this should be organised with different kinds of reviewer:
The list is correct but too verbose. And it does not attack the core
of the problem. I think the problem is not:
What can/should I do?
but instead:
Can
On Fri, 5 Sep 2008, Alvaro Herrera [EMAIL PROTECTED] writes:
Please use the patch I posted yesterday, as it had all the issues I
found fixed. There were other changes in that patch too.
My bad. Patch is modified with respect to suggestions[1][2] from
Tom. (All 115 tests passed in cvs tip.)
Hi,
In reviewing Volkan Yazici's (sorry for the dots) patch to improve
plpgsql's error messages, I noticed that we have no PO files for plpgsql
at all!
It doesn't seem hard to add; I just had to create a nls.mk file and
things seem ready to go. Obviously, we'll need to add plpgsql to the
Hello again,
I received the following email from a helpful fellow off-list,
pointing out an error in my review:
On Fri, Sep 5, 2008 at 7:03 PM, Ragnar [EMAIL PROTECTED] wrote:
On fös, 2008-09-05 at 15:07 +1000, Brendan Jurd wrote:
Wouldn't this be better written as:
if
Alvaro Herrera wrote:
It doesn't seem hard to add; I just had to create a nls.mk file and
things seem ready to go. Obviously, we'll need to add plpgsql to the
pgtranslation files in pgfoundry.
Actually this is wrong -- since the library is going to run with
postgres text domain, we need to
Alvaro Herrera [EMAIL PROTECTED] writes:
In reviewing Volkan Yazici's (sorry for the dots) patch to improve
plpgsql's error messages, I noticed that we have no PO files for plpgsql
at all!
Ugh. Yeah, we should fix that. Does it actually just work, seeing
that plpgsql is a loadable library?
Volkan YAZICI [EMAIL PROTECTED] writes:
On Thu, 04 Sep 2008, Tom Lane [EMAIL PROTECTED] writes:
This is not ready to go: you've lost the ability to localize most of
the error message strings.
How can I make this available? What's your suggestion?
I think the best way is to use
On 9/5/08, Marko Kreen [EMAIL PROTECTED] wrote:
The list is correct but too verbose. And it does not attack the core
of the problem. I think the problem is not:
What can/should I do?
but instead:
Can I take the responsibility?
To clarify it - that was the problem I faced last
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In reviewing Volkan Yazici's (sorry for the dots) patch to improve
plpgsql's error messages, I noticed that we have no PO files for plpgsql
at all!
Ugh. Yeah, we should fix that. Does it actually just work, seeing
that plpgsql
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually this is wrong -- since the library is going to run with
postgres text domain, we need to add the files to the backend's
nls.mk:
Can't we give it its own text domain? It seems fundamentally wrong
for a plug-in language to require core support
On Fri, 2008-09-05 at 09:19 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
If you are a postgresql hacker at all, or even want to be one, we need
your
help reviewing patches! There are several easy patches in the list, so
So, you'll implement the part of SQL-MED that deals with specifying
remote connections, e.g something like CREATE CONNECTION (no, I
haven't looked at what the syntax actually is)?
Yeah, that sounds like a good idea. We should get that into core, and
modify contrib/dblink to use it as well.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Actually this is wrong -- since the library is going to run with
postgres text domain, we need to add the files to the backend's
nls.mk:
Can't we give it its own text domain? It seems fundamentally wrong
for a plug-in language to
Kevin Grittner [EMAIL PROTECTED] writes:
PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8 chunks);
1615136 used
ExecutorState: 2787288448 total in 364 blocks; 328 free (5 chunks);
2787288120 used
Ouch. We have created a memory leak someplace, but it's hard to tell
Getting this, my cvs copy is as of 1:00PM EST.
[EMAIL PROTECTED] pgsql]# ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time
Alvaro Herrera [EMAIL PROTECTED] writes:
The vices in the error message are not the translator's fault: missing
quotes and plpgsql instead of PL/pgSQL:
It's been message style policy for quite some time to not quote the
output of format_type. I think this is because format_type sometimes
puts
Andrew Chernow wrote:
Getting this, my cvs copy is as of 1:00PM EST.
[EMAIL PROTECTED] pgsql]# ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit
Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8
chunks);
1615136 used
ExecutorState: 2787288448 total in 364 blocks; 328 free (5
chunks);
2787288120 used
Ouch. We have created a memory
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
yeah the code coverage changes broke it - the buildfarm dashboard is
pretty telling:
Yes --- it looks like the configure.in patch is designed to look for
gcov AND lcov (do we really need both?) AND genhtml, and error out
if they're not present,
Kevin Grittner [EMAIL PROTECTED] writes:
The tables and views aren't that hard; finding a way to generate
enough fake data may be a challenge. (I assume that since it took
over a half hour to run out of memory, the volume of data needs to be
sufficient to get there.)
We don't really need 2GB
On Fri, Sep 5, 2008 at 7:37 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
So, you'll implement the part of SQL-MED that deals with specifying remote
connections, e.g something like CREATE CONNECTION (no, I haven't looked at
what the syntax actually is)?
Yeah, that sounds like a good idea.
Why does the planner consider both input variations of each symmetric merge join? The
README says there is not a lot of difference between the two options. When
are there any differences?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Fri, 05 Sep 2008, Tom Lane [EMAIL PROTECTED] writes:
I think the best way is to use
subroutine(..., gettext_noop(special error message here))
at the call sites, and then
errmsg(%s, _(msg))
when throwing the error. gettext_noop() is needed to have the string
be put into
Ryan Bradetich [EMAIL PROTECTED] writes:
Here is my review of the Test citext casts written by David Wheeler:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which was discussed during July
On Sep 5, 2008, at 11:30, Tom Lane wrote:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not search_path
dependent.
Thanks, I'll check that out.
One thing
On Fri, 2008-09-05 at 11:21 -0700, Tom Raney wrote:
Why does the planner consider both input variations of each symmetric merge
join? The README says there is not a lot of difference between the two
options. When are there any differences?
-Tom Raney
Volkan YAZICI wrote:
BTW, Alvaro fixed my string concatenations which yielded in lines
exceeding 80 characters width, but I'd want to ask twice if you're sure
with this. Because, IMHO, PostgreSQL is also famous with the quality and
readability of its source code -- that I'm quite proud of as
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
yeah the code coverage changes broke it - the buildfarm dashboard is
pretty telling:
Yes --- it looks like the configure.in patch is designed to look for
gcov AND lcov (do we really need both?) AND genhtml, and error out
if
Tom Raney [EMAIL PROTECTED] writes:
Why does the planner consider both input variations of each symmetric merge
join? The README says there is not a lot of difference between the two
options. When are there any differences?
The righthand side needs to support mark/restore, the left
On Fri, Sep 5, 2008 at 2:52 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
yeah the code coverage changes broke it - the buildfarm dashboard is
pretty telling:
Yes --- it looks like the configure.in patch is designed to look for
Howdy,
The statistics collector currently dumps the stats file at every 500ms. This
is a major problem if the file becomes large -- occasionally we've been forced
to disable stats collection to cope with it. Another issue is that while the
file is frequently written, it is seldom read.
On Fri, Sep 5, 2008 at 9:54 AM, Andrew Chernow [EMAIL PROTECTED] wrote:
Andrew Chernow wrote:
I think it got confused with the instanceData feature, which has nothing
to do with the event system and requires public functions. libpqtypes
happens to use the instanceData functions within its
Martin Pihlak [EMAIL PROTECTED] writes:
So, as a simple optimization I am proposing that the file should be
only written when some backend requests statistics. This would
significantly reduce the undesired write traffic at the cost of
slightly slower stats access.
How necessary is this given
Tom Lane [EMAIL PROTECTED] wrote:
Also, does the leak still occur if
you just run the query as-is rather than EXPLAIN ANALYZE it?
The machine became unresponsive similar to the early symptoms of the
apparent memory leak cited in this post:
On Fri, 05 Sep 2008 15:23:18 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Martin Pihlak [EMAIL PROTECTED] writes:
So, as a simple optimization I am proposing that the file should be
only written when some backend requests statistics. This would
significantly reduce the undesired write traffic
Andrew Chernow escribió:
/*
* PQmakeEmptyPGresult
* returns a newly allocated, initialized PGresult with given status.
* If conn is not NULL and status indicates an error, the conn's
* errorMessage is copied.
*
* Note this is exported --- you wouldn't think an
Tom Lane wrote:
Martin Pihlak [EMAIL PROTECTED] writes:
So, as a simple optimization I am proposing that the file should be
only written when some backend requests statistics. This would
significantly reduce the undesired write traffic at the cost of
slightly slower stats access.
How
Andrew Chernow escribió:
Alvaro Herrera wrote:
Andrew Chernow escribió:
* PQclear -
* free's the memory associated with a PGresult
*/
I'd add a comment here stating why the event name is not deallocated;
otherwise it just looks like it's being leaked.
The event name is
On Thu, Sep 04, 2008 at 09:54:02PM +0100, Simon Riggs wrote:
* coding review - does it follow standard code guidelines? Are there
portability issues? Will it work on Windows/BSD etc? Are there
sufficient comments?
* code review - does it do what it says, correctly?
Just one thing though, I
Martijn van Oosterhout wrote:
Just one thing though, I picked a random patch and started reading.
However, the commitfest page doesn't link to anywhere that actually
describes *what* the patch is trying to do. Many patches do have the
design and the patch in one page, but some don't.
I
Gregory Stark wrote:
I wonder if it's worth keeping two variants at all really. Why not just make
psql's native table formatting exactly ReST? Is there any part of it that we
don't like as much as our existing tables?
It doubles the number of display lines; a very obvious shortcoming.
--
Alvaro Herrera [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I suppose what happens is the original patch comes with design and
later a newer version is posted with just changes. The commitfest page
points to the latter, losing former in the archive somewhere.
Hmm, IMO this is a
Martin Pihlak escreveu:
I suspected that, but somehow managed to overlook it :( I guess it was
too tempting to use it. I'll start looking for alternatives.
If you can't afford a 500 msec pgstat time, then you need to make it
tunable. Another ideas are (i) turn on/off pgstat per table or
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
I have attached two patches:
- funcdef.diff implements pg_get_functiondef()
- edit.diff implements \ef function in psql based on (1).
I've applied this with some corrections (mostly around proper quoting)
and some outright editorialization:
* the
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
If you can't afford a 500 msec pgstat time, then you need to make it
tunable. Another ideas are (i) turn on/off pgstat per table or database
and (ii) make the pgstat time tunable per table or database. You can use
the reloptions column to
Andriy Bakay escreveu:
I have problems to setup SSL for PostgreSQL server. I did all the steps
which described in the documentation (17.8. Secure TCP/IP Connections
with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
me: could not start server. And nothing in the logs (I
Heikki Linnakangas wrote:
The way my rewritten FSM works at the moment is that pages are handed
out of the FSM in random order, to spread the load of multiple backends
to different pages. That's good for spreading the load, but it occurred
to me while observing a test case that inserts a
On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
* the way you had it set up, the CREATE OR REPLACE FUNCTION command
would be sent to the backend instantaneously upon return from the
editor, with no opportunity for the user to decide he didn't want his
changes applied. This
Updated patch attached, based on comments from Ryan Bradetich and Tom
Lane, and sync'd to latest CVS version.
...Robert
On Mon, Sep 1, 2008 at 9:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Ryan Bradetich [EMAIL PROTECTED] writes:
On Mon, Sep 1, 2008 at 1:00 PM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
... I changed
the exit code to PSQL_CMD_NEWEDIT instead of PSQL_CMD_SEND, which causes
the command to wait in the query buffer.
The principle of least astonishment suggests that \ef
I wrote:
* the psql command seemed to have some ideas about supplying a blank
CREATE OR REPLACE FUNCTION command for a nonexistent function, but this
didn't actually work. In any case it seemed poorly thought out, because
you'd really need to pay some attention to *why* the
94 matches
Mail list logo
