Re: Per-database/schema settings

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

In response to

Responses

Browse pgsql-hackers by date

  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?