On Tue, 2008-07-08 at 14:51 -0400, Tom Lane wrote:
> I'd still like to take a look.
I was tasked with reviewing this for the current commit fest, although
so far I've just been working on grokking the rest of the GIN code. But
if you'd like to review it instead, that's fine with me.
-Neil
--
On Mon, 2008-06-23 at 03:52 +1000, Thomas Lee wrote:
> * Should it be possible to set this new variable via a command-line
> option ala shared_buffers?
I would say not: most parameters cannot be set by special command-line
parameters, and this one is not important enough to warrant special
treatm
On Fri, 2008-06-13 at 01:49 -0300, Euler Taveira de Oliveira wrote:
> Attached is a small patch to fix some typos in probes.d path.
Applied, thanks.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On Mon, 2008-06-09 at 00:25 -0700, Neil Conway wrote:
> Attached is a patch that makes some minor changes to the text emitted by
> the new "help" command.
Applied to HEAD.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your su
On Tue, 2008-06-10 at 06:42 +0200, Pavel Stehule wrote:
> internally is table functions implemenation identical with SRF.
It's not the internals that I'm concerned about.
> Semantically is far - user's doesn't specify return type (what is from
> PostgreSQL), but specifies return table, what is mo
On Tue, 2008-06-03 at 13:03 +0200, Pavel Stehule wrote:
> this patch add support of table functions syntax like ANSI SQL 2003.
I'm not necessarily opposed to this, but I wonder if we really need
*more* syntax variants for declaring set-returning functions. The
existing patchwork of features is con
Attached is a patch that makes some minor changes to the text emitted by
the new "help" command. Previous output:
postgres=# help
You are using psql, the command-line interface to PostgreSQL.
\? for psql help
\h or \help for SQL help
\g or ";" to execute a query
\
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote:
> Applied with corrections. Most notably, since ALTER SEQUENCE RESTART
> is nontransactional like most other ALTER SEQUENCE operations, I
> rearranged things to try to ensure that foreseeable failures like
> deadlock and lack of permissions would
On Tue, 2008-03-25 at 12:54 -0700, Neil Conway wrote:
> Barring any objections, I'll apply this to HEAD tomorrow.
Applied to HEAD.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Tue, 2008-03-25 at 15:45 -0500, Robert Lor wrote:
> Attached is the doc patch for the recent DTrace changes
Applied, thanks.
-Neil
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
On Tue, 2008-03-18 at 16:19 -0300, Alvaro Herrera wrote:
> The other approach, of course, is to just keep all the code in tqual.c
> and not create a separate module at all. Opinions? I prefer to keep
> them separate, but I'm not wedded to it if there's any strong reason not
> to do it. Also, the
On Sat, 2008-03-22 at 21:35 -0400, Tom Lane wrote:
> After a quick read, looks sane except for one stylistic gripe:
> in exec_stmt_return_next, you added an initialization of tuple = NULL
> in order to remove a couple of lines like
>
> tuple = NULL; /* keep compiler quiet *
On Thu, 2008-02-28 at 16:37 -0800, Neil Conway wrote:
> Attached is a patch that allows an array of Datums + nulls to be
> inserted into a tuplestore without first creating a HeapTuple, per
> recent suggestion on -hackers. This avoids making an unnecessary copy.
Applied to HEA
On Wed, 2008-02-27 at 10:54 -0800, Neil Conway wrote:
> Barring any objections, I'll apply this to HEAD and back branches
> tonight or tomorrow.
Applied to HEAD, REL8_3_STABLE, and REL8_2_STABLE. (I can backpatch
further if anyone feels strongly about
Attached is a patch that allows an array of Datums + nulls to be
inserted into a tuplestore without first creating a HeapTuple, per
recent suggestion on -hackers. This avoids making an unnecessary copy.
There isn't a really analogous optimization to be applied to tuplesort:
it takes either a TTS, a
On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
> Negative refcount does not prove that the SRF itself hasn't
> still got a pointer to the tupdesc.
That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense
On Tue, 2008-02-26 at 12:09 -0800, Neil Conway wrote:
> I'd like to apply this change to back branches reasonably soon, so if
> you have a better way to do the FreeTupleDesc() hack, let me know.
Barring any objections, I'll apply this to HEAD and back branches
tonight or
On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
> You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
> == -1).
Attached is a revised version of this patch. It makes the
FreeTupleDesc() change described above, and fixes a bug: in
SRF_RETURN_DONE(), we need to
On Tue, 2008-02-26 at 03:13 -0500, Tom Lane wrote:
> "It's OK in the built-in SRFs" is disastrously different from "It's OK".
Right, I never said that, I was just commenting on your view that the
predominant use-case for SRFs is returning refcounted tupdescs.
You didn't comment on my proposed sol
On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
> I find this part of the patch to be a seriously bad idea.
> nodeFunctionscan has no right to assume that the function has returned
> an expendable tupdesc; indeed, I would think that the other case is
> more nearly what's expected by the API for
Attached is a patch that fixes the SRF memory leaks I recently reported
on -hackers[1]. The patch creates a distinct memory context for the
SRF's "multi_call_memory_ctx", and then deletes that context when the
SRF finishes. This ensures that any user allocations made in this
context are reclaimed.
On Tue, 2008-01-29 at 13:20 -0500, Tom Lane wrote:
> The reason it was kept was to override the search path --- unqualified
> NUMERIC will always be taken as pg_catalog.numeric even if you have some
> other type "numeric" in front of it.
It should be possible to implement this behavior without req
On Mon, 2008-01-28 at 17:27 +1100, Russell Smith wrote:
> Can somebody explain why it's important to load with
> synchronized_scanning off?
*Loading* with synchronized scanning off is not important (and is not
implemented by the patch).
*Dumping* with synchronized scanning off is necessary to en
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
> I liked the "synchronized_sequential_scans" idea myself.
I think that's a bit too long. How about "synchronized_scans", or
"synchronized_seqscans"?
-Neil
---(end of broadcast)---
TIP 6: ex
On Sun, 2008-01-27 at 12:36 -0500, Tom Lane wrote:
> Both of the above arguments hold water only if we implement compatible
> *semantics*, not merely syntax, so I find them unconvincing at this
> stage.
How are the semantics of the proposed patch incompatible with the SQL
spec or the implementatio
On Sun, 2008-01-27 at 09:17 +, Gregory Stark wrote:
> Tom's feeling at the time was that even though it was providing something from
> the standard, it wasn't actually allowing the user to do anything he couldn't
> before.
I think this feature has value:
(1) This is SQL-standard syntax (and n
Attached is an updated version of Greg Stark's patch to add support for
the non-recursive variant of the SQL99 WITH clause[1]. I haven't looked
at the actual functionality of the patch yet (which is quite trivial) --
I just fixed up bitrot and the like. I also removed support for
RECURSIVE and the
On Mon, 2008-01-14 at 20:55 -0500, Tom Lane wrote:
> Any thoughts whether to apply or not?
Seems like a much more sane approach to me -- +1.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archive
On Tue, 2008-01-08 at 23:08 -0500, Tom Lane wrote:
> Hmm, I think that must be my fault, but I'm not sure how it got by me
> ... I'm usually pretty careful about adding outfuncs support when I add
> a node field. Patch looks good, please apply.
Applied to HEAD.
-Neil
-
Attached is a patch which fixes an oversight in _outAgg(): the
"grpColIdx" and "grpOperators" fields of the Agg struct were not emitted
by _outAgg(). I don't see any good reason to omit this information.
Note that while the "grpOperators" field was added during the 8.3 devel
cycle, the "grpColIdx"
On Mon, 2007-12-10 at 19:12 -0500, Greg Smith wrote:
> I just poked around the
> documentation a bit and I didn't find anything that cleared up which
> options you can pass from a client
http://www.postgresql.org/docs/8.2/static/libpq-envars.html
Which says only "PGOPTIONS sets additional run-t
On Mon, 2007-12-10 at 19:27 +, Dave Page wrote:
> Whilst doing some profiling of the server I found it useful to add an
> option to pgbench to introduce a delay between client connection setup
> and the start of the benchmark itself to allow me time to attach the
> profiler to one of the backen
Applied, thanks.
-Neil
On Fri, 2007-12-07 at 18:48 +1100, FAST PostgreSQL wrote:
> Rgds,
> Arul Shaji
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining col
On Tue, 2007-10-16 at 00:34 -0400, Tom Lane wrote:
> Seems like this needs more comments about what's happening, rather
> than less ...
Fair point.
> Also, it looks to me like the plan node's own resultslot might never be
> assigned to at all, when the subplan returns zero rows. Does this
> corn
Attached is a patch that avoids a needless copy of the result tuple in
nodeMaterial, in the case that we don't have a previously-materialized
tuple to return. We can just return the TTS produced by executing our
child node, rather than returning a copy of it.
I didn't bother pulling the MinimalTup
On Tue, 2007-10-09 at 19:31 +0100, Heikki Linnakangas wrote:
[...]
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes
On Tue, 2007-10-02 at 23:45 +0200, Hannes Eder wrote:
> while rebuilding the entire project I ran across following warning:
>
> .\src\interfaces\libpq\fe-secure.c(593): warning C4101: 'fp' :
> unreferenced local variable
Applied, thanks.
BTW, CC'ing hackers is not necessary for trivial patches
On Fri, 2007-09-28 at 10:02 +0100, Heikki Linnakangas wrote:
> Well, yes it could, but why? Keeping them separate looks slightly more
> readable to me, and the change could break a lot of external modules for
> no good reason.
I agree: it also complicates the common case (calling relation_open()
a
The pgsql-patches mailing list is for submitting modifications to
Postgres, not for asking these sorts of questions.
On Thu, 2007-20-09 at 06:49 +0100, sayali k wrote:
> I am keen in implementing certain additional aggregate
> functions like percentage, standard deviation etc. I
> would like to kn
On Wed, 2007-09-19 at 12:25 +0100, Heikki Linnakangas wrote:
> It would be nice to slip this into 8.3...
+1 from me: the tzcode merge is pretty obviously 8.4 material, but it
would be nice to get this perf tweak in for 8.3.
-Neil
---(end of broadcast)---
On Tue, 2007-09-18 at 18:27 -0700, Neil Conway wrote:
> The builtin corr() aggregate doesn't produce the correct results in some
> circumstances.
Applied to HEAD and REL8_2_STABLE.
-Neil
---(end of broadcast)---
TIP 5: don't fo
The builtin corr() aggregate doesn't produce the correct results in some
circumstances. Per the SQL spec, corr(x, y) is defined as equivalent to
covar_pop(x, y) / (stddev_pop(x) * stddev_pop(y)).
postgres=# create table t1 (x float8, y float8);
CREATE TABLE
postgres=# copy t1 from stdin with csv;
On Thu, 2007-08-09 at 04:08 +1000, Brendan Jurd wrote:
> This patch adds the default location for the DocBook DSSSL stylesheets
> in gentoo's package system to the configure script.
FYI, patches should typically be submitted as context diffs. For the
specific case of configure, you should submit p
On Mon, 2007-08-06 at 14:21 -0700, Neil Conway wrote:
> Attached is a patch that fixes a gradual memory leak in ExecReScanAgg(),
> when the AGG_HASHED strategy is used
Applied to HEAD, and backpatched back to 7.4.
-Neil
---(end of bro
On Mon, 2007-06-08 at 17:48 -0700, Neil Conway wrote:
> Obviously this is just for debugging, but I've found it useful while
> looking at some memory-related issues. Any comments or objections to
> including this in HEAD?
Applied, with an indentation of two spaces per
On Mon, 2007-08-06 at 20:56 -0400, Tom Lane wrote:
> Seems reasonable except I'd vote for less indentation --- the lines are
> too long already. How do you feel about 1 or 2 spaces per level?
Sure, 2 spaces per level is fine with me (1 makes it a bit hard to see
the tree structure, IMHO).
-Neil
Previously, MemoryContextStats() simply emitted a line of output for
each MemoryContext. This is fine, but it makes it difficult to see the
shape of the MemoryContext hierarchy. Attached is a trivial patch to
indent each context by "4 * level" spaces, where "level" is the depth of
the node within t
On Mon, 2007-08-06 at 18:52 -0400, Tom Lane wrote:
> Hmm. Good catch, but I can't help wondering if this is just the tip
> of the iceberg. Should *every* MemoryContextReset be
> MemoryContextResetAndDeleteChildren?
Yeah, the same thought occurred to me. Certainly having the current
behavior as t
Attached is a patch that fixes a gradual memory leak in ExecReScanAgg(),
when the AGG_HASHED strategy is used:
* the aggregation hash table is allocated in a newly-created
sub-context of the agg's aggcontext
* MemoryContextReset() resets the memory allocated in child
contexts,
On Wed, 2007-08-01 at 16:49 -0700, Neil Conway wrote:
> Attached is a patch which fixes a memory leak in tuplestore_end().
Applied to HEAD, and to back branches as far back as 7.4.
-Neil
---(end of broadcast)---
TIP 3: Have you checked
Attached is a patch which fixes a memory leak in tuplestore_end().
Barring any objections, I'll apply this to HEAD and back branches
tomorrow.
-Neil
Index: source/src/backend/utils/sort/tuplestore.c
===
RCS file: /home/neilc/postgres
On Mon, 2007-23-07 at 23:57 -0700, Neil Conway wrote:
> Attached is a patch implementing RETURN QUERY, per earlier discussion
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
h
Attached is a patch implementing RETURN QUERY, per earlier discussion,
and based on a patch from Pavel Stehule. Like RETURN NEXT, RETURN QUERY
doesn't immediately return from the function, allowing RETURN NEXT and
RETURN QUERY to be intermixed in a single function.
Barring any objections, I'll app
On Wed, 2007-07-18 at 17:22 -0400, Alvaro Herrera wrote:
> I wouldn't know how to look for other variadic functions using NULL
> sentinels though.
You would need something with more knowledge of C than "grep" has, at
any rate. Perhaps you could teach sparse to do this analysis, if it
can't do it a
On Wed, 2007-07-18 at 16:59 +0200, Peter Eisentraut wrote:
> It might be good to check the actual definition of NULL in this case,
> however,
> before wondering further.
Well, the existing coding is plainly wrong, regardless of the NULL
implementation used on any given machine (although it will
I've applied the latest version of the patch to HEAD. Thanks for the
patches, Nikhil and Trevor -- we can take a look at improving INCLUDING
CONSTRAINTS for 8.4.
On Mon, 2007-16-07 at 15:50 +0530, NikhilS wrote:
> I agree, since its a LIKE operation and not inheritance as such, how about
> "src_id
On Mon, 2007-07-16 at 13:11 +0200, Stefan Kaltenbrunner wrote:
> I'm slowly working on submitting patches to reduce the amount of (bogus)
> compiler warnings generated by various buildfarm members.
>
> Warthog(the unixware box) generates some 1140 lines of:
>
> UX:cc: WARNING: debugging and opti
On Mon, 2007-16-07 at 14:28 +0530, NikhilS wrote:
> Guess you want to use "src_options" here to be uniform with usages
> elsewhere that you have replaced.
Thanks, good catch.
> You suppose "src_options" is much more readable than "inhreloptions"
> or "inh_idxoptions"? Your call :).
Yeah, I'm not
On Tue, 2007-10-07 at 12:53 +0530, NikhilS wrote:
> Yes, in the CREATE..LIKE case, options will be NULL and in the normal
> CREATE..INDEX case inhreloptions will be NULL. Note that options is a
> List of DefElem entries, whereas inhreloptions is a char pointer.
Hmm, right -- ugly. I'll just stick
On Tue, 2007-05-06 at 14:50 +0530, NikhilS wrote:
> PFA, a patch which provides the "CREATE .. INCLUDING INDEXES"
> functionality. This patch uses the same functionality introduced by
> the earlier patches in this thread albeit for the "INCLUDING INDEXES"
> case.
Attached is a revised version of
On Tue, 2007-07-03 at 09:56 -0400, Tom Lane wrote:
> Neil, according to
> http://developer.postgresql.org/index.php/Todo:PatchStatus
> you have accepted two patches to review --- what is happening with
> those?
Yeah, sorry, forgot about those -- I'll take a look at them tonight.
-Neil
On Mon, 2007-02-07 at 23:13 -0400, Tom Lane wrote:
> Er, was this on the agenda for 8.3?
Well, it seemed fairly harmless to me (no behavioral changes and very
little new code, just syntax), so I didn't see a compelling reason to
delay applying it for a few months. But I can revert it if you'd pref
On Sun, 2007-07-01 at 12:55 -0700, David Fetter wrote:
> Here's a new patch + file. This one allows ALTER [SEQUENCE | VIEW] to
> work only on the respective database objects, but permits the old
> ALTER TABLE syntax.
Applied with some fixes. Thanks for the patch. ALTER VIEW ... SET SCHEMA
might b
On Sun, 2007-01-07 at 12:55 -0700, David Fetter wrote:
> Here's a new patch + file. This one allows ALTER [SEQUENCE | VIEW] to
> work only on the respective database objects, but permits the old
> ALTER TABLE syntax.
How about taking a look at the more thorough documentation updates Tom
suggested
On Thu, 2007-06-28 at 12:08 +0200, Jacob Rief wrote:
> If there is any chance to get this patch applied, I will of course regenerate
> it out of the HEAD-revision of the CVS repository.
I don't see a reason to reject the patch. All the arguments about why
using C++ in the backend is ill-advised ar
On Tue, 2007-26-06 at 15:10 -0700, Neil Conway wrote:
> Attached is a patch that adds information about function volatility to
> the output of psql's "\df+" slash command. I'll apply this to HEAD
> tomorrow, barring any objections.
Applied.
-Neil
---
On Thu, 2007-28-06 at 02:07 -0400, Tom Lane wrote:
> It was already pointed out upthread that wrapping the inclusions in
> extern "C" {...} would fix the identifier part of the problem from
> the user side
No, my point about extern "C" was that I don't think we need to add it
to the Postgres heade
On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
> The patch as given merely renames some random identifiers that happen to
> be keywords in some non-C language (thereby breaking not only a lot of
> core backend code, which we can fix, but who knows what other
> user-written extensions that we ca
On Wed, 2007-06-27 at 20:51 -0400, Andrew Dunstan wrote:
> He's used the usual "#ifdef __cplusplus" wrapper - isn't that good enough?
Well, there's nothing wrong with it per se, I'm just wondering (1) what
the proper set of headers to add it to is -- the patch just does a
handful (2) whether we ne
On Thu, 2007-06-28 at 00:43 +0200, Jacob Rief wrote:
> But the C++-compiler rejects to compile legal C code,
> because some of the included Postgres-headers, ie. postgres.h,
> executor/spi.h, commands/trigger.h, fmgr.h use a few C++ keywords to
> defined a some struct members and function arguments
On Wed, 2007-27-06 at 00:16 -0400, Alvaro Herrera wrote:
> +1 as well but I'm wondering whether the output is too wide.
Well, the output of \df+ is already likely to be wider than 72
characters, so I'm not sure the patch would really make the situation
materially worse ("\df+ nextval" is 118 chara
On Tue, 2007-26-06 at 20:29 -0700, Joshua D. Drake wrote:
> Tom Lane wrote:
> > +1, but are there not any documentation changes to make?
Sure, I'll update the psql ref page.
> Well here is a question (just because I haven't seen it) is there a list
> of functions and their volatility in the docs
Attached is a patch that adds information about function volatility to
the output of psql's "\df+" slash command. I'll apply this to HEAD
tomorrow, barring any objections.
-Neil
Index: src/bin/psql/describe.c
===
RCS file: /home/neil
On Thu, 2007-21-06 at 22:09 -0400, Tom Lane wrote:
> Seems reasonable to back-patch into 8.2 too...
Okay, done.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Wed, 2007-06-20 at 15:51 -0700, Neil Conway wrote:
> Attached is a patch that fixes this, by calling fflush() on the psql
> output stream after each call to printQuery() in ExecQueryUsingCursor().
Applied to HEAD.
-Neil
---(end of bro
psql's "FETCH_COUNT" feature is useful for incrementally displaying the
results of a long-running query. However, psql fails to flush its output
stream as new rows from the partial result set are produced, which means
that partial query results may not be visible to the client until the
stdio buffe
On Mon, 2007-21-05 at 12:23 +0530, NikhilS wrote:
> I had spent some time on this earlier so decided to complete and send
> the patch to you for review. This patch supports copying of
> expressions, predicates, opclass, amorder, reloptions etc. The test
> case also contains some more additions with
On Wed, 2007-30-05 at 21:23 +0200, Peter Eisentraut wrote:
> I'm not sure what your rationale was for creating lower-case words
> instead of upper case, except for it looks nicer. Is there a technical
> reason?
There's no real technical reason: the standard says upper-case, but PG's
general phi
On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote:
> More generally, I'm really hoping to get rid of bespoke text<->whatever
> cast functions in favor of using datatypes' I/O functions. To what
> extent can we make the boolean I/O functions serve for this? It seems
> relatively painless on the in
On Mon, 2007-28-05 at 13:54 -0400, Neil Conway wrote:
> Okay, attached is a patch that does this. To summarize, the changes are:
>
>* add tmask bits for msec, usec (I reordered the #defines to keep
> them logically contiguous, but AFAICS this isn't necessary)
>* i
On Mon, 2007-28-05 at 15:05 -0400, Tom Lane wrote:
> Right. I guess you misunderstood me: I was arguing for rejecting double
> occurrences of the same unit name, but not occurrences of different unit
> names that we happen to map into the same interval field internally.
Makes sense to me. I'll se
On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote:
> More generally, I'm really hoping to get rid of bespoke text<->whatever
> cast functions in favor of using datatypes' I/O functions.
I don't object, but I'm curious: is there a benefit to this other than
brevity of implementation? ISTM the spec
I noticed that SQL:2003 specifies explicit casts between "boolean" and
the character string types. Attached is a patch that implements them,
and adds some simple regression tests.
A few points worth noting:
(1) The SQL spec requires that text::boolean trim leading and trailing
whitespace from the
On Mon, 2007-28-05 at 10:50 -0400, Tom Lane wrote:
> I'd argue that it's an oversight. I don't have a problem with adding up
> the values of units that really translate to the same thing (eg,
> '1 week 1 day' -> '8 days'), but I think '1 second 2 second' should
> be rejected because it's almost ce
neilc=# select '1 day 1 millisecond'::interval;
interval
1 day 00:00:00.001
(1 row)
neilc=# select '1 millisecond'::interval;
ERROR: invalid input syntax for type interval: "1 millisecond"
neilc=# select '0.001 seconds'::interval;
interval
--
00
On Mon, 2007-14-05 at 22:58 -0400, Neil Conway wrote:
> Has a revised version of this patch been submitted?
In the absence of a revised patch, I can finish the feature myself, but
I won't get the free cycles until after PGCon. I can commit to getting
it done before the end of May, or els
On Tue, 2007-15-05 at 09:07 -0400, Alvaro Herrera wrote:
> I agree, the note should be added there (but it should be a short one
> and refer the reader someplace else for more complete details).
I've applied the attached patch to HEAD and REL8_2_STABLE.
-Neil
Index: doc/src/sgml/config.sgml
On Fri, 2007-27-04 at 18:59 -0400, Neil Conway wrote:
> This patch needs more work.
Has a revised version of this patch been submitted?
-Neil
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Mon, 2007-14-05 at 16:22 -0400, Bruce Momjian wrote:
> I agree with Tom. I don't think the current behavior is a major issue
> for users for it to be mentioned more than it already is
Are you really suggesting that we shouldn't modify config.sgml to note
that "autovacuum = off" does not actual
On Sun, 2007-13-05 at 18:58 -0700, David Fetter wrote:
> cvs diff works just great until you want to add or remove a file
> without write permissions to the CVS repository, i.e. when you've
> checked out as anonymous.
Personally, I usually work against a checkout from a local mirror of the
CVS rep
On Sun, 2007-13-05 at 22:06 -0400, Tom Lane wrote:
> This fact is already documented in at least three places; do we really
> need two more?
I think we need to at least modify the documentation for the autovacuum
GUC parameter, which currently states only that it "controls whether the
server shoul
On Sun, 2007-06-05 at 21:30 -0400, Tom Lane wrote:
> It'd be a good idea if you repeat the previous number-of-collisions
> experiment on this code.
I repeated the same experiment, and got essentially the same number of
collisions (829 collisions on ~2 million randomly generated numerics,
with 273
On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
> As suggested in the TODO list (and as I need the functionality
> myself), I have implemented the current_query interface to
> debug_query_string.
Comments:
* docs need a bit more detail (they should emphasize that it is the
current query
On Sun, 2007-06-05 at 21:30 -0400, Tom Lane wrote:
> You can do it always if you simply decrement the weight for each leading
> zero removed.
On reflection, the patch as given was wrong anyway: if two Numerics are
identical except for the presence of leading zeroes, we can't consider
the weight wh
On Thu, 2007-03-05 at 23:57 -0400, Tom Lane wrote:
> Hm, but apply hash_any() to the remaining digits? That might work, if
> you are careful about how you factor the weight into it (or just not try
> to use the weight in the hash).
Attached is a patch that implements this idea. Since leading or t
On Sun, 2007-06-05 at 00:20 -0400, Andrew Dunstan wrote:
> I object to the short notice. I think we need to give people a chance to
> adjust their configs
Sure, I can wait a few days (although if we're going to do this for 8.3,
we should do it promptly). On reflection, it might actually be wiser
On Sat, 2007-05-05 at 22:49 -0500, Michael Glaesemann wrote:
> Would it make more sense to have phrase it in the positive sense?
> i.e., --enable-floating-point-datetimes? I guess that's a bit longer,
> but it says what you're doing, rather than what you're *not* doing.
I think the primary rea
On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
> I'm still not very comfortable with that. You're proposing to add a
> pretty obvious failure mechanism --- any numeric-returning function
> that failed to "normalize" its output would now create a subtle,
> hard-to-find bug.
What about teaching
On Wed, 2007-02-05 at 17:09 +0530, NikhilS wrote:
> Since this patch is only supposed to copy unique/primary indexes, I
> dont think we will ever have predicates associated to such indexes?
Nope:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create unique index t1_a_idx on t1 ((a +
On Fri, 2007-04-20 at 09:46 +0200, Pavel Stehule wrote:
> I refreshed Magnus's patch
> http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
> februar.
Applied, thanks.
BTW, I notice that the documentation for PL/PgSQL's FETCH command states
that only the direction variants tha
1 - 100 of 1000 matches
Mail list logo
