> 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. > Thanks, I knew this was available for python & perl PLs, I wasn't aware it was I plpgsql too. Still, it would be nice to have something akin to oracle's IF(UPDATING('col_name')) THEN > > - 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. > Nope, I mean if you use date_part to extract a piece of a date, you get a float instead of an integer. It trips me up everytime I try something like this: select * from table where (weekmask & (1 << date_part('DOW', $1))) <> 0 To my surprise, the << operator fails because it requires an integer argument, but date_part provides only a double floating point. I realize this is documented as intended behavior, but why? Is there any scenario where DOW (or day, year, hour, or *any* field really) would be returning a fractional number? > > - 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@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
