On Saturday 31 January 2009 8:47:28 pm Adam Rich wrote:
> On Thu, 29 Jan 2009 13:16:17 +0000
>
> Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> > So, what do people say? Is Postgres perfect in your world or does it
> > do some things which rub you the wrong way?
>
> I see all the major ones have already been mentioned, so here's some
> minor ones.
>
> - lack of system-level and DDL triggers
> - inability to limit triggers to certain columns
> - inability to know the DML operation causing a trigger
From:
http://www.postgresql.org/docs/8.3/interactive/plpgsql-trigger.html
TG_OP
Data type text; a string of INSERT, UPDATE, or DELETE telling for which
operation the trigger was fired.
This is also available in plpythonu, I don't know about the other PL's.
> - date_part/extract returning floats instead of integer
Maybe this what you are looking for ?:
http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html
Note: When timestamp values are stored as double precision floating-point
numbers (currently the default), the effective limit of precision might be less
than 6. timestamp values are stored as seconds before or after midnight
2000-01-01. Microsecond precision is achieved for dates within a few years of
2000-01-01, but the precision degrades for dates further away. When timestamp
values are stored as eight-byte integers (a compile-time option), microsecond
precision is available over the full range of values. However eight-byte
integer timestamps have a more limited range of dates than shown above: from
4713 BC up to 294276 AD. The same compile-time option also determines whether
time and interval values are stored as floating-point or eight-byte integers.
In the floating-point case, large interval values degrade in precision as the
size of the interval increases.
> - parts of the SQL statement (e.g. 'for update of') requiring table
> aliases when present instead of table names.
> - lack of queryable high-water marks useful for tuning
> - lack of an auto-tuner, for that matter.
> - inability to log (e.g. long-running queries) to a table
> - lack of custom session-level variables (without editing postgresql.conf)
> - lack of autonomous transactions
--
Adrian Klaver
aklaver@comcast.net