> On the other hand, I seem to have botched the definition of
> force_default_value() in include/catalog/pg_proc.h, because adding the
> trigger manually doesn't seem to work either:
>
> | des=# \df force_default_value
> | List of functions
> | Result data type | Schema | Name | Argument data types
> | ------------------+------------+---------------------+---------------------
> | "trigger" | pg_catalog | force_default_value | text
> | (1 row)
> |
> | des=# create trigger test_id_always_default before insert on test for each row execute procedure
force_default_value('id');
> | ERROR: function force_default_value() does not exist
>
> Any suggestions?
Triggers are strange this way. You need to create the function without
any arguments. The procedure is expected to find (and enforce) the
arguments through use of the TriggerData struct.
ttdummy() in src/test/regress/regress.c is an example of a Trigger
taking 2 arguments.
Using triggers could cause some interesting side effects when they're
system controlled. Triggers are fired by naming convention
(alphabetical order). If the user creates two triggers, firing first
and third (force_default_value() being second) they will see two
different values in that field.
It would be interesting to see what other DBs do with ALWAYS and BEFORE
triggers (whether they see the user supplied or generated value).
I think a longer term solution would be to add a type to pg_attrdef and
a bool for ALWAYS. (Tom?)
- default, identity, and generator being the types.
- SERIAL would be converted into an identity (not the other way around).
- psql would not show defaults in the case of an identity.
- pg_dump could be trained to use the identity syntax on the table which
has the added benefit of not relying on sequence naming convention.
- rewriteTargetList() can be used to enforce the default value from the
client perspective only (triggers, user rules, etc. could all override
ALWAYS default but the spec does not mention otherwise).