From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Per-database/schema settings |
Date: | 2000-07-10 07:11:33 |
Message-ID: | Pine.LNX.3.96.1000710084525.24431B-100000@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 7 Jul 2000, Thomas Lockhart wrote:
> > This solution can forever stop all discussion about styles that PG
> > must/can support.
>
> This is one thing I'm *not* certain about. The problems with a fully
> general, templated formatting function for the backend include
>
> 1) It is easy to make a date/time template which *cannot* be used to
> read data back in. So, for example, pg_dump could be fundamentally
> broken just be this setting. Currently, input and output are always
> compatible (more or less ;)
full support for in/out is expect in this idea, and we can add check
that conterol if defined template is right for timestamp interpretation.
> 2) There may be a performance hit to *always* use a fully general
> template for formatting.
Not sure. The to_char/timestamp is fast and parsed template is cached,
IMHO is not big (speed) differention between to_char/timestamp and standard
date/time formatting.
> 3) If the template is used for output, it should probably be used for
> input (to minimize the possibility of (1)). But then we would be able to
> accept fewer date/time variations than we do now.
With this setting is all in user's hands...
I don't know how much problematic it is, but the oracle has this feature
(NSL_DATE_FORMAT in ALTER SESSION, etc)
But I not say that we must implement this, it is still open thema :-)
Karel
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-07-10 07:30:09 | Re: Progress report: intraquery memory recovery in executor |
Previous Message | Tom Lane | 2000-07-10 07:00:00 | Re: postmaster errors with index on temp table? |