On Tue, 19 Sep 2006, Alvaro Herrera wrote:
Jeremy Drake wrote:
I have found the same thing with the type timestamp without time zone.
The verbosity of type names seems rather extreme.
Then use simply timestamptz (with TZ) or timestamp (without).
Didn't know about these, learn something
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
== installing plpgsql ==
ERROR: could not access file $libdir/plpgsql: No such file or
directory
command failed:
* -Add fillfactor to control reserved free space during index creation
GIN doesn't use fillfactor yet...
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end
[EMAIL PROTECTED] writes:
I have the impression I'm not being heard.
*I* control the MAC address assignment for all of *MY* units.
No, you're missing the point. How does that help *me* avoid collisions with
your UUIDs? UUIDs are supposed to be unique period, not just unique on your
On Wed, 20 Sep 2006, Gregory Stark wrote:
[EMAIL PROTECTED] writes:
I have the impression I'm not being heard.
*I* control the MAC address assignment for all of *MY* units.
No, you're missing the point. How does that help *me* avoid collisions with
your UUIDs? UUIDs are supposed to be
Hi, Martijn,
Martijn van Oosterhout wrote:
Someone writing SECURITY DEFINER in their function definition has to be
understood to know what they're doing. After all, chmod +s doesn't
reset global execute permissions either, because that would be far too
confusing. The same applies here IMHO.
Hi, Bruce,
Bruce Momjian wrote:
Should I try hacking my mail reader to prevent this? I think I see
where it is happening in the code.
AFAICT, the wrapping of long header lines by indentation (as your mailer
seems to do) is RFC conformant, so I think it is majordomo who needs the
fix.
The
Hi, Bruce,
Markus Schaber wrote:
Should I try hacking my mail reader to prevent this? I think I see
where it is happening in the code.
AFAICT, the wrapping of long header lines by indentation (as your mailer
seems to do) is RFC conformant, so I think it is majordomo who needs the
fix.
Hi, Martijn,
Martijn van Oosterhout wrote:
2. I can see the official todo list being in CVS, which gives it all
the access protection it needs. A wiki todo list can stay where it is,
just that it's not official.
[I've just made a reference to the TODO list in CVS from the wiki, that
if I look into my cvs repository directory, it shows only
gram.y,v,
with gram.c,v in Attic - which seems to make sense. Must be my
client
that's gone crazy. In fact, mmy output ends up as:
Index: src\backend\parser/gram.c
On Wed, Sep 20, 2006 at 11:59:52AM +0200, Markus Schaber wrote:
But I have the possibility to chmod a-x before chmod +s the file.
Maybe we should add [NOT] PUBLICLY EXCUTABLE[1] keywords to CREATE
FUNCTION, with the default being the current behaviour for now (possibly
configurable). Add an
I discussed with Gavin about pg_downgrade process. I think that it
should be much dangerous and more complex problem than upgrade. Some
operation on the new system should makes downgrade impossible ...
My experience with database upgrades is that downgrade is requested only
if there some show
On Wed, Sep 20, 2006 at 12:54:14PM +0200, Zdenek Kotala wrote:
My first question is how important is downgrade for You and Your customers?
And second is how to verify that downgrade is possible?
Well, one way to do it is to set up a Slony replica using the older
version of the software.
On Wed, Sep 20, 2006 at 12:28:54PM +0200, Markus Schaber wrote:
Maybe you should rename the public writable Wiki page list to Wishlist
instead of Todo, to make the difference more explicit.
Hmm, all the stuff there now does refer to things that are on the TODO
list (I think). So it's not
Jeremy Drake wrote:
On Tue, 19 Sep 2006, Alvaro Herrera wrote:
Jeremy Drake wrote:
I have found the same thing with the type timestamp without time
zone.
The verbosity of type names seems rather extreme.
Then use simply timestamptz (with TZ) or timestamp (without).
Didn't know about
On Wed, 20 Sep 2006, Andrew Sullivan wrote:
On Wed, Sep 20, 2006 at 12:54:14PM +0200, Zdenek Kotala wrote:
My first question is how important is downgrade for You and Your customers?
And second is how to verify that downgrade is possible?
Well, one way to do it is to set up a Slony
Thanks, done.
---
Alvaro Herrera wrote:
Jim C. Nasby wrote:
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:
Hi, Mark,
[EMAIL PROTECTED] wrote:
The versions that include a MAC address, time, and serial number for
the machine come pretty close, presuming that the user has not
overwritten the MAC address with something else. It's unique at
manufacturing time.
Not even that is guaranteed. I remember
On Wed, Sep 20, 2006 at 09:28:42PM +1000, Gavin Sherry wrote:
Well, I think that people who really want downgrade in such a tool are
those for which slony replication is just not an option. That is, data in
the range of hundreds of gigabytes. Using slony to upgrade is often not
practical
Gavin Sherry wrote:
On Wed, 20 Sep 2006, Andrew Sullivan wrote:
On Wed, Sep 20, 2006 at 12:54:14PM +0200, Zdenek Kotala wrote:
My first question is how important is downgrade for You and Your customers?
And second is how to verify that downgrade is possible?
Well, one way to do it is to
devdb=# select * from tbluuid;
pk|
--+
6b13c5a1afb4dcf5ce8f8b4656b6c93c |
01e40a79b55b6e226bffb577e960453d |
(2 rows)
The UUID standards define a single perfectly clear format, and the one
you show is not it.
I was wondering if
The dashless format is neither standards compliant nor compatible with
other databases that have uuid functions (notably MS SQL Server and
MySQL), nor with microsoft tools where they're used frequently.
(ignoring the {} wrapping stuff which is trivial).
If we add a UUID type to core, I
Walter Cruz wrote:
The larger version is only hidden from everyone :)
http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg
http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg
Very cool, I was hoping someone would post this. Any chance we
I would like to work on the domain casting problem. I have spent
sometime in order to understand how this whole domain handling works
when it comes to casting and I think I understand why this cannot be
fixed in isolation as Tom has described in:
Mark,A model that intended to try and guarantee uniqueness would provide aUUID generation service for the entire host, that was not specific to
any application, or database, possibly accessible via the loopbackaddress. It would ensure that at any given time, either the time isnew, or the sequence
On Tue, 2006-09-19 at 12:13 -0400, Tom Lane wrote:
Also, I'm not sold that the concept is even useful. Apparently the idea
is to offload the expense of taking periodic base backups from a master
server, by instead backing up a PITR slave's fileset --- which is fine.
Good. That's the key
On Wed, Sep 20, 2006 at 05:04:00AM -0400, Gregory Stark wrote:
[EMAIL PROTECTED] writes:
I have the impression I'm not being heard.
*I* control the MAC address assignment for all of *MY* units.
No, you're missing the point. How does that help *me* avoid collisions with
your UUIDs? UUIDs are
Matthew T. O'Connor schreef:
Walter Cruz wrote:
The larger version is only hidden from everyone :)
http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg
http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg
Very cool, I was hoping someone
On Tue, 2006-09-19 at 14:59 +0100, Heikki Linnakangas wrote:
Praveen Kumar N wrote:
how about system cache? Can we control the size of system cache?
It's in backend-private memory. I don't remember how it's sized.
It's fixed size: syscache caches a predefined set of catalog info.
--
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stijn Vanroye
Sent: 20 September 2006 14:48
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pdfs of the conference
Matthew T. O'Connor schreef:
Walter Cruz wrote:
The larger version
[EMAIL PROTECTED] wrote:
Really this whole debate only reinforces the point that there isn't
a single way of doing UUID generation. There are multiple libraries
out there each with pros and cons. It makes more sense to have
multiple pgfoundry UUID generating modules.
Exactly. If I lead you to
Jeremy Drake [EMAIL PROTECTED] writes:
I must jump in with my amusement at this whole conversation. I just
looked up the standard (http://www.ietf.org/rfc/rfc4122.txt) and it
includes this abstract:
A UUID is 128 bits long, and can guarantee
uniqueness across space and time.
The only
-Original Message-
From: Dave Cramer [mailto:[EMAIL PROTECTED]
Sent: 20 September 2006 15:40
To: Dave Page
Subject: Re: [HACKERS] pdfs of the conference
The guy with the PostgreSQL sign round his neck is Devrim
Gunduz. The
guy holding one up at the back is Chris Browne.
Gevik Babakhani [EMAIL PROTECTED] writes:
First I would like to know how PG's code looked like without the
domains.
IIRC, as far as the datatype coercion and operator/function resolution
code were concerned, the domain patch basically consisted of dropping
getBaseType() calls in at a bunch of
Tom Lane wrote:
So the hard part of this doesn't really require any understanding of
code at all. What we need is a proposal for an algorithm that loosens
the casting rules just enough to make explicit pg_cast entries for
domains work the way we would like them to, without wholesale breakage
of
The larger version is only hidden from everyone :)
http://people.planetpostgresql.org/mha/uploads/photo/conf/conf
erence_group.jpg
http://people.planetpostgresql.org/mha/uploads/photo/conf/con
ference_group.jpg
Very cool, I was hoping someone would post this. Any
Markus Schaber wrote:
Hi, Bruce,
Bruce Momjian wrote:
Should I try hacking my mail reader to prevent this? I think I see
where it is happening in the code.
AFAICT, the wrapping of long header lines by indentation (as your mailer
seems to do) is RFC conformant, so I think it is
On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
AFAICT it's just junk. It happens to be the input times
MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't
change the function to return VOID
I agree. Given how soon we want to get an 8.2 beta out the door, perhaps
this change
I'd like to include a section on Major changes in this release at the
top of the release notes, as has been done for at least the last 6 major
releases. The notes below are one stab at that, for **discussion**. I've
tried to arrange specific changes into groups...
Major changes in this release:
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
AFAICT it's just junk. It happens to be the input times
MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't
change the function to return VOID
I agree. Given how soon we want to get an 8.2
On 9/19/06 5:15 AM, Gavin Sherry [EMAIL PROTECTED] wrote:
On Tue, 19 Sep 2006, Heikki Linnakangas wrote:
Jie Zhang wrote:
Hi Heikki and all,
Please find the latest bitmap index patch in the attachment. This patch is
generated against the postgresql cvs head.
Thanks.
The handling
On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
I have completed my first pass over the release notes and Tom has made
some additions:
http://momjian.postgresql.org/cgi-bin/pgrelease
I will probably go over them again in a few hours, update them to
current CVS, then move
Simon Riggs wrote:
Zero administration overhead now possible (Alvaro)
With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
embedded databases.
This was true for 8.1 already, no?
Regards,
Andreas
Tom Lane wrote:
Rereading what I just wrote, it might be as simple as allowing a
two-step cast in certain cases, only if the first step is a domain to
base type coercion (which we assume would be specially marked in
pg_cast). But the devil is in the details ... and anyway there might
be a
Andreas Pflug wrote:
Simon Riggs wrote:
Zero administration overhead now possible (Alvaro)
With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
embedded databases.
This was true for 8.1 already, no?
On Wed, 2006-09-20 at 18:22 +0200, Andreas Pflug wrote:
Simon Riggs wrote:
Zero administration overhead now possible (Alvaro)
With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
embedded databases.
Here's a starter though:
The guy with the PostgreSQL sign round his neck is Devrim Gunduz.
The guy holding one up at the back is Chris Browne. On the front
row
theres Josh Berkus in the middle, Peter Eisentraut to the right,
and
Gavin Sherry on the far right. Bruce is behind Gavin in
Mark Wong wrote:
Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
Curious, I'm still seeing the same behavior. Maybe I'll take another
snapshot from CVS.
Hm, maybe I need to try a bit harder here. Does the not registered
error happen immediately/reliably for you, or do you need to run
Joshua D. Drake [EMAIL PROTECTED] writes:
No. 8.1 did not have it turned on by default.
Neither does 8.2 though.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your
Mark Dilger wrote:
Casts from int2 - int4, int2 - int8, and int4 - int8 would all be
SAFE, I think, because they are not lossy. But perhaps I have not
thought enough about this and these should be IMPLICIT rather than SAFE.
I have thought about this some more. I think these are indeed SAFE.
Mark Dilger [EMAIL PROTECTED] writes:
Mark Dilger wrote:
Casts from int2 - int4, int2 - int8, and int4 - int8 would all be
SAFE, I think, because they are not lossy. But perhaps I have not
thought enough about this and these should be IMPLICIT rather than SAFE.
I have thought about this
Simon Riggs wrote:
On Wed, 2006-09-20 at 18:22 +0200, Andreas Pflug wrote:
Simon Riggs wrote:
Zero administration overhead now possible (Alvaro)
With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
Mark Wong [EMAIL PROTECTED] writes:
I did a gross test and my kit appears broken between the 8.0 and 8.1
releases. I'll try to narrow down the exact date.
I've narrowed it down between cvs pulls from Dec 14, 2005 and Dec 15,
2005. Does the attached diff appear to be a plausible cause?
Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
I did a gross test and my kit appears broken between the 8.0 and 8.1
releases. I'll try to narrow down the exact date.
I've narrowed it down between cvs pulls from Dec 14, 2005 and Dec 15,
2005. Does the attached diff appear to be a
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
No. 8.1 did not have it turned on by default.
Neither does 8.2 though.
oh... heh.
J
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Tom Lane wrote:
Mark Dilger [EMAIL PROTECTED] writes:
Mark Dilger wrote:
Casts from int2 - int4, int2 - int8, and int4 - int8 would all be
SAFE, I think, because they are not lossy. But perhaps I have not
thought enough about this and these should be IMPLICIT rather than SAFE.
I have
Per discussion on reducing heap tuple header, I've started to work on
the phantom cid idea.
I'm thinking of having an array of cmin,cmax pairs, indexed by phantom
cid number. Looking up cmin,cmax of a phantom id is then a simple array
lookup. To allow reusing phantom cids, we have a hash
Zdenek, Andrew,
Overall, I'd tend to say that downgradability should be for a v2 version of
the tool. It's simply not as important. For one thing, there's always
reverting-to-backup.
However, we *do* need to be able to halt the upgrade and reverse it if it
starts erroring out. So that
Matteo Beccati [EMAIL PROTECTED] writes:
Tom Lane ha scritto:
Matteo Beccati [EMAIL PROTECTED] writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is large enough? I feel a bit
uncomfortable about
Albe Laurenz wrote:
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
Because createlang relies on *dynamic* loading.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
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 at the moment
my guess is that it never will. The data
Mark Dilger [EMAIL PROTECTED] writes:
If the system chooses cast chains based on a breadth-first search,
then the existing int2 - int8 cast would be chosen over an int2 -
int4 - int8 chain, or an int2 - int3 - int4 - int8 chain, or in
fact any chain at all, because the int2 - int8 cast is the
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 09:31:48AM -0700, Mark Dilger wrote:
Perhaps we need to be able to register casts with more information than
just IMPLICIT vs. EXPLICIT. Perhaps we also need something like SAFE or
some other term, and then have a rule that no chain of casts chosen by the
system (as
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
Should the values in the default configuration file contain units? And
if so, should we phase out the verbal description of the units, e.g.,
#work_mem = 1024# min 64, size in kB
becomes
#work_mem = 1MB # min 64kB
(The native units are of course
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,
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 server into a
swap-storm. (Arguably, not having a limit is
On Wed, Sep 20, 2006 at 10:20:18PM +0200, Peter Eisentraut wrote:
Should the values in the default configuration file contain units?
And if so, should we phase out the verbal description of the units,
e.g.,
#work_mem = 1024# min 64, size in kB
becomes
#work_mem
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, essentially
providing N+1 capability.
Why wouldn't you
Magnus Hagander wrote:
What does your CVS/Entries file look for that dir?
It does contain both gram.c and gram.y. They look just the same (except
for version and date, of course). I don't know how it got there ;-) Is
it safe to just remove that?
I don't know if it's safe, but my Entries
On Wed, Sep 20, 2006 at 10:26:55AM -0700, Mark Dilger wrote:
I have thought about this some more. I think these are indeed SAFE. The
distinction between SAFE and IMPLICIT should not, I think, be whether the
storage type is identical, but rather whether there is any possible loss of
Alvaro Herrera [EMAIL PROTECTED] writes:
Strangely, if I try to do a cvs add gram.c, it fails with
cvs add: `gram.c' added independently by second party
I don't know what this means. (Why second party and not third
party?). Even if I delete gram.c. Even if I remove it from
.cvsignore.
I
Martijn van Oosterhout kleptog@svana.org writes:
My question is whether there should be any implicit casts that are not
safe. Your example int8 - float8 being implicit is I think an error
and we should wonder why that cast implicit now anyway.
Because the SQL spec requires it. You are not
Peter,
#work_mem = 1024# min 64, size in kB
becomes
#work_mem = 1MB # min 64kB
(The native units are of course still shown in the documentation for
reference.)
+1
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
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
Jim C. Nasby [EMAIL PROTECTED] writes:
I didn't realize we had a lot of ways a backend could run a machine out
of memory, or at least ways that didn't have some kind of limit (ie:
work_mem). Are any of them very easy to run into?
work_mem has nothing to do with trying to guarantee no swapping
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,
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-to-date.
How you figure that? The cycling approach will require
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
Tom Lane wrote:
Now we do have the flexibility to alter the default contents of pg_cast
--- there could be more or fewer entries in there than there are now,
if the type coercion rules are altered to do less or more automatically
than they do now. But the end-result behavior needs to wind up
Trying to design this stuff purely according to abstract notions of
elegance of the cast rules isn't going to work out well --- we have
both spec requirements and backwards compatibility to worry about.
Now we do have the flexibility to alter the default contents of pg_cast
--- there could
Hi,
Tom Lane wrote:
I've committed this change with (for now) 100 as the minimum histogram
size to use. Stefan, are you interested in retrying your benchmark?
A first try with ltree gave big improvements on my smaller data set: the
estimated row count is correct or off by only 1 row. I'm
Jim C. Nasby wrote:
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
Merlin Moncure [EMAIL PROTECTED] writes:
ok, here is the promised docs for the advisory locks.
Applied with light editorialization.
some quick notes here: this is my first non trivial patch (albeit only
documentation) and i am a complete docbook novice.
Not bad for a first try --- I fixed a
One good thing about advisory locks having been in contrib was that they
didn't affect anyone who didn't actually install the module. Now that
we've put those functions in core, I wonder whether we don't need to
face up to the possibility of malicious use. For instance, it's not
very hard to
Bruce Momjian wrote:
Jim C. Nasby wrote:
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,
Mark Cave-Ayland [EMAIL PROTECTED] writes:
My main issue at the moment is that the code in transformFromClauseItem
seems a terrible hack, mainly because the grammar returns each string
within the FROM clause as a RangeVar, and transformFromClauseItem
assumes that each RangeVar represents a
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 9/21/06, Tom Lane [EMAIL PROTECTED] wrote:
One good thing about advisory locks having been in contrib was that they
didn't affect anyone who didn't actually install the module. Now that
we've put those functions in core, I wonder whether we don't need to
face up to the possibility of
Simon Riggs wrote:
On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
I have completed my first pass over the release notes and Tom has made
some additions:
http://momjian.postgresql.org/cgi-bin/pgrelease
I will probably go over them again in a few hours, update them to
All,
I vote for locking down to superuser access (lets be frank here: I
would estimate 90%+ database installatons run with the application as
root) so we are not losing much.
Not in my experience. Note that making them superuser-only pretty much puts
them out of the hands of hosted
Doesn't creating many temp tables in a transaction do the same thing?
---
Josh Berkus wrote:
All,
I vote for locking down to superuser access (lets be frank here: I
would estimate 90%+ database installatons run with
Usually the major items just jump out of the release list. In this
case, nothing really jumped out, and I felt if I listed sereral, it was
going to look weak because they were not big things, so I figured I
would just go with the broad list.
The criteria I usually use are things that were not
On Wed, 20 Sep 2006, Bruce Momjian wrote:
Doesn't creating many temp tables in a transaction do the same thing?
---
Like this?
jeremyd=# CREATE OR REPLACE FUNCTION testy(n integer) returns integer as $$
BEGIN
EXECUTE
Bruce,
What happened to PL/pgSQL debugging? Did it die?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining
96 matches
Mail list logo
