On Mon, Aug 17, 2015 at 7:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hi Neil! Long time no see.
Likewise :)
Attached is a one-liner to double the size of the table when space is
exhausted.
I think this could use a comment, but otherwise seems OK.
Attached is a revised patch with a comment.
spi_printtup() has the following code (spi.c:1798):
if (tuptable-free == 0)
{
tuptable-free = 256;
tuptable-alloced += tuptable-free;
tuptable-vals = (HeapTuple *) repalloc(tuptable-vals,
tuptable-alloced * sizeof(HeapTuple));
2012/3/19 Qi Huang huangq...@hotmail.com:
I actually tried to find out, personally...not sure if I was searching
wrongly, but searching for TABLESAMPLE did not yield a cornucopia of
useful conversations at the right time in history (~2007), even when
the search is given a broad date-horizon
I tried $subject recently, and noticed some minor issues:
(1) Two warnings that suggest bugs; in src/backend/utils/adt,
datetime.c:3101:27: warning: use of logical || with constant operand;
switch to bitwise | or remove constant
And similarly for src/interfaces/ecpg/pgtypeslib/interval.c.
On Sun, Aug 1, 2010 at 7:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I tried to duplicate your results using what I believe to be the latest
version of clang,
I'm using SVN tip of llvm+clang from ~one week ago.
(2) clang doesn't support (or require) -no-cpp-precomp, which
src/template/darwin
On Sun, Aug 1, 2010 at 9:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering about the bleats I saw for -fwrapv though.
configure already is set up to install that switch only conditionally:
# Disable optimizations that assume no overflow; needed for gcc 4.3+
On Tue, May 5, 2009 at 8:50 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
While discussing potential changes to PostgreSQL documentation of
transaction isolation levels, Emmanuel Cecchet pointed out an
intriguing new paper[1] on a new algorithm to provide true
serializable behavior in
On Thu, Oct 16, 2008 at 5:26 AM, Tom Lane [EMAIL PROTECTED] wrote:
It would probably be cleaner to take that logic out of build_hash_table
altogether, and put it in a separate function to be called by
ExecInitAgg.
Yeah, I considered that -- makes sense. Attached is the patch I
applied to HEAD,
I noticed a minor leak in the per-query context when ExecReScanAgg()
is called for a hashed aggregate. During rescan, build_hash_table() is
called to create a new empty hash table in the aggcontext. However,
build_hash_table() also constructs the hash_needed column list in
the per-query context,
On Tue, Sep 2, 2008 at 9:35 AM, David Fetter [EMAIL PROTECTED] wrote:
Any chance we can buy a few copies of the official one for use on the
project?
AFAIK there is no significant difference between the official
standard and the draft version available online, so I don't see the
point.
Neil
--
On Mon, Sep 1, 2008 at 9:35 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
+1. I've been using a variation on this theme (it returns the type
OID, not a text value) for a couple of years.
Returning regtype seems like the natural choice.
-Neil
--
Sent via pgsql-hackers mailing list
On Wed, 2008-07-09 at 10:58 -0700, Josh Berkus wrote:
Have received exactly zero feedback on the question of whether I should
be assigning reviewers to WIP patches or not.
I suppose it depends on what exactly WIP means, but I should think
that if work is still in progress, the patch is not
On Wed, 2008-07-09 at 10:59 -0700, Josh Berkus wrote:
This commitfest we have a number of non-committer reviewers doing
reviewing. When they're done with their review, how do they handoff
to a committer for final check and commit?
One approach would be to assign a committer to each patch,
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 Wed, 2008-07-09 at 14:38 -0400, Alvaro Herrera wrote:
But patches in progress still need comments from reviewers.
Certainly, but should this be done as part of the commit fest process?
Commenting on the future direction that an in-development patch ought to
take sounds more like a task for
On Wed, 2008-07-09 at 11:50 -0700, Josh Berkus wrote:
So one thing I was thinking of is:
1) change status to ready for committer
2) post message to -hackers detailing the review and calling for a
committer to check the patch
3) a committer picks it up
Sure -- or else have we could have a
On Wed, 2008-06-11 at 19:24 -0400, Bruce Momjian wrote:
Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
wondering if we should be automatically doing quiet while .psqlrc is
processed.
There is some precedent for not emitting the messages: most Unix tools
don't echo the
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 be
On Fri, 2008-05-02 at 23:22 +0200, Jan Urbański wrote:
While looking around vacuum.h (for my GSoC project) I found:
typedef struct VacAttrStats *VacAttrStatsP;
and then throughout the code sometimes VacAttrStats *foo is used and
sometimes VacAttrStatsP bar is used.
Personally I think we
On Tue, 2008-04-08 at 15:26 -0500, Decibel! wrote:
My idea to avoid this situation is to add an option to COPY that
tells it not to throw an error until it runs out of input data.
An alternative would be to have the client continue reading (and
discarding) COPY input until the
On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote:
I'm still waiting to see an example of where you say this patch is even
marginally useful.
It's not hard to think of one:
SELECT * FROM remote_table() WHERE x = 5;
Applying the predicate on the remote database (pushing the predicate
On Sat, 2008-03-22 at 21:24 -0400, Tom Lane wrote:
Oh, wait, that's just a -patches entry; it doesn't look like Neil
ever committed it. Neil, how come?
Sorry, slipped through the cracks -- I've now committed the patch.
-Neil
--
Sent via pgsql-hackers mailing list
On Tue, 2008-03-25 at 17:26 -0300, Alvaro Herrera wrote:
There is one hole here: contention on ProcArrayLock. Basically, for
simple transactions we will need to update MyProc after every command.
If we're just updating MyProc-xmin, we only need to acquire
ProcArrayLock in shared mode, right?
On Thu, 2008-03-20 at 20:05 -0300, Alvaro Herrera wrote:
Neil, you're on the loop for changing the default in configure. Want to
do the honors?
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
-Neil
--
Sent via pgsql-hackers mailing list
On Tue, 2008-03-11 at 20:56 +0800, longlong wrote:
This would be a nice feature. Right now there are often applications
where there is a data loading or staging table that ends up being
merged with a larger table after some cleanup. Moving that data from
the preperation area into the final
On Tue, 2008-03-11 at 15:18 -0700, Neil Conway wrote:
Note also that pg_bulkload currently does something analogous to this
outside of the DBMS proper:
http://pgbulkload.projects.postgresql.org/
Sorry, wrong project. I mean pgloader:
http://pgfoundry.org/projects/pgloader/
-Neil
On Wed, 2008-02-27 at 15:24 +0100, Pavel Stehule wrote:
I thing RETURN QUERY is successful idea. It should be completed with
support of dynamic SQL.
Yeah, I can see that being useful.
RETURN EXECUTE sqlstring [USING];
What is the USING clause for?
-Neil
---(end
I notice that several of the call sites of tuplestore_puttuple() start
with arrays of datums and nulls, call heap_form_tuple(), and then switch
into the tstore's context and call tuplestore_puttuple(), which
deep-copies the HeapTuple into the tstore. ISTM it would be faster and
simpler to provide
On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
As a result, I have a few questions about the timestamp code. In what
instances is the floating point timestamp recommended?
One circumstance is when there isn't a native int64 type available. The
floating point datetime code is the
On Tue, 2008-02-26 at 14:55 -0500, Tom Lane wrote:
Anyway I think they both have their place.
I think it is very fragile to have the semantics of a builtin datatype
change depending on a configure option. It makes it difficult to write
applications that depend on the unique properties of
On Tue, 2008-02-26 at 11:33 -0800, Josh Berkus wrote:
We need two (or more) PostgreSQL hackers to volunteer to regularly check the
Coverity reports and either fix/forward the bugs found, or (more often) mark
them as non-bugs in the Coverity system.
I take a look at this periodically.
On Tue, 2008-02-26 at 14:57 -0800, Joshua D. Drake wrote:
Would there be a way to script the responses to flag us for things
that are important?
I think you need human verification / analysis, which isn't an easy
thing to script.
-Neil
---(end of
Consider this test case:
create table baz (a int, b int);
insert into baz (select 1, generate_series(1, 300));
select baz.*, (select 1 from generate_series(1, 1) g(a)
where g.a baz.b)
from baz;
The final query consumes ~800 MB of memory on my
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
Given your point (2), is this worth fixing by itself?
Right, probably not.
Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
-Neil
---(end of broadcast)---
TIP 7: You can help
On Tue, 2008-01-29 at 13:06 +0100, Peter Eisentraut wrote:
The ORDER BY clause would also used in XMLAGG, so we should try to parse this
in a generalized way.
Yeah, that should be doable. We could go further and expose ORDER BY to
CREATE AGGREGATE, so that users could write aggregates that are
When building with MSVC 2005 (Express) and the Longhorn Platform SDK
(version 6.0a), it seems that IPPROTO_IPV6 is only defined when
_WIN32_WINNT = 0x0501. This results in a compiler error when trying to
build pqcomm.c (line 389). According to [1], building for Windows 2000
(that is, _WIN32_WINNT
I recently noticed that SQL:200n[1] defines a new aggregate function,
array_agg(). The relevant portions of the spec are:
p. 66: If ARRAY_AGG is specified, then an array value with one element
formed from the value expression evaluated for each row that
qualifies.
p. 556: array aggregate
On Tue, 2008-01-22 at 20:53 +0100, Pavel Stehule wrote:
And there is most important question about data visibility - is
autonomous transaction independent on main transaction (isolation)?
From looking at how Oracle does them, autonomous transactions are
completely independent of the transaction
On Wed, 2008-01-23 at 09:30 +, Gregory Stark wrote:
I think the hard part would be error handling. You have to be able to catch
any errors and resume the outer transaction.
I agree that you'd need to do this, but I don't follow why it would be
particularly difficult. You essentially have a
On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
Maybe someone could enhance this concept to include it with the core
database to provide autonomous transactions.
I agree that autonomous transactions would be useful, but doing them via
dblink is a kludge. If we're going to include
In CVS HEAD, why does exec_simple_query() pass an empty cursorOptions to
pg_plan_queries() at postgres.c:903? If we're planning DECLARE CURSOR,
ISTM we ought to be passing down the DECLARE CURSOR's cursorOptions.
-Neil
---(end of broadcast)---
On Tue, 2007-12-11 at 19:11 -0500, Greg Smith wrote:
I'm curious what you feel is missing that pgloader doesn't fill that
requirement: http://pgfoundry.org/projects/pgloader/
For complicated ETL, I agree that using an external tool makes the most
sense. But I think there is still merit in
On Fri, 2007-12-14 at 14:48 +0200, Hannu Krosing wrote:
How did you do it ?
Did you enchance COPY command or was it something completely new ?
By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
to drop (and log) rows that contain malformed data. That is, rows with
too many
On Fri, 2007-12-14 at 18:22 -0500, Tom Lane wrote:
If we could somehow only do a subtransaction per failure, things would
be much better, but I don't see how.
One approach would be to essentially implement the pg_bulkloader
approach inside the backend. That is, begin by doing a subtransaction
On Fri, 2007-12-14 at 15:47 +, Gregory Stark wrote:
I've wanted for a long time to have EXPLAIN ANALYZE output per-node I/O usage.
This would be especially useful if we could distinguish hardware versus
logical I/O though. And I always thought that would be very hard.
My thought in the
On Thu, 2007-12-13 at 22:06 -0500, Tom Lane wrote:
I guess that on purely philosophical grounds, it's not an unreasonable
behavior. For example, LIMIT n means output at most n tuples,
not output exactly n tuples. So when it outputs no tuples in the face
of a negative limit, it's meeting its
On Tue, 2007-12-11 at 10:53 -0800, Josh Berkus wrote:
Just so you don't lose sight of it, one of the biggest VLDB features we're
missing is fault-tolerant bulk load.
I actually had to cook up a version of this for Truviso recently. I'll
take a look at submitting a cleaned-up implementation for
On Wed, 2007-11-28 at 09:38 -0800, Trevor Talbot wrote:
PostgreSQL's problem is that it (and AFAICT POSIX) conflates encoding
with locale, when the two are entirely separate concepts.
In what way does PostgreSQL conflate encoding with locale?
-Neil
---(end of
On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote:
I expect these cleanups to continue for at least another week or two.
Once they slow we will schedule RC1.
So are there no plans for an additional beta? Given the recent addition
of changes like
On Wed, 2007-11-07 at 11:38 +0900, Josh Berkus wrote:
./configure --with-libxml does not accept a location argument. This
makes it impossible to configure 8.3 with LibXML on the Mac, because I
can't upgrade the main libxml without breaking something, and
./configure doesn't let me specify
I noticed that processCancelRequest() emits a log message at DEBUG2 when
it receives a cancel request with a bad key or for a non-existent PID.
For example,
ereport(DEBUG2,
(errmsg_internal(bad key in cancel request for process %d,
backendPID)));
I think this ought
On Sun, 2007-11-04 at 11:06 -0500, Tom Lane wrote:
No, if it's intended for the log it should be LOG. Your other proposals
are actually *less* likely to get to where the DBA could see them.
Good point. I suggested WARNING because that suggests that something is
awry, whereas LOG is used for
On Mon, 2007-10-22 at 15:40 +0200, Cédric Villemain wrote:
Does postgresql use posix_fallocate ?
No.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
On Tue, 2007-10-16 at 11:24 +1000, Brendan Jurd wrote:
Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?
See prior discussion:
http://archives.postgresql.org/pgsql-bugs/2004-10/msg1.php
It would be easy enough to have EXECUTE
On Thu, 2007-10-11 at 16:04 -0400, Bruce Momjian wrote:
I have added the following introductory paragraph to the release notes:
This release represents a major leap forward by adding significant new
functionality and performance enhancements to
productnamePostgreSQL/. Many
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
I think this almost says it all. My particular gripe about this whole
thing is that there are other features that are not too intrusive (or
appear so anyway) that are easily more useful that are not being
considered at all. Namely,
On Mon, 2007-10-08 at 16:50 -0400, Alvaro Herrera wrote:
palloc uses malloc underneath. My thought is to replace that with
sbrk, mmap or something like that. Not very portable though, a lot of
work, and most likely not nearly enough benefits.
Yeah, I agree this isn't likely to be a win in
On Thu, 2007-10-04 at 09:04 +0200, Guillaume Smet wrote:
There is a typo in the contrib part:
# Add GIN support for hstore (Guillaume Smet, Teodor)
# Add GIN support for pg_trgm (Guillaume Smet, Teodor0
s/Teodor0/Teodor)/
And I didn't participate to the GIN support of hstore, I just added
On Thu, 2007-10-04 at 15:50 +0100, Simon Riggs wrote:
On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
Somebody who wants the
above behavior can send ROLLBACK; DISCARD ALL.
...which generates an ERROR if no transaction is in progress and fills
the log needlessly.
Well, it's a WARNING,
On Tue, 2007-25-09 at 22:15 -0400, Tom Lane wrote:
I believe that (1) is now committed (renamed to RETURN QUERY),
but what is the status of (2)?
Personally I won't cry if this doesn't make it into 8.3, particularly
since there was some disagreement about it. But if you intend to make
it
On Thu, 2007-09-20 at 16:08 +0300, Martin Pihlak wrote:
The GUC variable stats_function_level now takes 3 values: on, off and all.
That seems a confusing set of values. Perhaps off, pl, and all
would be clearer?
I'm curious if you've measured the performance overhead of enabling this
On Mon, 2007-09-10 at 21:04 -0400, Tom Lane wrote:
I have just noticed that a column txn_start has appeared in
pg_stat_activity since 8.2. It's a good idea, but who chose the name?
Me.
I'm inclined to rename it to xact_start, which is an abbreviation
that we *do* use in the code, and in
On Sun, 2007-02-09 at 13:04 -0500, Kenneth Marshall wrote:
2. Evaluate the performance of different hash index implementations
and/or changes to the current implementation. My current plan is
to keep the implementation as simple as possible and still provide
the desired performance.
On Wed, 2007-08-29 at 13:53 -0400, Tom Lane wrote:
Why wouldn't we just remove the README files altogether? I can't
see maintaining duplicate sets of documentation.
I agree that duplication is bad, but I think README files in the
individual contrib directories is useful and worth keeping: if
On Wed, 2007-08-29 at 22:41 +0200, Florian G. Pflug wrote:
Or are platforms with INT64_IS_BUSTED no longer supported,
and are all those #ifdefs only legacy code?
Personally I think we should head in that direction: if we enable
integer datetimes by default in 8.4 (per earlier discussion), such
On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote:
In the longer run I want to make the whole system more data driven, so
that it's comparatively easy for someone to add stuff.
I don't mean to hijack your thread, but I wonder if maintaining two
separate build systems is the best approach
On Sat, 2007-04-08 at 09:26 -0400, Andrew Dunstan wrote:
So what are *you* doing about it? This is open source, where if you want
it and it's not there you make it. Otherwise you're just one more
whinger wanting something for nothing.
I don't agree with this attitude at all: we should be
To review, Pavel Stehule submitted a proposal and patch to add support
for table functions a few months back:
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php
http://archives.postgresql.org/pgsql-patches/2007-05/msg00054.php
Pavel proposed two basically independent features:
On Fri, 2007-07-13 at 14:11 +0300, Martin Pihlak wrote:
I'm working on a patch to extend the stats collector to handle stored
procedure
statistics (call counts, duration etc). The goal is to make this information
visible via pg_stat functions/views. The collection would be controllable via
On Fri, 2007-07-13 at 15:38 -0500, Jim C. Nasby wrote:
According to http://developer.postgresql.org/index.php/Feature_Matrix,
8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
http://www.postgresql.org/docs/8.2/static/sql-createindex.html
See the CONCURRENTLY clause.
On Mon, 2007-28-05 at 15:24 -0400, Tom Lane wrote:
readline has much more functionality
Fair enough, that's probably a good enough reason to leave things as
they are for now.
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase your
On Tue, 2007-29-05 at 16:01 -0400, Tom Lane wrote:
(I imagine someday we'll get around to allowing int8 to be pass-by-value
on 64-bit platforms.)
This could really be a significant performance win: I'm planning to take
a look at doing it for 8.4.
-Neil
---(end of
If both libedit and libreadline are available, we currently default to
linking against libreadline, unless the --with-libedit-preferred
configure option is used. Why do we default to preferring GNU readline
over libedit?
libedit is clearly preferable for license reasons. You could make the
On Fri, 2007-18-05 at 11:47 -0500, Jim C. Nasby wrote:
Assuming the concurrent psql stuff gets in, do you still see a use for
this?
I think concurrent psql (and/or async libpq) is the right way to handle
this sort of requirement. DROP INDEX NOWAIT is hacky, and would be
difficult (impossible?)
On Fri, 2007-18-05 at 13:29 -0400, Alvaro Herrera wrote:
I think what Joshua really wants is an equivalent of this
That's not what his original email asked for, at any rate.
start:
BEGIN;
LOCK TABLE foo IN ACCESS EXCLUSIVE MODE NOWAIT;
-- if fail, rollback and go to start
On Fri, 2007-18-05 at 21:59 -0400, Tom Lane wrote:
I kinda think this is emphasizing the wrong end of the process.
I don't disagree, but I think a tool like this would still be enormously
helpful (to me, at any rate). While there's more to the process of
feature development than just mailing
On Wed, 2007-16-05 at 11:25 -0400, Bruce Momjian wrote:
Are we agreed to wait for 8.4 for this?
Yes.
-Neil
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote:
Either way, we are taking the hit, it is just a matter of where. IMO it
would be better to have the information in the database where it makes
sense, than pushing out to a log
If performance monitoring information is provided as a
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararraysel(), which in turn estimates the selectivity of
*each* array
On Wed, 2007-09-05 at 01:07 +0530, Raja Agrawal wrote:
We are using the following piece of code for updating a list
synchronously i.e. no two threads would update the list at a time.
Do you mean threads or processes?
Is the following way of using semaphores not correct in the postgres
On Sun, 2007-06-05 at 13:09 -0400, Bruce Momjian wrote:
Also, are we sure we can load a dump that used the float format? What
happens for a date out of int8 range?
AFAIK we should always be able to reload timestamp values that are in
the legal range for an int8-based timestamp. For values
What is the reasoning behind having two different implementations of the
datetime types, with slightly different behavior? Do we intend to keep
supporting both FP- and integer-based datetimes indefinitely?
Clearly, there are some costs associated with maintaining two different
implementations:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
We've so far managed to avoid having any hard dependency on a working
int64 type, but this would certainly be one. I don't really think the
code-size-reduction argument is strong enough to justify that.
What benefit do we get from avoiding
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
-Neil
---(end of broadcast)---
TIP 7: You can help support the
On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
(1) I believe the reasoning for Tom's earlier change was not to reduce
the I/O between the backend and the pgstat process [...]
Tom, any comments on this? Your change introduced an undocumented
regression into 8.2. I think you're on the hook
Pavel, my apologies for not getting back to you sooner.
On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
example: I have table with attr. cust_id, and I want to use parametrized
view (table function) where I want to have attr cust_id on output.
Hmm, I see your point. I'm personally
On Fri, 2007-04-27 at 07:36 +0200, Pavel Stehule wrote:
it's true. There is bug. I'll send actualised version tomorrow.
No need: I fixed the bug and applied the patch. Thanks for the patch.
-Neil
---(end of broadcast)---
TIP 6: explain analyze
On Tue, 2007-04-24 at 18:04 +0300, Marko Kreen wrote:
Attached patch addresses all 3 comments. As it will be
top-level command, I put code into commands/discard.c
Applied with some minor tweaks -- thanks for the patch. I didn't bother
moving the regression tests out of guc.sql, although they
On Tue, 2007-04-24 at 17:38 -0400, Neil Conway wrote:
which included other modifications to reduce the pgstat I/O volume in
8.1. I don't think this particular change was wise
I looked into this a bit further:
(1) I believe the reasoning for Tom's earlier change was not to reduce
the I/O
I haven't read the rest of the thread yet, but is this hunk not buggy?
yylex() is side-effecting, so the two calls to yylex() do not do what
the comment suggests.
*** 2083,2091
check_FROM = false;
}
! /* check FROM keyword after direction's specification */
!
On Thu, 2007-04-12 at 14:56 -0700, Andrew Hammond wrote:
I've written the following function definitions to extend
generate_series to support some temporal types (timestamptz, date and
time). Please include them if there's sufficient perceived need or
value.
I could see these being useful,
On Mon, 2007-04-23 at 17:48 -0400, Tom Lane wrote:
I think we've got something isomorphic to that in the patch queue
already --- take a look at Pavel's table function patch. It's in
need of cleanup but I think it will make it in.
Interesting -- I missed that patch, but it seems like a better
On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
It is RETURN TABLE(SQL) via ANSI SQL 2003
I think there are two basically orthogonal features in the patch: the
RETURNS TABLE addition to CREATE FUNCTION, and the RETURN TABLE
statement in PL/PgSQL. The former is specified by the SQL
[ CC'ing -hackers ]
On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
This patch adds a sentence on monitoring.sgml explaining that
stats_row_level needs to be enabled if user wants to get last
vacuum/analyze execution time.
This behavior was introduced in r1.120 of
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still the logical place for the implementation of DISCARD?
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
-Neil
---(end
In a PL/PgSQL set-returning function, returning the result set of a
query requires a FOR loop and repeated invocations of the RETURN NEXT
statement:
FOR x in SELECT ... LOOP
RETURN NEXT x;
END LOOP;
This works, but it seems overly verbose. It occurred to me that we could
easily
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
I'm really still opposed to the entire concept. You're proposing to put
a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a lot of code: the patch just adds a few
syscache lookups, wrapped in a
On Sat, 2007-04-21 at 02:38 -0400, Tom Lane wrote:
Maybe so, but you're going to be writing quite a lot of duplicative
code, because the existing routines you might have been thinking of
using (lsyscache.c etc) don't behave that way.
Right, I'm envisioning doing a conditional LockAcquire and
1 - 100 of 1081 matches
Mail list logo
