On Thu, Oct 12, 2006 at 03:03:43PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The specific concern I have is large result sets, like 10s or 100s of MB
(or more). We just added support for not buffering those in psql, so it
seems like a step backwards to have the backend
On Thu, Oct 12, 2006 at 12:01:12PM -0700, David Fetter wrote:
On Thu, Oct 12, 2006 at 03:51:39PM +0400, Teodor Sigaev wrote:
You're running in auto-commit, mode. An implicit commit happens
after this statement. Which clears the table. Looks right to me.
Oops, I see
Should something
On Thu, Oct 12, 2006 at 09:40:30AM -0700, Josh Berkus wrote:
Jim,
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN | [[NO] BITMAP] INDEX index_name} */
This proposal seems to deliberately ignore every point that has been
made
Wasn't configure changed to complain if it's fed a bogus argument? I
just did ./configure --with-deps on a fresh checkout and it didn't
complain...
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
See also information_schema and newsysviews on pgFoundry.
On Wed, Oct 11, 2006 at 10:15:22AM +0200, Zdenek Kotala wrote:
Look at http://www.postgresql.org/docs/8.1/interactive/catalogs.html
Specially on pg_attribute, pg_class and pg_type table. Or you can use
some features in the psql.
On Wed, Oct 11, 2006 at 10:04:10AM -0400, Andrew Dunstan wrote:
Teodor Sigaev wrote:
It's possible to create function 'exists' and mention only it in docs.
Good point. Will you do that, or do you want me to?
ISTM it would be better to mention the deprecated version and
explicitly state that
On Wed, Oct 11, 2006 at 04:17:19PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On Wed, Oct 11, 2006 at 10:04:10AM -0400, Andrew Dunstan wrote:
Teodor Sigaev wrote:
It's possible to create function 'exists' and mention only it in docs.
Good point. Will you do that, or do
On Wed, Oct 11, 2006 at 04:27:41PM -0400, Andrew Sullivan wrote:
Hello,
In a possible moment of insanity, in
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php
I volunteered to try to help solve a problem Tom Lane noted: The
hard part of this problem is finding a
On Wed, Oct 11, 2006 at 05:00:50PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Sorry, I don't know the history of hstore... but if it's brand new, why
are we worried about backwards compatibility?
Because it's been available for awhile outside of contrib (namely,
on Oleg
On Tue, Oct 10, 2006 at 06:06:09PM +0200, Peter Eisentraut wrote:
Simon Riggs wrote:
For 8.3, I'd like to add the following two related features to assist
with Index Tuning and usability:
- Virtual Indexes
This seems useful, but I'm not sure we need a catalog object for that.
It
IIRC there was an intention to allow ownership reassignment of all
objects in the database. Somehow views got missed (probably because they
don't currently have an ALTER command). If there isn't a lot of code
involved in making this happen, I'd argue it should go in as a bug fix.
If not, can we
On Tue, Oct 10, 2006 at 09:23:34PM -0400, Neil Conway wrote:
On Tue, 2006-10-10 at 20:17 -0500, Jim C. Nasby wrote:
IIRC there was an intention to allow ownership reassignment of all
objects in the database. Somehow views got missed
ALTER TABLE can change view ownership (as well
On Tue, Oct 10, 2006 at 09:33:13PM -0400, Neil Conway wrote:
On Tue, 2006-10-10 at 20:27 -0500, Jim C. Nasby wrote:
Wow, that's news to me. I'll prepare a docs patch to reflect that.
It is already reflected in the docs, although it might need to be more
prominent.
Yeah, it should be listed
Sinte we already have width_bucket, I'd argue this should go in core. If
someone's feeling adventurous, there should probably be a double
precision version as well. Hrm... and maybe text...
Doesn't the backend already have something like this for calculating
histograms?
On Sun, Oct 08, 2006 at
On Sat, Oct 07, 2006 at 05:29:03PM -0400, Tom Lane wrote:
So the only regex patterns you can't write directly are dot, R* and R?
for which you can use these locutions:
. = ?
R* = (R+|)
R? = (R|)
(Perhaps this should be documented
On Sat, Oct 07, 2006 at 06:22:19PM -0700, David Fetter wrote:
On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The existing patch's behavior is that the rightmost switch wins,
ie, if an object's name matches more than one pattern then it
On Sun, Oct 08, 2006 at 05:26:11PM -0700, Mark Wong wrote:
I made another couple of gross mistakes of forgetting to compile
PostgreSQL with --enable-thread-safe and enabling the user space irq
balancing program in Linux. I've restarted the histories with 600 and
What's the advantage of irq
On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Sinte we already have width_bucket, I'd argue this should go in core. If
someone's feeling adventurous, there should probably be a double
precision version as well. Hrm... and maybe text
On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Oct 09, 2006 at 12:02:12PM -0400, Tom Lane wrote:
... I think Jeremy's problem would be solved just by applying
the float8 version to extract(epoch from timestamp).
Thinko there ... I
On Mon, Oct 09, 2006 at 05:56:41PM +, Chris Browne wrote:
[EMAIL PROTECTED] (Tzahi Fadida) writes:
Hi,
Is there a LinkedIn group for Postgresql/Hackers list.
If there is, how can i join?
The usual way LinkedIn works is that if there are people you know that
do PostgreSQL work, they
On Mon, Oct 09, 2006 at 01:59:18PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sat, Oct 07, 2006 at 06:22:19PM -0700, David Fetter wrote:
On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote:
My first thought is that the rule should be to apply all
On Mon, Oct 09, 2006 at 10:37:32AM -0700, Mark Wong wrote:
Jim C. Nasby wrote:
On Sun, Oct 08, 2006 at 05:26:11PM -0700, Mark Wong wrote:
I made another couple of gross mistakes of forgetting to compile
PostgreSQL with --enable-thread-safe and enabling the user space irq
balancing program
On Mon, Oct 09, 2006 at 03:49:50PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Oct 09, 2006 at 01:49:37PM -0400, Tom Lane wrote:
This is exactly the slippery slope I don't care to start down.
I guess I'm confused as to how this is any different from other
On Mon, Oct 09, 2006 at 02:57:28PM -0500, Aaron Bono wrote:
On 10/5/06, Jim Nasby [EMAIL PROTECTED] wrote:
On Oct 5, 2006, at 11:50 AM, Tom Lane wrote:
regression=# select ('2006-09-15 23:59:00'::timestamp - '2006-09-01
09:30:41'::timestamp);
?column?
--
14 days
On Fri, Oct 06, 2006 at 02:35:55AM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
It would be nice to denote types/aliases that are and aren't ANSI. A
number are marked in the docs, but it would be good to add the info
to that summary table.
Right under the table this sentence appears:
On Fri, Oct 06, 2006 at 04:10:42PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I would think that c || 'x' would result in 'xx',
but it doesn't
We did it that way up through 7.3, but changed because we concluded the
behavior was inconsistent
Column | Type | Modifiers
+---+---
c | character(20) |
decibel=# select c, c || ('x'::char) from c;
c | ?column?
--+--
x| xx
I would think that c || 'x' would result in 'x
Moving to -docs
On Tue, Oct 03, 2006 at 12:13:46PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Markus Schaber [EMAIL PROTECTED] writes:
Here's a small patch that adds an appropriate explanation.
If we're going to document these aliases, what of float4, float8, and bool?
Also,
Why is it timestamptz can store a date and time to 1 microsecond in 8
bytes but a timetz needs 12 to store just the time to 1 microsecond?
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
I'm looking at how NULLs are handled in relation to plpgsql row types.
Looking at exec_assign_value, it appears that we're supposed to be able
to handle setting a row variable to NULL:
if (*isNull)
{
/* If source is null, just assign nulls to
On Fri, Sep 29, 2006 at 01:15:06PM +0900, ITAGAKI Takahiro wrote:
Jim C. Nasby [EMAIL PROTECTED] wrote:
The reason I thought of this is because once the transaction commits, we
have no use for the cid info. So we could do something like have
bgwriter look for tuples that belong
On Thu, Sep 28, 2006 at 11:32:37AM -0400, D'Arcy J.M. Cain wrote:
On Thu, 28 Sep 2006 11:25:45 -0400
Luke Lonergan [EMAIL PROTECTED] wrote:
Oic - so it's a floating point in an 8 byte int. That probably limits the
speed benefits, no?
No, it's an int type. Floating point has nothing to
In addition to/instead of abstracting cmin/cmax to a phantom ID, what
about allowing for two versions of the tuple header, one with cid info
and one without? That would allow for cid info to be stripped out when
pages were written to disk.
The downside to this is that we'd have to be able to deal
On Thu, Sep 28, 2006 at 05:13:11PM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
In addition to/instead of abstracting cmin/cmax to a phantom ID, what
about allowing for two versions of the tuple header, one with cid info
and one without? That would allow for cid info to be stripped out
On Thu, Sep 28, 2006 at 05:19:47PM -0400, D'Arcy J.M. Cain wrote:
On Thu, 28 Sep 2006 22:53:34 +0200
Martijn van Oosterhout kleptog@svana.org wrote:
Every new type needs to have a well-defined use-case before it can be
considered for includion.
Well, it is already included. The current
On Thu, Sep 28, 2006 at 03:07:39PM -0700, David Wheeler wrote:
PostgreSQLers,
I just ran into an issue where a client thought that autovacuum was
running but it wasn't. This is because it's not fatal when autovacuum
is on but stats_start_collector and/or stats_row_level is off. I
On Thu, Sep 28, 2006 at 11:23:30PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Sep 28, 2006 at 05:19:47PM -0400, D'Arcy J.M. Cain wrote:
Well, it is already included. The current proposal is simply to
improve the existing type. I guess you are arguing a different
On Wed, Sep 27, 2006 at 05:38:38AM -0400, Bruce Momjian wrote:
Heikki Linnakangas wrote:
Jim C. Nasby wrote:
Couldn't vacuum just eliminate tuples marked dead? Heck, don't we do
that anyway right now?
You mean _index_ tuples marked dead? Sure, no problem there.
Granted, you'd
On Wed, Sep 27, 2006 at 12:30:43PM +0100, Simon Riggs wrote:
On Tue, 2006-09-26 at 21:27 -0500, Jim C. Nasby wrote:
Since I don't recall any ideas ever having been thrown out on how to do
this...
ISTM that we could gain additional insight on how many rows would likely
result from
On Wed, Sep 27, 2006 at 01:55:21PM -0400, Andrew Dunstan wrote:
Kris Jurka wrote:
On Wed, 27 Sep 2006, Andrew Dunstan wrote:
The settings are in hours, so this says that if we haven't seen a
HEAD build in 1 day or a stable branch build in 1 week, alert the
owner by email, and
On Wed, Sep 27, 2006 at 04:13:34PM -0400, Tom Lane wrote:
Jon Lapham [EMAIL PROTECTED] writes in pgsql-general:
If I run...
sleep 3; echo starting; createdb bar
...and power off the VM while the createdb bar is running.
Upon restart, about 50% of the time I can reproduce the following
On Wed, Sep 27, 2006 at 04:52:51PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Then again, if we're doing that, we could probably just nuke 'em...
This has been considered and rejected before, on the grounds that
removing files you don't know the source of is a good way
On Tue, Sep 26, 2006 at 12:35:54PM +0100, Heikki Linnakangas wrote:
Tom Lane wrote:
We could rename pg_attribute as pg_userattribute, and remove all the
system attributes from that. To stay backwards-compatible, we could have
a pg_attribute view on top of that contained the system attributes
Since I don't recall any ideas ever having been thrown out on how to do
this...
ISTM that we could gain additional insight on how many rows would likely
result from a join be comparing the shape of the histogram for the
joining columns. For example, if the histogram arrays were exactly
identical,
On Tue, Sep 26, 2006 at 11:16:54AM +0100, Heikki Linnakangas wrote:
To locate the actual matching items on the heap page, we have to scan
the heap page because we don't have the item ids, so this is a tradeoff
between CPU and I/O. However, we could have a hybrid where we initially
store
On Tue, Sep 26, 2006 at 05:27:56PM +0100, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Anything that involves having VACUUM re-evaluate index expressions is a
nonstarter ... or have you already forgotten the optimizations we put
into 8.2 that assume, eg, no
On Tue, Sep 26, 2006 at 08:51:10AM -0400, Tom Lane wrote:
3. Do nothing. Let index scans mark the index tuple as dead when it's
convenient. There's no correctness problem with just leaving dead index
tuples there, because you have to check the index quals on each heap
tuple anyway when
On Fri, Sep 22, 2006 at 12:59:36PM -0700, Joe Conway wrote:
Andrew Sullivan wrote:
On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more
On Sun, Sep 24, 2006 at 12:26:55AM -0400, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
I asked around inside Red Hat but haven't gotten any responses yet ...
seeing that it's a rather old Suse kernel, I can understand that RH's
kernel hackers might not be too excited
On Mon, Sep 25, 2006 at 10:03:50AM +0200, Peter Eisentraut wrote:
Am Montag, 25. September 2006 04:04 schrieb ITAGAKI Takahiro:
#shared_buffers = 32000kB # min 128kB or max_connections*16kB
#temp_buffers = 8000kB # min 800kB
#effective_cache_size = 8000kB
Are there any
On Mon, Sep 25, 2006 at 09:29:28AM +0200, Jean-Paul Argudo wrote:
Hi all,
I would like to submit two ideas:
1/
In the daily tasks I have as (also) a standard DBA, I found usefull to
view locks in a human point of view. I think the ~ '^pg_' part of the
queries may be not so clean... Any
On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote:
On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
On 9/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
the whole
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan [EMAIL PROTECTED] wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could probably get a
On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system
On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote:
On 9/22/06, Jim C. Nasby [EMAIL PROTECTED] wrote:
I'm not asking for a defined solution to how to support multiple
different users of locks within the same database. I just want us to set
aside (as in, recommend they not be used
On Thu, Sep 21, 2006 at 11:24:53AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
What happened to PL/pgSQL debugging? Did it die?
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and
On Wed, Sep 20, 2006 at 04:02:00PM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right
On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
Also, not sure what the thoughts are regarding surnames. I'm referred to
as both Simon and Simon Riggs in the release notes. Should we have a
policy of first mention uses full name, subsequent mentions just use
first name if there is
On Wed, Sep 20, 2006 at 02:09:43PM +0100, Simon Riggs wrote:
But why in the world would you want to stop the slave to do it? ISTM
we would want to arrange things so that you can copy the slave's files
while it continues replicating, just as with a standard base backup.
You can do that,
On Wed, Sep 20, 2006 at 04:22:47PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
What would the failure mode be? Would we just keep going until the box
ran out of memory? I think it'd be better to have some kind of hard
limit so that a single backend can't grind a production
On Wed, Sep 20, 2006 at 04:26:30PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
An advantage to being able to stop the server is that you could have one
server processing backups for multiple PostgreSQL clusters by going
through them 1 (or more likely, 2, 4, etc) at a time
On Wed, Sep 20, 2006 at 05:50:48PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
My thought is that in many envoronments it would take much beefier
hardware to support N postmasters running simultaneously than to cycle
through them periodically bringing the backups up
On Wed, Sep 20, 2006 at 07:52:33PM -0400, Tom Lane wrote:
face up to the possibility of malicious use. For instance, it's not
very hard to create a DoS situation by running the system out of shared
lock table space:
Didn't you just say we don't try and protect against DoS? ;P
The brute
On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
Both this and pg_prepared_statements are very useful for pooled
connection setups.
Should read Both of these are very useful...
I don't think I can't change that because they are two separate bullet
items.
Except it's
On Tue, Sep 19, 2006 at 01:10:48AM +0200, Albert Cervera Areny wrote:
Hi,
I've decided to start hacking on PostgreSQL, and I've looked at the
easier jobs in the TODO list. I'm interested in implementing:
% Add a GUC variable to control the tablespace for temporary objects and sort
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer inserting the MAC address and the time, to at
least allow me to control if a collision is possible. This is not easy
to do using a few
On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
Both this and pg_prepared_statements are very useful for pooled
connection setups.
Should read Both of these are very useful
On Tue, Sep 19, 2006 at 03:35:55PM +0200, Gevik Babakhani wrote:
As others have mentioned, using MAC address doesn't remove the
possibility of a collision.
Maybe a good compromise that would allow a generator function to go into
the backend would be to combine the current time with a
On Tue, Sep 19, 2006 at 09:51:23AM -0400, [EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
I would not use a 100% random number generator for a UUID value as was
suggested. I prefer
On Mon, Sep 18, 2006 at 10:10:32AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
One problem I see with userlock is that you're asking for lock ID
conflicts unless you control everything on the system that's using
userlocks.
Well, the lock IDs already include the database
On Mon, Sep 18, 2006 at 09:30:43AM -0400, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
The reason for this behavior is that analyze.c attaches the CREATE TABLE
AS aliases to the targetlist (via applyColumnNames) before it processes
the ORDER BY clause. (So, order by z2 works
I couldn't remember if you wanted grammar/spelling nitpicks, so I
included them... sorry for the noise if you didn't want them.
#Improve performance of statistics monitoring, especially
pg_stat_activity (Tom)#
I would s/pg_stat_activity/stats_command_string/, since that's where the
actual change
If you're going to yank it, please at least include a generator in
contrib.
Personally, I'd like to see at least some kind of generator in core,
with appropriate info/disclaimers in the docs. A simple random-number
generator is probably the best way to go in that regard. I think that
most people
On Mon, Sep 18, 2006 at 12:23:16PM -0400, [EMAIL PROTECTED] wrote:
I have UUID generation in core in my current implementation. In the
last year that I've been using it, I have already chosen twice to
generate UUIDs from my calling program. I find it faster, as it avoids
have to call out to
On Mon, Sep 18, 2006 at 07:46:41PM +0100, Gregory Stark wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
1. When using new OIDs always start from a fixed number. For example
1. This way the new OIDs are easy to recognize and the developer can
continue the work.
Reserving a range
On Mon, Sep 18, 2006 at 01:59:00PM -0400, Andrew Dunstan wrote:
Pascal Meunier wrote:
Thanks for answering; I appreciate it, as well as the efforts of all the
people who contributed to this database that I now use in my projects.
However, I feel that making a decision based on the number
On Mon, Sep 18, 2006 at 05:06:09PM -0400, Merlin Moncure wrote:
On 9/18/06, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... I was thinking it didn't matter, but on closer look, the
int4-oid cast is implicit while the oid-int4 one is only assignment.
So you'd need to write a cast to pass an OID if we
On Sun, Sep 17, 2006 at 04:18:36PM -0400, Tom Lane wrote:
* table and index. (Ideally other_pages should include all the other
* tables and indexes used by the query too; but we don't have a good way
* to get that number here.)
A first-order approximation to this would be to add up the
On Mon, Sep 18, 2006 at 12:29:56AM +0300, Enver ALTIN wrote:
On Fri, 2006-09-15 at 09:38 -0700, Joshua D. Drake wrote:
Hello,
Hi Joshua,
Yeah, this is a cross post and it is slightly off topic but IMHO this is
important.
Tomorrow one of our own, Devrim Gunduz is becoming a man.
On Sun, Sep 17, 2006 at 07:38:38PM -0400, Tom Lane wrote:
* The contrib/userlock replacement issue
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
On Sun, Sep 17, 2006 at 10:10:52PM -0400, Tom Lane wrote:
I'm inclined to fix this in HEAD but not back-patch it, on the grounds
that there might be apps out there expecting the existing behavior,
and it's not a big enough deal to change behavior in a minor release.
Thoughts?
Isn't the
On Sun, Sep 17, 2006 at 12:32:13PM -0700, Joshua D. Drake wrote:
Tom proposed a modest roadmap type experiment a week or so ago. I'd like
to see that pursued. After all, we know of some things that are at least
at first cut stage for 8.3, and a few things high on may people's
agenda. I'd
On Mon, Sep 18, 2006 at 12:20:10AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I think it'd be better to attack this problem from the other side;
namely looking at what's actually cached.
You can kiss goodbye to plan stability if you go that route... and
in any case I
On Sun, Sep 10, 2006 at 09:40:51AM -0700, Joshua D. Drake wrote:
In any case the same logic that leads to it being desirable to report all
the
errors to the user in a UI and not just report them one by one also
applies to
the database. I'm not sure it's the most important issue in the
On Thu, Sep 14, 2006 at 10:24:43AM -0400, Pascal Meunier wrote:
First, I asked about this on #postgresql, and I realize that this request
would be a low priority item. Yet, it would be an improvement for security
reasons.
When creating a function using EXTERNAL SECURITY DEFINER, by default
On Thu, Sep 14, 2006 at 11:12:14AM -0400, D'Arcy J.M. Cain wrote:
The benefit of the money type is speed. Because internal operations
are done on integers they can generally be handled by single CPU ops.
My tests on the 64 bit version show 10% to 25% improvement over numeric
for many
On Thu, Sep 14, 2006 at 11:32:09PM +0200, Peter Eisentraut wrote:
Gevik Babakhani wrote:
As suggested in earlier discussion we provide a raw/plain output of
the uuid type:
devdb=# select * from tbluuid;
pk|
--+
On Thu, Sep 14, 2006 at 02:36:22PM -0700, Joshua D. Drake wrote:
But on a serious note, the problem I run into is exactly the opposite.
Someone will turn on autovacuum because they thought it was a good idea
and for their work load, it isn't. So instead of creating new and
interesting ways
On Sat, Sep 02, 2006 at 09:26:36PM -0700, Joshua D. Drake wrote:
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
for 8.3 (and early on so we get some good testing of it).
Can someone put this on the TODO, just so we (hopefully) don't forget
about it?
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
While I'm sitting here in New Jersey in a room with Bruce Momjian (aka
Rock Star), I figured now would be a good time to announce my new
employment. I'll be doing sales support/engineering from Austin.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDBhttp://enterprisedb.com
added to the release notes and have something automagically cull those
out of CVS.
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 2
such as bugzilla, but let's get one
thing after another up.
Actually, I've generally found bugzilla to be a decent tool for
general-purpose tracking. Feature requests and what-not need a lot of
the same capabilities of a bug tracker, and having everything in one
tool is often very handy.
--
Jim C. Nasby
of trawling through pg_dump to confirm that.
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
, this is a C file stuff...)
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire
what actually
happened would probably suffice. It'd at least be a great start.
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 4: Have
On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct settings. I don't know
...
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 6: explain analyze is your friend
the status of the migration tools? Is that
ball still in Larry's court?
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
---(end of broadcast)---
TIP 6: explain analyze
201 - 300 of 1317 matches
Mail list logo
