Re: [HACKERS] Ranges for well-ordered types

On Jun 11, 2006, at 14:45 , Bruno Wolff III wrote: On Sun, Jun 11, 2006 at 10:18:11 +0900, Michael Glaesemann <[EMAIL PROTECTED]> wrote: Time (and timestamp) is a bit of a issue conceptually. The "default" successor function would depend on the precision of the timestamp. And in the ideal

Re: [HACKERS] Ranges for well-ordered types

On Jun 11, 2006, at 10:57 , Jim C. Nasby wrote: On Sun, Jun 11, 2006 at 10:18:11AM +0900, Michael Glaesemann wrote: Under design I proposed, closed-closed and closed-open are just two different representations of the same range: to the commonly used notation, the closed-open range [p1, p2) is

Re: [HACKERS] Ranges for well-ordered types

On Sun, Jun 11, 2006 at 10:18:11 +0900, Michael Glaesemann <[EMAIL PROTECTED]> wrote: > > Time (and timestamp) is a bit of a issue conceptually. The "default" > successor function would depend on the precision of the timestamp. And in the ideal case it doesn't exist. That is why I think a c

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Well, the argument against changing pg_dump is that it would impact the ability to use the newer version of pg_dump with older backends (which would be lacking these functions). ISTM what would be best is to add the functions to the backend, and add a TODO or comments to pg_dump indicating that

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Tom Lane said: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> O.k. so now what I am getting from this thread is, the functions exist >> now in pg_dump but we want to pull them out of pg_dump and push them >> into the backend? > > That's exactly what I *don't* want to do. If you can think of a

Re: [HACKERS] Ranges for well-ordered types

On Sun, Jun 11, 2006 at 10:18:11AM +0900, Michael Glaesemann wrote: > > On Jun 11, 2006, at 5:15 , Bruno Wolff III wrote: > > >I think you might want to reconsider your design. It works well for > >dates > >because sets of dates are made of of isolated points and such sets are > >both open and

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

On Sat, Jun 10, 2006 at 07:33:54PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > > O.k. so now what I am getting from this thread is, the functions exist > > > now in pg_dump but we want to pull them out of pg_dump and push them > > > into the

Re: [HACKERS] Ranges for well-ordered types

On Jun 11, 2006, at 5:15 , Bruno Wolff III wrote: I think you might want to reconsider your design. It works well for dates because sets of dates are made of of isolated points and such sets are both open and closed. If you are using time, I think it will be more convenient to use a closed

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > O.k. so now what I am getting from this thread is, the functions exist > > now in pg_dump but we want to pull them out of pg_dump and push them > > into the backend? > > That's exactly what I *don't* want to do. If you can thin

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: O.k. so now what I am getting from this thread is, the functions exist now in pg_dump but we want to pull them out of pg_dump and push them into the backend? That's exactly what I *don't* want to do. If you can think of a use-case

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > O.k. so now what I am getting from this thread is, the functions exist > now in pg_dump but we want to pull them out of pg_dump and push them > into the backend? That's exactly what I *don't* want to do. If you can think of a use-case for these fu

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Joshua D. Drake wrote: > > >> Maybe I am misunderstanding the TODO (which is entirely possible due to > >> the complete lack of documentation on the feature) but I *thought* all I > >> was going to do was create 6 functions that could be called to get > >> various useful information? > >> > >>

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Maybe I am misunderstanding the TODO (which is entirely possible due to the complete lack of documentation on the feature) but I *thought* all I was going to do was create 6 functions that could be called to get various useful information? For example, pg_get_tabledef() would be a very handy

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Joshua D. Drake wrote: > Tom Lane wrote: > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >> So could I get some further definition? > > > > There are two fairly strong reasons for NOT trying to push more logic > > into the backend from pg_dump: > > > > 1. It would remove the freedom we curren

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: So could I get some further definition? There are two fairly strong reasons for NOT trying to push more logic into the backend from pg_dump: 1. It would remove the freedom we currently have to make pg_dump adapt dumps from old serv

Re: [HACKERS] Ranges for well-ordered types

On Sat, Jun 10, 2006 at 23:51:58 +0900, Michael Glaesemann <[EMAIL PROTECTED]> wrote: > Each row of this table represents the time range (from from_date to > to_date) during which a teacher was assigned to a particular school. > (Teachers can be assigned to more than one school at a time.) Th

Re: [HACKERS] bison version

ohp@pyrenet.fr wrote: > Hi, > > I'd like to check 2 things: > > What's the bison version required to compile gram.y ? > Trying to set up a build farm machine, it seems I can't compile with bison > 2.1 ... 1.875 > Also where is the documentation page that gives postgresql limits (number > of col

Re: [HACKERS] bison version

ohp@pyrenet.fr wrote: > Hi, > > I'd like to check 2 things: > > What's the bison version required to compile gram.y ? > Trying to set up a build farm machine, it seems I can't compile with bison > 2.1 ... 2.1 should work fine - there are a number of boxes on the buildfarm running with that versi

[HACKERS] bison version

Hi, I'd like to check 2 things: What's the bison version required to compile gram.y ? Trying to set up a build farm machine, it seems I can't compile with bison 2.1 ... Also where is the documentation page that gives postgresql limits (number of column/table max size of col) Many thanks --

Re: [HACKERS] That EXPLAIN ANALYZE patch still needs work

> "MvO" == Martijn van Oosterhout writes: MvO> What we want is just a monotonically increasing counter that can MvO> be read quickly and consistantly, we're not majorly fussed if it MvO> doesn't match real time. This puts us back to CPU cycle counters, MvO> but they have drawbacks of their ow

Re: [HACKERS] That EXPLAIN ANALYZE patch still needs work

Greg Stark <[EMAIL PROTECTED]> writes: > There seem to be two types of overhead going on. There's the amount of time > spent in gettimeofday itself which is pretty consistent. That is a fact not in evidence. The impression I had from that linux-kernel discussion was that the problematic kernel co

Re: [HACKERS] How to avoid transaction ID wrap

Martijn van Oosterhout writes: > That's why people suggest partitions. Then you only vacuum the > partitions that are new and the old ones never need to be touched... This will all work a lot better once we track XID wraparound risk on a per-table rather than per-database basis. I hope that will

Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > So could I get some further definition? There are two fairly strong reasons for NOT trying to push more logic into the backend from pg_dump: 1. It would remove the freedom we currently have to make pg_dump adapt dumps from old servers to match newer

Re: [HACKERS] [PATCHES] ADD/DROP INHERITS

Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > Maybe it would be better to set attislocal=0 if the attinhcount goes from > > 0->1? > > That just moves the surprises to other cases. Sure, but if we're not allowing new columns to be created, those surprise cas

Re: [HACKERS] That EXPLAIN ANALYZE patch still needs work

Martijn van Oosterhout writes: > The interesting thing about this is that they obviously are gearing > gettimeofday() to be accurate, rather than just considering it a > counter that is somewhat close to real time. At the expense of speed. Not sure that that's an accurate description. What I thi

Re: [HACKERS] That EXPLAIN ANALYZE patch still needs work

Martijn van Oosterhout writes: > Right now I'm confused though. I was under the impression the changes > were going to be ripped out because it was decided to be unworkable. I > think improvements can be made but I'm unsure if there's any > interest... I've reverted the current patch because it c

Re: [HACKERS] [PATCHES] ADD/DROP INHERITS

Greg Stark <[EMAIL PROTECTED]> writes: > Maybe it would be better to set attislocal=0 if the attinhcount goes from > 0->1? That just moves the surprises to other cases. I think I'd prefer to err in the direction that can't cause unexpected data loss (due to columns being dropped that perhaps shou

Re: [HACKERS] Ranges for well-ordered types

On Jun 11, 2006, at 2:34 , Michael Glaesemann wrote: On Jun 11, 2006, at 0:54 , Ian Caulfield wrote: I've done similar date range things by creating a composite type consisting of the lower and upper bounds, and then implementing a btree opclass where the comparator returns 0 if two range

Re: [HACKERS] Ranges for well-ordered types

On Jun 11, 2006, at 0:54 , Ian Caulfield wrote: I've done similar date range things by creating a composite type consisting of the lower and upper bounds, and then implementing a btree opclass where the comparator returns 0 if two ranges overlap - this allows a current btree index to enfor

Re: [HACKERS] [PATCHES] ADD/DROP INHERITS

Also a couple other thoughts: I have a bit of uneasiness about the "use the first hole" method for adding parents. Namely it makes the whole thing a bit unpredictable from the user's point of view. The holes aren't user visible so they have no way to know when they add a parent where in the list

Re: [HACKERS] Ranges for well-ordered types

On Jun 10, 2006, at 23:51 , Michael Glaesemann wrote: A range can be formed for any point type, where a point type is any type that's well-ordered: * the range of values is bounded (the number of values in the type is finite) * comparisons are well-defined for any two values, and

Re: [HACKERS] Ranges for well-ordered types

Ian Caulfield wrote: On 6/10/06, *Michael Glaesemann* <[EMAIL PROTECTED] > wrote: Returning to my original example, with a "date_range" type, the table could be defined as: create table teachers__schools_2 ( teacher text not null , sc

Re: [HACKERS] Latest timezone data in 8.1.4

On Sat, Jun 10, 2006 at 05:44:37AM -0700, Paul Lindner wrote: > Some questions... > > * Is this the correct way to do this? It's as good a way as any. I have on occasion considered linking the postgres timezone data to the system timezone data, solving this problem. > * Can updating the ti

Re: [HACKERS] Ranges for well-ordered types

"Ian Caulfield" <[EMAIL PROTECTED]> writes: > I've done similar date range things by creating a composite type consisting > of the lower and upper bounds, and then implementing a btree opclass where > the comparator returns 0 if two ranges overlap - this allows a current btree > index to enforce no

Re: [HACKERS] How to avoid transaction ID wrap

On Fri, Jun 09, 2006 at 06:20:21PM -0700, Trent Shipley wrote: > VACCUM needs to be run for two reasons. > 1) To recover the transaction counter. > 2) To recover records marked for deletion. > > VACCUM needs to be run over the entire database. If the data in the database > is N, then VACCUM is O

Re: [HACKERS] Ranges for well-ordered types

On 6/10/06, Michael Glaesemann <[EMAIL PROTECTED]> wrote: Returning to my original example, with a "date_range" type, the tablecould be defined as: create table teachers__schools_2(teacher text not null, school text not null, period date_range not null, primary key (teacher, schoo

[HACKERS] Ranges for well-ordered types

I've been interested in representing and manipulating time ranges in PostgreSQL, where a time range is defined by a start time and an end time. Time ranges are useful, for example, in representing when some predicate was known valid. Similarly, time ranges can be used to represent "transact

[HACKERS] Latest timezone data in 8.1.4

Hi, At work, our production 8.1.x systems were having problems with timezones. A new code push had newer 2006 time zones that Postgres didn't recognize. To fix this I built a custom RPM that overwrites the timezone data with the latest data from nih.gov. I changed the postgres-8.1.4-1PDG.spe

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: 09 June 2006 17:01 > To: Mark Cave-Ayland > Cc: 'Tom Lane'; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Proposal for debugging of server-side stored > procedures (cut) > Debugging embedded perl has so

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Thomas Hallgren [mailto:[EMAIL PROTECTED] > Sent: 09 June 2006 16:25 > To: Mark Cave-Ayland > Cc: pgsql-hackers@postgresql.org > Subject: Re: Proposal for debugging of server-side stored procedures > > Some thoughts from another Tom... Hi Tom, Thanks for the