From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | <lockhart(at)fourpalms(dot)org>, "PostgreSQL Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patches for LOCALTIME and regexp, feature list |
Date: | 2002-06-15 09:38:17 |
Message-ID: | 00d201c21450$61e5e230$0200a8c0@SOL |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
You wrote "was either to voluminous" instead of "was either too voluminous"
in the first paragraph of the appendix...
Chris
----- Original Message -----
From: "Thomas Lockhart" <lockhart(at)fourpalms(dot)org>
To: "PostgreSQL Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Sent: Saturday, June 15, 2002 1:16 PM
Subject: [HACKERS] Patches for LOCALTIME and regexp, feature list
> I've just committed changes to include an SQL99 feature list as an
> appendix in the User's Guide. While preparing that I noticed a feature
> or two which would be trivial to implement, so we now have LOCALTIME and
> LOCALTIMESTAMP function calls per spec (afaict; the spec is very vague
> on the behaviors).
>
> I've also removed the ODBC-compatible parentheses on CURRENT_TIMESTAMP
> etc and made sure that the ODBC driver handles the case correctly.
>
> More details from the CVS logs are below...
>
> - Thomas
>
> Add LOCALTIME and LOCALTIMESTAMP functions per SQL99 standard.
> Remove ODBC-compatible empty parentheses from calls to SQL99 functions
> for which these parentheses do not match the standard.
> Update the ODBC driver to ensure compatibility with the ODBC standard
> for these functions (e.g. CURRENT_TIMESTAMP, CURRENT_USER, etc).
> Include a new appendix in the User's Guide which lists the labeled
> features
> for SQL99 (the labeled features replaced the "basic", "intermediate",
> and "advanced" categories from SQL92). features.sgml does not yet split
> this list into "supported" and "unsupported" lists.
> Search the existing regular expression cache as a ring buffer.
> Will optimize the case for repeated calls for the same expression,
> which seems to be the most common case. Formerly, always searched
> from the first entry.
> May want to look at the least-recently-used algorithm to make sure it
> is identifying the right slots to reclaim. Seems silly to do math when
> it seems that we could simply use an incrementing counter...
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2002-06-15 10:32:30 | Re: Non-standard feature request |
Previous Message | Bruce Momjian | 2002-06-15 05:32:01 | Re: Queries using rules show no rows modified? |