Re: Re: new type proposal

From: "Martin A(dot) Marques" <martin(at)math(dot)unl(dot)edu(dot)ar>
To: "Dan Wilson" <phpPgAdmin(at)acucore(dot)com>, <pgsql-general(at)postgresql(dot)org>, <alex(at)pilosoft(dot)com>
Subject: Re: Re: new type proposal
Date: 2001-02-07 11:08:44
Message-ID: 01020708084401.09040@math.unl.edu.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

El Mar 06 Feb 2001 20:58, Dan Wilson escribió:
>
> : 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.

OK, but anyway, that function (which can be made by anyone) would be on the
template0(1) database? Then why don't you create it there, and you'll have it
for all the databases you built in the future.

> 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")
> );

It isn't that bad what you want, but I insist with not make a "TO BIG"
backend, or start putting things by default in the template database, if it
is that the users will not normally use it.

> And would have a trigger associated with it and a function to update the
> mod_time column.
>
> : 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.

Well, it may not be my case, but what about people that have scripts that
constantlly built new tables.
Any way, yuo can add it to your template database.

> 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.

Bad idea.

> 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.

The decision is on the developers, not me. ;-)

Saludos... :-)

--
System Administration: It's a dirty job,
but someone told I had to do it.
-----------------------------------------------------------------
Martín Marqués email: martin(at)math(dot)unl(dot)edu(dot)ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tamsin 2001-02-07 11:25:01 drop check constraint
Previous Message Emmanuel Charpentier 2001-02-07 10:22:22 Trouble with views (7.1beta4 Debian) and PgAccess 0.98.7.