Re: Patches for LOCALTIME and regexp, feature list - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Patches for LOCALTIME and regexp, feature list
Date
Msg-id 00d201c21450$61e5e230$0200a8c0@SOL
Whole thread Raw
In response to Patches for LOCALTIME and regexp, feature list  (Thomas Lockhart <lockhart@fourpalms.org>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Queries using rules show no rows modified?
Next
From: Mike Mascari
Date:
Subject: Re: Non-standard feature request