Re: [INTERFACES] [pgaccess-users] RE: [HACKERS]bugzilla.pgaccess.org
Changing data types probably won't appear. I don't know of anyone working on it -- and it can be quite a complex issue to get a good (resource friendly and transaction safe) version. I'd be happy with a non-resource friendly and non-transaction-safe version over not having the functionality at all... ;) Certain (imho common) cases could be short circuited to only manipulate the column definition (including default value), like alter varchar(10) to varchar(20), or decimal(10) to decimal(20), or even varchar(10) to varchar(5) (which would need to select all rows, and check that none is actually longer than 5, or abort). That is what I have seen other db's do. Do it inplace where it is easily possible, else do a long transaction that rewrites the content. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bugzilla.pgaccess.org
In reply to Hannu Krosing Iavor Raytchev wrote: How hard will the migration from MySQLzilla to PostgreSQLzilla be ? Is this a rhetoric question? I have no idea. A posting I saw (by one of the Bugzilla guys, I think) required something to be done in PostgreSQL before they can migrate - something exactly related to the issue of upgrading from one Bugzilla version to another. I have included pgsql-hackers again, where this discussion originally started crossposted. Hannu's question is absolutely not rhetoric. I see a concern about using a MySQL based tool for PostgreSQL related project management on a public site in it. The Bugzilla project plans to support PostgreSQL in one of their future releases, but this requires functionality in PostgreSQL, that is not even scheduled for 7.3. So the availability of a supported PostgreSQL port of Bugzilla is unpredictable at this time. My opinion is that a project as closely related to PostgreSQL as pgaccess should try to use PostgreSQL backed management tools. The switch to PHP BugTracker or something else at this time would be easiest, since the Bugzilla installation on pgaccess.org is virgin and does not contain any data yet. This is reason why I suggested that switch when you asked for comments originally. And I have not yet seen any argument against it, nor any reason why to start off with a MySQL based Bugzilla version now. Especially when there are equivalent solutions using PostgreSQL available. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bugzilla.pgaccess.org
The Bugzilla project plans to support PostgreSQL in one of their future releases, but this requires functionality in PostgreSQL, that is not even scheduled for 7.3. So the availability of a supported PostgreSQL port of Bugzilla is unpredictable at this time. I think he said that they needed DROP COLUMN functionality, which is being worked on for 7.3. (Although I haven't had time to work on it for a few days) Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bugzilla.pgaccess.org
Christopher Kings-Lynne wrote: The Bugzilla project plans to support PostgreSQL in one of their future releases, but this requires functionality in PostgreSQL, that is not even scheduled for 7.3. So the availability of a supported PostgreSQL port of Bugzilla is unpredictable at this time. I think he said that they needed DROP COLUMN functionality, which is being worked on for 7.3. (Although I haven't had time to work on it for a few days) DROP COLUMN is the one we might solve in 7.3. ALTER COLUMN ... TYPE was mentioned too and I don't know when or how we will have that one. REPLACE INTO is one more. Though you can work around it. If you setup a BEFORE INSERT trigger, in which you do a table lock, then try to UPDATE an existing row with NEW's key. If that succeeds, you return NULL, suppressing the INSERT. If it fails, you return NEW letting the INSERT happen. The table lock (what Bradley called heavy locking) is required because otherwise someone can sneak in between your update attempt and letting the INSERT happen, getting exactly the same result and ... boom, duplicate key error. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] bugzilla.pgaccess.org
Jan Wieck wrote: Christopher Kings-Lynne wrote: The Bugzilla project plans to support PostgreSQL in one of their future releases, but this requires functionality in PostgreSQL, that is not even scheduled for 7.3. So the availability of a supported PostgreSQL port of Bugzilla is unpredictable at this time. I think he said that they needed DROP COLUMN functionality, which is being worked on for 7.3. (Although I haven't had time to work on it for a few days) DROP COLUMN is the one we might solve in 7.3. ALTER COLUMN ... TYPE was mentioned too and I don't know when or how we will have that one. Christopher plans to work on that when he is done DROP COLUMN. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bugzilla.pgaccess.org
Just out of curiosity, what database is backing it? If it isn't PostgreSQL, what about using PHP BugTracker instead? That runs on top of PostgreSQL. http://sourceforge.net/projects/phpbt/ Jan Or Gborg... ;-) http://gborg.postgresql.org/project/gborg/projdisplay.php Cheers, Ned Any other suggestions? Iavor ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
Josh Berkus said: Iavor, Any other suggestions? I can tell you from experience that Double-Choco-Latte, another PHP/PostgreSQL tool, is really set up just for single projects. So it would work fine for PGAccess-only. However, DCL has its own problems and is not necessarily better than Mozilla; I personally don't think it's worth switching tools just to eat our own dogfood if we don't gain some functionality in the process. I'd love to re-write one of these tools someday; they all have ghastly UI problems. Right. Just after I do the accounting program, and get caught up on my tax filing, and re-paint the bathroom ... Thanks, Josh. This was the answer I wanted to hear. The one thing that really bugs me about Mozilla/Issuezilla is that, if you click the link on an issue e-mail, you don't get automatically logged in, forcing you to search for the bug a second time if you want to commment or close the issue. Grrr. Also there's no option *not* to get the darned e-mails for people who check the web interface regularly. What don't you try bugzilla.bugzilla.org or something like that :) I mean - the guys at Mozilla have made a great product using Bugzilla. I would be happy if we bring pgaccess at least to the level of Mozilla. Then we can talk about changing the bug tracking system. Agreed? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
On Wed, 2002-07-10 at 21:49, Iavor Raytchev wrote: Josh Berkus said: Iavor, Any other suggestions? I can tell you from experience that Double-Choco-Latte, another PHP/PostgreSQL tool, is really set up just for single projects. So it would work fine for PGAccess-only. However, DCL has its own problems and is not necessarily better than Mozilla; I personally don't think it's worth switching tools just to eat our own dogfood if we don't gain some functionality in the process. Still we could use the bugzilla variant that uses PostgreSQL for its DB. You can download it from the link uder the perl seal on the page https://bugzilla.redhat.com/bugzilla/index.cgi It points to ftp://people.redhat.com/dkl where are variants for mysql, oracle and postgresql. The only thing you have to do after install is changing the first lines of scripts as they currently ppoint to #!/usr/bonsaitools/bin/perl which you may not have ;) --- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
Iavor, Any other suggestions? I can tell you from experience that Double-Choco-Latte, another PHP/PostgreSQL tool, is really set up just for single projects. So it would work fine for PGAccess-only. However, DCL has its own problems and is not necessarily better than Mozilla; I personally don't think it's worth switching tools just to eat our own dogfood if we don't gain some functionality in the process. I'd love to re-write one of these tools someday; they all have ghastly UI problems. Right. Just after I do the accounting program, and get caught up on my tax filing, and re-paint the bathroom ... The one thing that really bugs me about Mozilla/Issuezilla is that, if you click the link on an issue e-mail, you don't get automatically logged in, forcing you to search for the bug a second time if you want to commment or close the issue. Grrr. Also there's no option *not* to get the darned e-mails for people who check the web interface regularly. -Josh ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
delurk - reading from the archives, so please cc me on responses Note that before bugzilla really supports postgresql, we (ie the bugzilla team) are going to need DROP COLUMN support, as well as support for changing a field's type. This is because thats how upgrades are done, when new features change the bz schema. See http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/checksetup.pl#2193 and below for the code. Lots of it is currently mysql specific, and could easily be wrapped in helper functions - some of it already is. That won't help if there isn't an easy way to use the functionality, though. Reclaiming the disk space is also really needed, because upgrading a bugzilla installation could change a table multiple times, and requirng all that extra disk space will probably be an issue with most admins. Bradley ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
On 10 Jul 2002, Rod Taylor wrote: On Wed, 2002-07-10 at 19:44, Bradley Baetz wrote: delurk - reading from the archives, so please cc me on responses Note that before bugzilla really supports postgresql, we (ie the bugzilla team) are going to need DROP COLUMN support, as well as support for changing a field's type. This is because thats how upgrades are done, when new features change the bz schema. Agreed it would be nice, but how come upgrades cannot be done with temp tables -- especially since the bugzilla database is simple (no foreign key constraints, etc.) If you're persisting with using ENUM(), a common upgrade script won't work anyway. We don't plan on persisting in using enum :) snip You've just changed the datatype from a varchar to integer. With the transaction support, you're guaranteed it won't be left mid way through either. Well, when bugzilla supports a db which supports foreign constraints, we'd like to add those in, too However, is there an easy way of obtaining the list of columns (and their types/indexes/etc) in a table, so that we can recreate table a with just that column missing? One which won't break when the underlying pg_* schema changes? The alternative is to pass the set of columns/indexes/etc into the DropColumn function each time its called, which would get messy quite quickly. Bradley ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
On 10 Jul 2002, Rod Taylor wrote: However, is there an easy way of obtaining the list of columns (and their types/indexes/etc) in a table, so that we can recreate table a with just that column missing? One which won't break when the underlying pg_* schema changes? I see. No, not that I know of. You could take an SQL dump of the DB and work on that, then restore at the end of the upgrade process -- but thats not so good :) :) Anyway, I'd *really* like to see PostgreSQL officially supported by Bugzilla. So would I. I cringe every time I think of the locking issues we have with mysql. There is work being done on that (on a branch), but I don't know what the state of it is. We may get DROP COLUMN in this release (Christopher?). Yeah, I've been reading the archives. bugzilla's auto-updating schema is probably a bit of an unusual application, but it works for us. Changing data types probably won't appear. I don't know of anyone working on it -- and it can be quite a complex issue to get a good (resource friendly and transaction safe) version. I'd be happy with a non-resource friendly and non-transaction-safe version over not having the functionality at all... ;) That said, if drop column is finished in time would the below be close enough to do a data type change?: alter table table rename column to coltemp; alter table table add column column newtype; update table table set column = coltemp; alter table table drop column coltemp; That would work - we'd have to manually recreate the indexes, but most of the type changes are done in combination with other changes which have us doing that anyway. Are there any other requirements aside from drop column and altering data types? I think the big issues are bugzilla ones, using mysql specific features (enum/timestamp types, REPLACE INTO, etc) Locking is the major one, but the first port to pgsql will almost certainly use heavy locking (ie mysql READ - pgsql SHARE MODE, mysql WRITE - ACCESS EXCLUSIVE MODE), because thats the easiest thing to port the mysql-based code over to. Less restrictive locking + select for update friends can be added later. Thanks, Bradley ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
Bradley Baetz wrote: delurk - reading from the archives, so please cc me on responses Note that before bugzilla really supports postgresql, we (ie the bugzilla team) are going to need DROP COLUMN support, as well as support for changing a field's type. This is because thats how upgrades are done, when new features change the bz schema. DROP COLUMNS should be in 7.3, due out in the Fall. You can simulate ALTER COLUMN by creating a new column, UPDATING the data to the new column, dropping the old, then renaming the new column to the old name. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS]bugzilla.pgaccess.org
Changing data types probably won't appear. I don't know of anyone
working on it -- and it can be quite a complex issue to get a good
(resource friendly and transaction safe) version.
I'd be happy with a non-resource friendly and
non-transaction-safe version
over not having the functionality at all... ;)
I absolutely, definitely agree with this! If I really, really, really need
to change a column type then even if it takes 2 hours, I should have the
option. People can always resort to doing a dump, edit and restore if they
really want...
For me, I'd have to buy / install harddrives if I wanted to change data
types in some of the larger tables. I've done a number of silly things
like store an Apache hitlog in the DB for pattern analysis. Lots and
lots of rows ;)
Of course, you might have thought about the correct column types in advance,
but hey :) I think that there's no way to have a rollback-able column type
change without temporarily doubling space. Actually, I think Oracle has
some sort of system whereby the column type change is irreversible, and if
it crashes halfway thru, the table is unusable. You can issue a command on
the table to pick up where it left off. You continue to do this until it's
fully complete. However, I think the temporary doubling is probably good
enough for 90% of our users...
That said, if drop column is finished in time would the below be close
enough to do a data type change?:
alter table table rename column to coltemp;
alter table table add column column newtype;
update table table set column = coltemp;
alter table table drop column coltemp;
That would work - we'd have to manually recreate the indexes,
but most of
the type changes are done in combination with other changes
which have us
doing that anyway.
Okay, if thats all it truly takes, I'll see if I can help get it done.
Well, you're always welcome to help me out with this DROP COLUMN business -
after which MODIFY will be straightforward. Don't forget that maybe foreign
keys, rules, triggers and views might have to be updated?
I think the big issues are bugzilla ones, using mysql specific features
(enum/timestamp types, REPLACE INTO, etc) Locking is the major one, but
enum(A,B,C) - column char(1) check (column IN ('A', 'B', 'C'))
timestamp? Output pattern may be different, but PostgreSQL 7.3 will
accept any timestamp I've thrown at it. Lots of weird and wonderful
forms.
Anyway, I think there is a way to coerce MySQL into outputting an ISO
style timestamp, which would probably be the best way to move as it'll
make adding other DBs easier in the future.
REPLACE INTO: Have an ON INSERT TRIGGER on all tables which will update
a row if the primary key already exists -- or catch an INSERT error and
try an update instead.
The main thing I pick up from all of this is that Bugzilla is rather poorly
written for cross-db compatibility. It should be using a database
abstraction layer such as ADODB that will let you do a 'replace' in _any_
database, is type independent, syntax independent, etc.
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
On 10 Jul 2002, Rod Taylor wrote:
enum(A,B,C) - column char(1) check (column IN ('A', 'B', 'C'))
right.
timestamp? Output pattern may be different, but PostgreSQL 7.3 will
accept any timestamp I've thrown at it. Lots of weird and wonderful
forms.
I'm referring to the mysql |timestamp| type, which will update that
column's contents to |now()| when any UPDATE is given for that partcular
row, unless the column was assigned to. I don't know how to handle the
last part in a trigger. Bugzilla's use of that feature is more trouble
than its worth, though, because we keep forgetting to stop the update in
places where it should be, and there are plans to remove it anyway.
REPLACE INTO: Have an ON INSERT TRIGGER on all tables which will update
a row if the primary key already exists -- or catch an INSERT error and
try an update instead.
BZ uses REPLACE in 4 places, and 3 of those check for the row existing
immediately before. :)
These are bugzilla problems, not postgres ones, though.
Bradley
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
Bradley Baetz [EMAIL PROTECTED] writes: I'm referring to the mysql |timestamp| type, which will update that column's contents to |now()| when any UPDATE is given for that partcular row, unless the column was assigned to. I don't know how to handle the last part in a trigger. It'd probably be close enough to have an UPDATE trigger that does if (new.timestamp = old.timestamp) new.timestamp = now(); regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [INTERFACES] [pgaccess-users] RE: [HACKERS] bugzilla.pgaccess.org
On Wed, 10 Jul 2002, Tom Lane wrote: Bradley Baetz [EMAIL PROTECTED] writes: I'm referring to the mysql |timestamp| type, which will update that column's contents to |now()| when any UPDATE is given for that partcular row, unless the column was assigned to. I don't know how to handle the last part in a trigger. It'd probably be close enough to have an UPDATE trigger that does if (new.timestamp = old.timestamp) new.timestamp = now(); Nope, because the documented way of making sure that the field doens't change is to use |UPDATE foo SET bar=bar |, and thats what bz uses. Don't worry about this, though - we will hpefully be removing this 'feature' soon. Bradley ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] bugzilla.pgaccess.org
Hello, As of today, a Bugzilla has been made available at - bugzilla.pgaccess.org This is a pretty straight forward installation of Bugzilla 2.14.2 It is currently empty. There are even no components so the first bug submissions can be either request for components or have to wait a few days. As we do not have much experience setting Bugzila for open source project (we use it for internal projects - with groups and permissions), all comments are welcome. Iavor -- Iavor Raytchev very small technologies (a company of CEE Solutions) in case of emergency - call: + 43 676 639 46 49 or write to: [EMAIL PROTECTED] www.verysmall.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] bugzilla.pgaccess.org
Iavor Raytchev wrote: Hello, As of today, a Bugzilla has been made available at - bugzilla.pgaccess.org This is a pretty straight forward installation of Bugzilla 2.14.2 It is currently empty. There are even no components so the first bug submissions can be either request for components or have to wait a few days. As we do not have much experience setting Bugzila for open source project (we use it for internal projects - with groups and permissions), all comments are welcome. Just out of curiosity, what database is backing it? If it isn't PostgreSQL, what about using PHP BugTracker instead? That runs on top of PostgreSQL. http://sourceforge.net/projects/phpbt/ Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bugzilla.pgaccess.org
- Original Message - From: Jan Wieck [EMAIL PROTECTED] To: Iavor Raytchev [EMAIL PROTECTED] Cc: pgaccess - developers [EMAIL PROTECTED]; pgaccess - users [EMAIL PROTECTED]; pgsql-hackers [EMAIL PROTECTED]; pgsql-interfaces [EMAIL PROTECTED] Sent: Tuesday, July 09, 2002 5:28 PM Subject: Re: [HACKERS] bugzilla.pgaccess.org Iavor Raytchev wrote: Hello, As of today, a Bugzilla has been made available at - bugzilla.pgaccess.org This is a pretty straight forward installation of Bugzilla 2.14.2 It is currently empty. There are even no components so the first bug submissions can be either request for components or have to wait a few days. As we do not have much experience setting Bugzila for open source project (we use it for internal projects - with groups and permissions), all comments are welcome. Just out of curiosity, what database is backing it? If it isn't PostgreSQL, what about using PHP BugTracker instead? That runs on top of PostgreSQL. http://sourceforge.net/projects/phpbt/ Jan Or Gborg... ;-) http://gborg.postgresql.org/project/gborg/projdisplay.php Cheers, Ned ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
