Re: Re: new type proposal - Mailing list pgsql-general

: El Mar 06 Feb 2001 19:38, Dan Wilson escribió:
: >
: > What would this do that would be non-standard?  Does the SERIAL datatype
: > add something that is not standard?  No... it just allows for an easy
way
: > to implement something that is standard.  The SERIAL "type" isn't really
a
: > datatype, it's just a keyword that allows you to automatically specify
an
: > int4 column with a related sequence and default.  I don't see why the
same
: > thing couldn't be done with TIMESTAMP!
:
: You're right about the SERIAL type, but I still don't think there should
be a
: new type that those what a trigger can do.
: If the developers added a new data type for each user that is to lazy to
: create a trigger, this would look much like MySQL. :-)
: Any way, with this kind of thoughts, why don't we take away the triggers,
and
: just make another built-in data type each time a user wants it?

No.... if this required a new datatype, then I would agree with you, but it
doesn't. It's just an automagic way to impliment existing functionality.  No
additional datatype is needed and it wouldn't replace what a trigger does.
We would use a trigger to impliment it.

When the parser comes across a create table statment and the AUTO_TIMESTAMP
(or whatever) keyword, it would then realize that the user wants an actual
timestamp datatype and would then automatically create a trigger to update
that column whenever the tuple was changed.

So here's your create statement:

CREATE TABLE auto_time_stamp_tbl (
   table_id SERIAL,
   mod_time AUTO_TIMESTAMP,
   my_data varchar(30)
);

This would then generate a table like the following:

CREATE TABLE "auto_time_stamp_tbl" (
   "table_id" int4 DEFAULT nextval('auto_time_stamp_tb_table_id_seq'::text)
NOT NULL,
   "mod_time" timestamp NOT NULL,
   "my_data" varchar(30) NOT NULL,
   CONSTRAINT "auto_time_stamp_tbl_pkey" PRIMARY KEY ("table_id")
);

And would have a trigger associated with it and a function to update the
mod_time column.

: > I'm not saying to create an actual datatype that is called TIMESTAMP or
: > LAST_MODIFIED, just use it in a create script.  It would then be
: > implemented with the DATE datatype combined with triggers.
: >
: > Makes perfect sense to me!
:
: But it would be built-in as it was said before? In that case we would have
a
: bigger backend. Very bad.... :-(

It can't be much more that much more overhead, and it would only be run
during a create table statement.  All the other code to support this is
already in the backend.

Alex mentioned that not many people need it, but I think if it existed more
people would use something like this.  I usually handle it through my
application code, which is what I think a lot of people do just because they
don't want to bother with creating the trigger.

Oh well... I will leave it up to those that know postgres best.  They can
make the decision, but I think it would be a great added feature without
adding anything non-standard.

-Dan