Re: Patches for LOCALTIME and regexp, feature list
От | Christopher Kings-Lynne |
---|---|
Тема | Re: Patches for LOCALTIME and regexp, feature list |
Дата | |
Msg-id | 00d201c21450$61e5e230$0200a8c0@SOL обсуждение исходный текст |
Ответ на | Patches for LOCALTIME and regexp, feature list (Thomas Lockhart <lockhart@fourpalms.org>) |
Список | 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@fourpalms.org> To: "PostgreSQL Hackers List" <pgsql-hackers@postgresql.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@postgresql.org >
В списке pgsql-hackers по дате отправления: