Re: [HACKERS] length coerce for bpchar is broken since 7.0

Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Before going further, may I ask you a question. Why in exprTypmod() is > bpchar() treated differently from other data types such as varchar? It's just hardwired knowledge about that particular datatype. In the light of your comments, it seems clear that

Re: [HACKERS] length coerce for bpchar is broken since 7.0

> > Simply clipping multibyte strings by atttypmode might produce > > incorrect multibyte strings. Consider a case inserting 3 multibyte > > letters (each consisting of 2 bytes) into a char(5) column. > > It seems to me that this means that atttypmod or exprTypmod() isn't > correctly defined for

Re: [HACKERS] length coerce for bpchar is broken since 7.0

Tatsuo Ishii <[EMAIL PROTECTED]> writes: If VARSIZE returned from exprTypmod() and atttypmod passed to coerce_type_typmod() is equal, the function node to call bpchar() would not be added. >> >> Um, what's wrong with that? Seems to me that parse_coerce is doing >> exactly what it'

Re: [HACKERS] length coerce for bpchar is broken since 7.0

> > If VARSIZE returned from exprTypmod() and atttypmod passed to > > coerce_type_typmod() is equal, the function node to call bpchar() > > would not be added. > > Um, what's wrong with that? Seems to me that parse_coerce is doing > exactly what it's supposed to, ie, adding only length coercions

Re: [HACKERS] pgsql is 75 times faster with my new index scan

> > TODO: > > - add HeapTupleHeaderData into each IndexTupleData > > - change code to reflect above > > - when deleting-updating heap then also update tuples' > > HeapTupleHeaderData in indices > > I doubt everyone would like trading query speed for insert/update > speed plus index size If he

Re: [HACKERS] "initdb -t" destroys all databases

Peter, comments? > Richard Poole <[EMAIL PROTECTED]> writes: > > It seems that initdb starts a single-user backend but gives it the "-x" > > option, which makes it call BootStrapXLOG, which fails because it > > expects to be called only on absolutely first-time system startup (?). > > initdb see

[HACKERS] Re: [COMMITTERS] pgsql/src/backend/utils/adt (formatting.c oracle_compat.c)

> > This effectively one line patch should fix the fact that > foreign key definitions in create table were erroring if > a primary key was defined. I was using the columns > list to get the columns of the table for comparison, but > it got reused as a temporary list inside the primary key > st

Re: [HACKERS] The lightbulb just went on...

The Hermit Hacker <[EMAIL PROTECTED]> writes: >> I will get this patch made up tonight for REL7_0; if Alfred doesn't >> see more failures after running it for a few days, then let's move >> forward on a 7.0.3 release. > that works for me ... I'm in Montreal for the weekend, so if we can get it >

Re: [HACKERS] psql's \d functions broken for views in current sources

Was this addressed? > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I assume this breakage is from the recent RELKIND_VIEW change; > >> probably psql didn't get updated to know about the new relkind. > > > Probably psql uses pg_views though I don't remember correctly. > > I

Re: [HACKERS] length coerce for bpchar is broken since 7.0

Tatsuo Ishii <[EMAIL PROTECTED]> writes: > If VARSIZE returned from exprTypmod() and atttypmod passed to > coerce_type_typmod() is equal, the function node to call bpchar() > would not be added. Um, what's wrong with that? Seems to me that parse_coerce is doing exactly what it's supposed to, ie,

[HACKERS] length coerce for bpchar is broken since 7.0

It seems the length coerce for bpchar is broken since 7.0. In 6.5 when a string is inserted, bpchar() is called to properly clip the string. However in 7.0 (and probably current) bpchar() is not called anymore. coerce_type_typmod() calls exprTypmod(). exprTypmod() returns VARSIZE of the bpchar d

Re: [HACKERS] fkey + primary key does not work in current

That's strange. I didn't see it. Can you send it over. The archives don't seem to be working again. > > I believe that I sent a patch on Sep 17 for this to -patches although > I don't know if anyone saw it (it's in the archives, so I know it > went through). > > Stephan Szabo > [EMAIL PROTEC

Re: [HACKERS] fkey + primary key does not work in current

I believe that I sent a patch on Sep 17 for this to -patches although I don't know if anyone saw it (it's in the archives, so I know it went through). Stephan Szabo [EMAIL PROTECTED] On Mon, 16 Oct 2000, Bruce Momjian wrote: > Has this been resolved? > > > On Fri, 15 Sep 2000, Tatsuo Ishii wro

Re: [HACKERS] The lightbulb just went on...

On Mon, 16 Oct 2000, Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > Something to force a v7.0.3 ... ? > > Yes. We had plenty to force a 7.0.3 already, actually, but I was > holding off recommending a release in hopes of finding Alfred's > problem. I thought so, about havin

Re: [HACKERS] Patch for TNS services

Patch applied. Can you send me the SGML diff? I will merge them in. > I've now prepared a polished and clean patch vs. 7.0.2. Who's gonna integrate > this patch in the CVS? I've no CVS access. > > The docs are another problem. I've installed jade and most other SGML stuff > here, but "make

RE: AW: [HACKERS] Backup, restore & pg_dump

At 15:07 16/10/00 -0700, Mikheev, Vadim wrote: > >So, pg_dump should be preserved asis. > Just to clarify; I have no intention of doing anything nasty to pg_dump. All I plan to do is rename the pg_restore to one of pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based restore utility,

Re: [HACKERS] The lightbulb just went on...

The Hermit Hacker <[EMAIL PROTECTED]> writes: > Something to force a v7.0.3 ... ? Yes. We had plenty to force a 7.0.3 already, actually, but I was holding off recommending a release in hopes of finding Alfred's problem. I will get this patch made up tonight for REL7_0; if Alfred doesn't see mor

Re: AW: [HACKERS] Backup, restore & pg_dump

At 00:12 17/10/00 +0200, Peter Eisentraut wrote: > >Btw., it will still be possible to restore, er, reload, with psql, right? > Correct. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/

Re: [HACKERS] Re: New relkind for views

Mark Hollomon <[EMAIL PROTECTED]> writes: I say let them drop it with either one. >> >> I kinda like the 'drop index with drop index', 'drop table with drop >> table' and 'drop view with drop view' groupings ... at least you are >> pretty sure you haven't 'oopsed' in the process :) > So th

Re: [HACKERS] The lightbulb just went on...

Something to force a v7.0.3 ... ? On Mon, 16 Oct 2000, Tom Lane wrote: > ... with a blinding flash ... > > The VACUUM funnies I was complaining about before may or may not be real > bugs, but they are not what's biting Alfred. None of them can lead to > the observed crashes AFAICT. > > What'

Re: [HACKERS] Re: New relkind for views

On Mon, Oct 16, 2000 at 08:41:43PM -0300, The Hermit Hacker wrote: > On Mon, 16 Oct 2000, Bruce Momjian wrote: > > > > "Hollomon, Mark" wrote: > > > > > > > > Do we still want to be able to inherit from views? > > > > > > Also: > > > > > > Currently a view may be dropped with either 'DROP VIEW

Re: [HACKERS] fkey + primary key does not work in current

Has this been resolved? > > On Fri, 15 Sep 2000, Tatsuo Ishii wrote: > > > It seems that foreign key does not work in current, if specified with > > primary key definition. Take a look at following example(works in > > 7.0.2.): > > > > test=# CREATE TABLE PKTABLE ( ptest1 int, ptest2 int, pte

RE: [HACKERS] Possible performance improvement: buffer replacemen t policy

Thanks. Vadim > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 16, 2000 5:40 PM > To: Mikheev, Vadim > Cc: 'Bruce Momjian'; [EMAIL PROTECTED] > Subject: Re: [HACKERS] Possible performance improvement: buffer > replacemen t policy > > > "Mikheev,

Re: [HACKERS] Possible performance improvement: buffer replacemen t policy

"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: >> Sounds like a perfect idea. Good luck. :-) > Hmm, how much time will be required? > I integrate WAL right now and have to do significant changes > in bufmgr... Don't worry about it, I am not planning to commit that code anytime soon. (I have oth

[HACKERS] The lightbulb just went on...

... with a blinding flash ... The VACUUM funnies I was complaining about before may or may not be real bugs, but they are not what's biting Alfred. None of them can lead to the observed crashes AFAICT. What's biting Alfred is the code that moves a tuple update chain, lines 1541 ff in REL7_0_PAT

RE: [HACKERS] Possible performance improvement: buffer replacement policy

> > It looks like it wouldn't take too much work to replace > > shared buffers on the basis of LRU-2 instead of LRU, so > > I'm thinking about trying it. > > > > Has anyone looked into this area? Is there a better method to try? > > Sounds like a perfect idea. Good luck. :-) Hmm, how much t

[HACKERS] Re: getting local domain to get attached through sendmail ...

I wonder how many "you're not allowed to post to this list" bounces I'll get from answering this... Please, when you send messages to sendmail.org, send them *only* there, not to various mailing lists as well. The Hermit Hacker <[EMAIL PROTECTED]> wrote: > I'm trying to get the committers m

Re: [HACKERS] Possible performance improvement: buffer replacement policy

> (If you subscribe to the ACM digital library, you can get a PDF of this > from there.) This article argues that standard LRU buffer management is > inherently not great for database caches, and that it's much better to > replace pages on the basis of time since the K'th most recent reference, >

Re: [HACKERS] Re: New relkind for views]

> On Mon, 16 Oct 2000, Bruce Momjian wrote: > > > > "Hollomon, Mark" wrote: > > > > > > > > Do we still want to be able to inherit from views? > > > > > > Also: > > > > > > Currently a view may be dropped with either 'DROP VIEW' > > > or 'DROP TABLE'. Should this be changed? > > > > I say let

Re: [HACKERS] Re: New relkind for views

On Mon, 16 Oct 2000, Bruce Momjian wrote: > > "Hollomon, Mark" wrote: > > > > > > Do we still want to be able to inherit from views? > > > > Also: > > > > Currently a view may be dropped with either 'DROP VIEW' > > or 'DROP TABLE'. Should this be changed? > > I say let them drop it with eithe

[HACKERS] Re: [GENERAL] PL/Perl compilation error

I can not apply this. Seems it has changed in the current tree. Here is the current plperl.c file. > Bruce Momjian wrote: > > > Can you send me a patch? > > > > > Hi, > > > > > > I have take a look to the source code concerning PL/Perl, it seems that 2 >variables > > > have a bad call : err

Re: AW: [HACKERS] Backup, restore & pg_dump

On Tue, 17 Oct 2000, Peter Eisentraut wrote: > Philip Warner writes: > > > >I like the pg_{import,export} names myself ... *nod* > > > > Sounds fine also; but we have compatibility issues in that we still need > > pg_dump. Maybe just a symbolic link to pg_export. > > I'm not so fond of changin

Re: [HACKERS] Indexing for geographical objects

We certainly would like to have them. Can you send a patch that applies against our current CVS snapshot. [ Charset ISO-8859-1 unsupported, converting... ] > Hi, > > I'm developping a geographical object type, very close to the geographic > type of PG. For the moment it is set up as external fu

Re: [HACKERS] minor fixes for regress

Applied and updated. > I wasn't too sure where to mail this. > > I have noticed that there are some identical files in > postgresql-7.0.2/src/test/regress/expected/ > > > diff float8-cygwin.out float8-small-is-zero.out #I recommend deleting > float8-cygwin.out > > diff geometry-cygwin-precisi

RE: AW: [HACKERS] Backup, restore & pg_dump

> >I like the pg_{import,export} names myself ... *nod* > > > > Sounds fine also; but we have compatibility issues in that we > still need pg_dump. Maybe just a symbolic link to pg_export. Yes, we still need in pg_dump, because of pg_dump is thing quite different from WAL based backup/restore.

Re: AW: [HACKERS] Backup, restore & pg_dump

> Philip Warner writes: > > > >I like the pg_{import,export} names myself ... *nod* > > > > Sounds fine also; but we have compatibility issues in that we still need > > pg_dump. Maybe just a symbolic link to pg_export. > > I'm not so fond of changing a long-established program name for the sake

Re: AW: [HACKERS] Backup, restore & pg_dump

Philip Warner writes: > >I like the pg_{import,export} names myself ... *nod* > > Sounds fine also; but we have compatibility issues in that we still need > pg_dump. Maybe just a symbolic link to pg_export. I'm not so fond of changing a long-established program name for the sake of ethymologica

Re: AW: [HACKERS] new relkind for view

TODO updated. > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Added to TODO> > >> > >> I think this is for new todo items: > >> create insert, update and delete rules for simple one table views > >> change elog for complex view ins|upd|del to "cannot {ins|upd|del} > >> [into|from] complex view w

Re: AW: [HACKERS] new relkind for view

Bruce Momjian <[EMAIL PROTECTED]> writes: > Added to TODO> >> >> I think this is for new todo items: >> create insert, update and delete rules for simple one table views >> change elog for complex view ins|upd|del to "cannot {ins|upd|del} >> [into|from] complex view without an on {ins|upd|del} ru

Re: AW: [HACKERS] Backup, restore & pg_dump

At 10:08 16/10/00 -0300, The Hermit Hacker wrote: > >I like the pg_{import,export} names myself ... *nod* > Sounds fine also; but we have compatibility issues in that we still need pg_dump. Maybe just a symbolic link to pg_export.

[HACKERS] Re: [BUGS] unique/references not honored when inheriting tables

AFAIK, yes. Inheriting unique constraints would be a special case of inheriting indexes theoretically, since I'd assume that inheriting a unique column should mean unique through entire inheritance tree. References is similar, we'd need to do something to inherit the triggers, and referencing

Re: AW: [HACKERS] new relkind for view

Added to TODO> [ Charset ISO-8859-1 unsupported, converting... ] > > > > 2. The executor complains if a DELETE or > > > INSERT references a view. > > I think this is for new todo items: > create insert, update and delete rules for simple one table views > change elog for complex v

Re: [PATCHES] Re: [HACKERS] when does CREATE VIEW not create a view?

On Mon, Oct 16, 2000 at 03:31:08PM -0500, Ross J. Reedstrom wrote: > On Mon, Oct 16, 2000 at 12:22:23PM -0400, Bruce Momjian wrote: > > OK, the bad news is that this does not apply to the current development > > tree. Ross, can you make a more corrent one? Sorry. > > I think it won't apply beca

Re: [HACKERS] when does CREATE VIEW not create a view?

On Mon, Oct 16, 2000 at 12:22:23PM -0400, Bruce Momjian wrote: > OK, the bad news is that this does not apply to the current development > tree. Ross, can you make a more corrent one? Sorry. I think it won't apply because it's already in there. There were also subsequent fixes to how pg_dump de

Re: [HACKERS] TODO list updates

Thanks. TODO updated. > > * Disallow LOCK on view > change to > * -Disallow LOCK on view (Mark H) > well, at least when my patch is applied :) > > > * Allow SQL function indexes > This seems to work in the CVS code, or I have misunderstood: > CREATE TABLE t ( a int); >

Re: [HACKERS] Re: ?????: ?????: WAL and indexes (Re: [HACKERS] WAL status& todo)

> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > > And how could I use such records on recovery > > being unable to know what data columns represent > > keys, what functions should be used for ordering? > > Um, that's not built into the index either, is it? OK, you win ... > > I'm still nervous

[HACKERS] Ответ: [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)

>> One of the purposes of WAL is immediate removing tuples >> inserted by aborted xactions. I want make VACUUM >> *optional* in future - space must be available for >> reusing without VACUUM. And this is first, very small, >> step in this direction. > >Why would vacuum become optional? Would WAL

[HACKERS] Re: Ответ: Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)

"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > And how could I use such records on recovery > being unable to know what data columns represent > keys, what functions should be used for ordering? Um, that's not built into the index either, is it? OK, you win ... I'm still nervous about how we're

[HACKERS] Ответ: Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)

>>> I don't understand why WAL needs to log internal operations of any of >>> the index types. Seems to me that you could treat indexes as black >>> boxes that are updated as side effects of WAL log items for heap tuples: >>> when adding a heap tuple as a result of a WAL item, you just call the >

Re: [HACKERS] Yet another LIKE-indexing scheme

> Can you give me a TODO item? * Fix LIKE indexing optimization for non-ASCII locales regards, tom lane

Re: [HACKERS] Isn't non-TEST_AND_SET code long dead?

> Mike Mascari <[EMAIL PROTECTED]> writes: > > On a somewhat related note, what about the NO_SECURITY defines > > strewn throughout the backend? Does anyone run the server with > > NO_SECURITY defined? And if so, what benefit is that over just > > running with everything owned by the same user? >

Re: [HACKERS] Yet another LIKE-indexing scheme

Can you give me a TODO item? > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Any status on this? > > Still broken, no known fix short of disabling LIKE optimization in > non-ASCII locales ... > > regards, tom lane > -- Bruce Momjian| http://

RE: AW: [HACKERS] ALTER TABLE DROP COLUMN

> Both options are in Oracle now, as proudly documented in their > freely accessible on-line documentation. It is very possible > they didn't implement it until version 8, i.e. until a couple of years > ago. FYI: ALTER TABLE DROP COLUMN was added as of 8 / 8i according to our Oracle DBA. - mer

[HACKERS] Re: [BUGS] unique/references not honored when inheriting tables

Is this still true in 7.1? > Helge Bahmann ([EMAIL PROTECTED]) reports a bug with a severity of 4 > The lower the number the more severe it is. > > Short Description > unique/references not honored when inheriting tables > > Long Description > If a table inherits fields carrying the "reference

Re: [HACKERS] Yet another LIKE-indexing scheme

Bruce Momjian <[EMAIL PROTECTED]> writes: > Any status on this? Still broken, no known fix short of disabling LIKE optimization in non-ASCII locales ... regards, tom lane

Re: [HACKERS] Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)

* Tom Lane <[EMAIL PROTECTED]> [001016 09:47] wrote: > "Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > >> I don't understand why WAL needs to log internal operations of any of > >> the index types. Seems to me that you could treat indexes as black > >> boxes that are updated as side effects of WAL

Re: [HACKERS] Yet another LIKE-indexing scheme

Any status on this? > Erich Stamberger <[EMAIL PROTECTED]> writes: > >> Our existing code fails because it generates WHERE name >= 'Czec' AND > >> name < 'Czed'; it will therefore not find names beginning 'Czech' > >> because those are in another part of the index, between 'Czeh' and > >> 'Czei'

[HACKERS] Re: Ответ: [HACKERS] Possible performance improvement: buffer replacement policy

"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > Excuse me but what is LRU-2? Like LRU, but using time to second most recent reference, instead of most recent reference, to sort the buffers for recycling. This gives a more robust statistic about how often the page is actually being touched. (Or t

Re: [HACKERS] Full text indexing (Question/request)

See contrib/fulltextindex. [ Charset ISO-8859-1 unsupported, converting... ] > I didn't see any mention of it on the TODO so I thought I'd ask if anyone > had thought about full test indexing for 7.1 (I'm guessing not).. > > If not, I'd like to suggest it be put on the TODO -- if nothing else so

[HACKERS] Re: Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)

"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: >> I don't understand why WAL needs to log internal operations of any of >> the index types. Seems to me that you could treat indexes as black >> boxes that are updated as side effects of WAL log items for heap tuples: >> when adding a heap tuple as a

Re: [HACKERS] INHERITS doesn't offer enough functionality

* Bruce Momjian <[EMAIL PROTECTED]> [001016 08:55] wrote: > > Alfred Perlstein wrote: > > > > > > I noticed that INHERITS doesn't propogate indecies, It'd be nice > > > if there was an toption to do so. > > > > Yep it would. Are you volunteering? > > > > Added to TODO: > > * Allow inher

Re: [HACKERS] Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)

* Mikheev, Vadim <[EMAIL PROTECTED]> [001016 09:33] wrote: > >I don't understand why WAL needs to log internal operations of any of > >the index types. Seems to me that you could treat indexes as black > >boxes that are updated as side effects of WAL log items for heap tuples: > >when adding a he

[HACKERS] Ответ: [HACKERS] New file naming

Great & Thanks! And then we'll have to log all files to be removed as part of xaction commit record. Vadim > - éÓÈÏÄÎÏÅ ÓÏÏÂÝÅÎÉÅ - > ïÔ: Tom Lane [SMTP:[EMAIL PROTECTED]] > ïÔÐÒÁ×ÌÅÎÏ: 16 ieoya?y 2000 a. 8:59 > ëÏÍÕ: Mikheev, Vadim > ëÏÐÉÑ:[EM

[HACKERS] Full text indexing (Question/request)

I didn't see any mention of it on the TODO so I thought I'd ask if anyone had thought about full test indexing for 7.1 (I'm guessing not).. If not, I'd like to suggest it be put on the TODO -- if nothing else so someone could pick it up in the far future if they wanted to.. It doesn't seem like t

[HACKERS] Ответ: [HACKERS] Possible performance improvement: buffer replacement policy

Excuse me but what is LRU-2? I know that in Oracle unused buffers are not in simple LRU list: Oracle tries to postpone writes as long as possible -:) Vadim > - éÓÈÏÄÎÏÅ ÓÏÏÂÝÅÎÉÅ - > ïÔ: Tom Lane [SMTP:[EMAIL PROTECTED]] > ïÔÐÒÁ×ÌÅÎÏ: 16 ieoya?y 2000 a. 8:50 > ëÏÍÕ:

[HACKERS] Ответ: WAL and indexes (Re: [HACKERS] WAL status & todo)

>I don't understand why WAL needs to log internal operations of any of >the index types. Seems to me that you could treat indexes as black >boxes that are updated as side effects of WAL log items for heap tuples: >when adding a heap tuple as a result of a WAL item, you just call the >usual index

Re: [HACKERS] Re: New relkind for views

> "Hollomon, Mark" wrote: > > > > Do we still want to be able to inherit from views? > > Also: > > Currently a view may be dropped with either 'DROP VIEW' > or 'DROP TABLE'. Should this be changed? I say let them drop it with either one. -- Bruce Momjian| http://c

Re: [HACKERS] selective fsync?

WAL should supersede all these concerns about fsync. At the very least, it changes the tradeoffs enough that there's no point in designing performance improvements based on the old code... regards, tom lane

Re: [HACKERS] when does CREATE VIEW not create a view?

OK, the bad news is that this does not apply to the current development tree. Ross, can you make a more corrent one? Sorry. > On Tue, Aug 29, 2000 at 10:12:38AM +0900, [EMAIL PROTECTED] wrote: > > > > Oh, the patch strikes me since it is not "multibyte aware." > > O.K. - > Here's the multiby

Re: AW: [HACKERS] My new job

Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > One thing that comes to my mind is, that you (core members) working full > time on PG will produce so much work, that we "hobby PgSQL'ers" will > have a hard job in keeping up to date. When core was first talking to the Great Bridge folks, one

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

On Mon, Oct 16, 2000 at 06:51:10PM +1100, Chris wrote: > KuroiNeko wrote: > > > 1 create table alpha( id int4, payload text ); > > > > Not a big deal, right? > > Yes a big deal. You just lost all your oids. Been there. Done that. Learned to heed the warnings about using oids in any

Re: [HACKERS] New file naming

"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > ALTER TABLE RENAME is rollback-able now. I think that > it's very easy to make DROP TABLE rollback-able too > (file should be removed after xaction committed) but > I have no time to deal with this currently. I will make sure that works before releas

[HACKERS] selective fsync?

I'm wondering how useful it would be if one could enable selective fsync. That would mean that although the database was running async mode, the system tables and doing things like create index would cause an fsync to enforce ordering in case of a crash. This would prevent more serious problems

Re: [HACKERS] INHERITS doesn't offer enough functionality

> Alfred Perlstein wrote: > > > > I noticed that INHERITS doesn't propogate indecies, It'd be nice > > if there was an toption to do so. > > Yep it would. Are you volunteering? > Added to TODO: * Allow inherited tables to inherit index -- Bruce Momjian| ht

Re: [HACKERS] Possible performance improvement: buffer replacement policy

Bruce Momjian <[EMAIL PROTECTED]> writes: >> It looks like it wouldn't take too much work to replace shared buffers >> on the basis of LRU-2 instead of LRU, so I'm thinking about trying it. >> >> Has anyone looked into this area? Is there a better method to try? > Sounds like a perfect idea. G

Re: [HACKERS] snapshots ...

The Hermit Hacker writes: > ... should be working again. I hard coded the path so that it finds > bison, which appears to be what was killing it ... That sounds suspiciously like the respective cron user not having /usr/local/bin is its path. -- Peter Eisentraut [EMAIL PROTECTED] h

Re: Precedence of '|' operator (was Re: [HACKERS] [patch,rfc] binary operators on integers)

Thomas Lockhart <[EMAIL PROTECTED]> writes: > I'd like to see closer adherence to the "usual" operator precedence. But > I really *hate* having to explicitly call out each rule in the a_expr, > b_expr, and/or c_expr productions. Any way around this? It's not easy in yacc/bison, I don't believe.

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

> > Not a big deal, right? > > Yes a big deal. You just lost all your oids. After I hit the wall with oids for the first time, I don't refer to them anymore :) But yes, you're perfectly right, this is one more reason to have DDL completely `automated,' ie no manual substitutions. And here th

[HACKERS] New file naming

is implemented. Regression tests are passed. make distclean + initdb are required. Now all file/dir names are numeric. OIDs are used for databases *and* relations on creation, but relation file names may be changed later if required (separate from oid pg_class.relfilenode field is used). ALTER T

AW: [HACKERS] My new job

> > >Bottom line is we're not sure what to do now. Opinions from the > > >floor, anyone? One thing that comes to my mind is, that you (core members) working full time on PG will produce so much work, that we "hobby PgSQL'ers" will have a hard job in keeping up to date. Thus you will have to be

WAL and indexes (Re: [HACKERS] WAL status & todo)

"Vadim Mikheev" <[EMAIL PROTECTED]> writes: > 3. There are no redo/undo for HASH, RTREE & GIST yet. This would be *really > really > great* if someone could implement it using BTREE' redo/undo code as > prototype. > These are the most complex parts of this todo. I don't understand why WAL

[HACKERS] 7.1 and ecpg

What exactly do we do with 7.1 on Nov 1st? Freeze or release? I'm absolutely sure I won't finish ecpg until Nov 1st. Yes, I know I had similar problems with 7.0, but real life tends to take away too much time. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU

AW: AW: AW: [HACKERS] ALTER TABLE DROP COLUMN

> I think we do, because it solves more than just the ALTER DROP COLUMN > problem: it cleans up other sore spots too. Like ALTER TABLE ADD COLUMN > in a table with child tables. Yes, could also implement "add column xx int before someothercolumn" to add a column in the middle. Andreas

Re: Precedence of '|' operator (was Re: [HACKERS] [patch,rfc] binary operators on integers)

> Well, that's a good point --- it isn't going to get any less painful to > fix it later. Do we want to just remove the special treatment of '|' > and let it become one with the undifferentiated mass of Op, or do we > want to try to set up reasonable precedence for all the bitwise > operators (an

RE: AW: [HACKERS] ALTER TABLE DROP COLUMN

At 10:56 PM 10/15/00 +0900, Hiroshi Inoue wrote: >When I used Oracle,I saw neither option of DROP COLUMN >feature. It seems to tell us that the implementation isn't >that easy. It may not be a bad choise to give up DROP >COLUMN feature forever. Both options are in Oracle now, as proudly documen

[HACKERS] Re: pgsql-committers list definitely wedged

On Mon, 16 Oct 2000, Tom Lane wrote: > > but I see at ftp://ftp.postgresql.org/pub/dev/ that the nightly > > snapshot hasn't updated since Monday either. > > As of this morning, it looks like the tar.gz files all got updated > at 4AM EDT last night, but to judge by timestamps, the associated > .

Re: [HACKERS] bytea type

[ Charset ISO-8859-1 unsupported, converting... ] > I found bytea doing a \dT in psql, but I do not find any documentation on > it. > > Could I have some source code implementation of bytea with examples ? Yes, it is like text, but you can put in binary data as 'a\\000b' puts a, null, b. --

Re: AW: [HACKERS] Backup, restore & pg_dump

I like the pg_{import,export} names myself ... *nod* On Mon, 16 Oct 2000, Zeugswetter Andreas SB wrote: > > > > > As a result do people have any objection to changing pg_restore to > > > > pg_undump? Or pg_load? > > Also possible would be a name like Oracle > pg_exp and pg_imp for export and

AW: [HACKERS] analyze.c

> > I've been reading something about implementation of histograms, and, > > AFAIK, in practice histograms is just a cool name for no more than: > >1. top ten with frequency for each > >2. the same for top ten worse > >3. average for the rest Consider, that we only need that info for

[HACKERS] bytea type

I found bytea doing a \dT in psql, but I do not find any documentation on it. Could I have some source code implementation of bytea with examples ? Franck Martin Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED]

AW: AW: [HACKERS] ALTER TABLE DROP COLUMN

> This style of "DROP COLUMN" would change the attribute > numbers whose positons are after the dropped column. > Unfortunately we have no mechanism to invalidate/remove > objects(or prepared plans) which uses such attribute numbers. > And I've seen no proposal/discussion to solve this problem >

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Chris wrote: > > Hiroshi Inoue wrote: > > > When I used Oracle,I saw neither option of DROP > > COLUMN feature. It seems to tell us that the > > implementation isn't > > that easy. It may not be a bad choise to give up DROP > > COLUMN feature forever. > > Because it's not easy we shouldn't do i

AW: [HACKERS] Backup, restore & pg_dump

> > > As a result do people have any objection to changing pg_restore to > > > pg_undump? Or pg_load? Also possible would be a name like Oracle pg_exp and pg_imp for export and import. (or pg_export and pg_import) Load and unload is often more tied to data only (no dml). I agree that the curre

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Hiroshi Inoue wrote: > We could easily break the consistency of DB due to > careless implementations. I'm sure no-one around here would do careless implementations. :-)

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Chris wrote: > Hiroshi Inoue wrote: > > > When I used Oracle,I saw neither option of DROP > > COLUMN feature. It seems to tell us that the > > implementation isn't > > that easy. It may not be a bad choise to give up DROP > > COLUMN feature forever. > > Because it's not easy we shouldn't do it?

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Hiroshi Inoue wrote: > Certainly it would need 2x. > However is ADD COLUMN DEFAULT really needed ? > I would do as follows. > > ADD COLUMN (without default) > UPDATE .. SET new_column = new default > ALTER TABLE ALTER COLUMN SET DEFAULT Well in current postgres that would use 2x. Wi

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Chris wrote: > Hiroshi Inoue wrote: > > > When I used Oracle,I saw neither option of DROP > > COLUMN feature. It seems to tell us that the > > implementation isn't > > that easy. It may not be a bad choise to give up DROP > > COLUMN feature forever. > > Because it's not easy we shouldn't do it?

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

Hiroshi Inoue wrote: > When I used Oracle,I saw neither option of DROP > COLUMN feature. It seems to tell us that the > implementation isn't > that easy. It may not be a bad choise to give up DROP > COLUMN feature forever. Because it's not easy we shouldn't do it? I don't think so. The perfect

Re: AW: [HACKERS] ALTER TABLE DROP COLUMN

KuroiNeko wrote: > 1 create table alpha( id int4, payload text ); > Not a big deal, right? Yes a big deal. You just lost all your oids.

Re: AW: AW: [HACKERS] ALTER TABLE DROP COLUMN

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > >> This said, I think Hiroshi's patch seems a perfect starting point, no ? > > > Having phantom columns adds additional complexity to the system overall. > > We have to decide we really want it before making things more complex > > th

  1   2   >