> > > > 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
> >
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 han
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 probab
On Thu, 11 Jul 2002, Christopher Kings-Lynne wrote:
> 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 o
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 |times
> > > 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
> > 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
Bradley Baetz wrote:
>
>
> 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 COLUM
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
On 10 Jul 2002, Rod Taylor wrote:
> On Wed, 2002-07-10 at 19:44, Bradley Baetz wrote:
> >
> >
> > 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
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/
11 matches
Mail list logo
