Re: [HACKERS] 'configure --disable-shared' and 'make check'

Peter Eisentraut 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. So that is working as designed. I interpret that as 'static builds for the database server are not supported'.

Re: [HACKERS] Release Notes: Major Changes in 8.2

Simon Riggs napsal(a): Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry) Overhead of statistics collection has been considerably reduced and new statistics and system information is available. Better query logging improves diagnostics and especially performance tunin

Re: [HACKERS] Release Notes: Major Changes in 8.2

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 column

Re: [HACKERS] advisory locks and permissions

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 EXECUT

Re: [HACKERS] Release Notes: Major Changes in 8.2

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

Re: [HACKERS] advisory locks and permissions

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

Re: [HACKERS] advisory locks and permissions

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 appli

Re: [HACKERS] Release notes

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

Re: [HACKERS] advisory locks and permissions

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 malici

Re: [HACKERS] advisory locks and permissions

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 f

Re: [HACKERS] [PATCHES] WIP: Hierarchical Queries - stage 1

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

Re: [HACKERS] Release notes

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 fu

[HACKERS] advisory locks and permissions

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 crea

Re: [HACKERS] [PATCHES] docs for advisory locks

"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 fi

Re: [HACKERS] Release notes

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 ju

Re: [HACKERS] -HEAD planner issue wrt hash_joins on dbt3 ?

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 now

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

> 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 c

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 bei

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

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

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

"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 requ

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

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)

Re: [HACKERS] Phantom Command ID

"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 sw

Re: [HACKERS] Phantom Command ID

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

Re: [HACKERS] Units in postgresql.conf.sample

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 ---

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

Martijn van Oosterhout 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 required to write

Re: [HACKERS] [PATCHES] Include file in regress.c

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 > .cvs

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 > pre

Re: [HACKERS] [PATCHES] Include file in regress.c

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 Entr

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

"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 y

Re: [HACKERS] Units in postgresql.conf.sample

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 > > #w

Re: [HACKERS] Phantom Command ID

"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 lim

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

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

[HACKERS] Units in postgresql.conf.sample

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 cours

Re: [HACKERS] Release notes

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

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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

Re: [HACKERS] Phantom Command ID

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

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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

Re: [HACKERS] Phantom Command ID

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 struc

Re: [HACKERS] 'configure --disable-shared' and 'make check'

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 broadcast)--

Re: [HACKERS] -HEAD planner issue wrt hash_joins on dbt3 ?

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 >>

Re: [HACKERS] pg_upgrade: downgradebility

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 might

[HACKERS] Phantom Command ID

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 table

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 t

Re: [HACKERS] Release Notes: Major Changes in 8.2

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 Pro

Re: [HACKERS] Lock partitions

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 plau

Re: [HACKERS] Lock partitions

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 cau

Re: [HACKERS] Release Notes: Major Changes in 8.2

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 dist

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 SAF

Re: [HACKERS] Release Notes: Major Changes in 8.2

"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

Re: [HACKERS] Lock partitions

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 ru

Re: [HACKERS] pdfs of the conference

> > 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 be

Re: [HACKERS] Release Notes: Major Changes in 8.2

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 data

Re: [HACKERS] Release Notes: Major Changes in 8.2

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? N

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 cleane

Re: [HACKERS] Release Notes: Major Changes in 8.2

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

Re: [HACKERS] Release notes

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 mo

Re: [HACKERS] Bitmap index status

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. >>> >>

Re: [HACKERS] [PATCHES] setseed() doc

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 g

[HACKERS] Release Notes: Major Changes in 8.2

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:

Re: [HACKERS] [PATCHES] setseed() doc

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 chang

Re: [HACKERS] Truncation of email subject lines

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 i

Re: [HACKERS] pdfs of the conference

> > >> The larger version is only hidden from everyone :) > > >> > > >> > > http://people.planetpostgresql.org/mha/uploads/photo/conf/conf > > erence_group.jpg > > >> > > > ference_group.jpg> > > >> > > > > > > Very cool, I was hoping

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 o

Re: [HACKERS] TODO: Fix CREATE CAST on DOMAINs

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 o

Re: [HACKERS] pdfs of the conference

> -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 Chr

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

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. Th

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

[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 t

Re: [HACKERS] pdfs of the conference

> -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 larg

Re: [HACKERS] system cache and buffer cache

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. --

Re: [HACKERS] pdfs of the conference

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 Very cool, I was hoping someone

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

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? UUI

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

> 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

[HACKERS] TODO: Fix CREATE CAST on DOMAINs

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: http://archives.postgresql.org/pgsql-hackers/2006-0

Re: [HACKERS] pdfs of the conference

Walter Cruz wrote: The larger version is only hidden from everyone :) http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg Very cool, I was hoping someone would post this. Any chance we

Re: [HACKERS] Opinion wanted on UUID/GUID datatype output formats.

> 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

Re: guc comment changes (was Re: [HACKERS] Getting a move on for 8.2

Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: That does not mean that the patch is bad, and I certainly support the feature change. But I can't efficiently review the patch. If someone else wants to do it, go ahead. I've finally taken a close look at this patch, and I don't l

Re: [HACKERS] Opinion wanted on UUID/GUID datatype output formats.

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

Re: [HACKERS] pg_upgrade: downgradebility

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 set

Re: [HACKERS] pg_upgrade: downgradebility

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

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

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 rememb

Re: [HACKERS] Release notes

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

Re: [HACKERS] pg_upgrade: downgradebility

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

Re: [HACKERS] polite request about syntax

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)

Re: [pgsql-www] [HACKERS] Developer's Wiki

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 wishl

Re: [HACKERS] pg_upgrade: downgradebility

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.

[HACKERS] pg_upgrade: downgradebility

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 sho

Re: [HACKERS] minor feature request: Secure defaults during

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

Re: [HACKERS] [PATCHES] Include file in regress.c

> > 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 > > > ===

Re: [pgsql-www] [HACKERS] Developer's Wiki

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 >

Re: [HACKERS] Truncation of email subject lines

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 >

Re: [HACKERS] Truncation of email subject lines

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 o

Re: [HACKERS] minor feature request: Secure defaults during

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 I

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

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 sup

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

[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 databa

[HACKERS] 'configure --disable-shared' and 'make check'

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: "/postgres/cvs/pgsql/src/test/regress

Re: [HACKERS] [COMMITTERS] pgsql: Remove completed TODO items: < * -Make postmater

< * -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

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

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 i