Re: Patches for LOCALTIME and regexp, feature list

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
>

In response to

Responses

Browse pgsql-hackers by date

  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?