Re: [HACKERS] Date/time types: big changeu

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Date/time types: big changeu
Date: 2000-02-18 15:35:01
Message-ID: 403.950888101@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> writes:
> I don't think this should be a per database setting. Why not use an
> environment variable PGDATESTYLE for it.

We already have that, and I wouldn't have brought up the issue if I
thought it was sufficient. The case where you really want to be able
to set a default at the database or installation level is when you have
a ton of client apps running on a bunch of different machines, and you
can't or don't want to fix them all at once. A client-side fix doesn't
get the job done for a dbadmin faced with that kind of situation.

Or were you talking about a server-side env variable? That could work
I guess, but I thought you were intent on eliminating env-var
dependencies in initdb and postmaster startup ... for good reasons ...

> Before we throw all kinds of per database defaults around, I'd like to see
> some sort of a concept where exactly a "database" stands versus "schema",
> etc. What happens if one day queries across databases are allowed?

Presumably a client doing that would make sure to request the same
datestyle (or whatever) from each database. You're right though
that we could use some global thinking about what parameters need
to be settable from where, and what their scopes need to be.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-02-18 15:48:29 Re: [HACKERS] Date/time types: big changeu
Previous Message Tom Lane 2000-02-18 15:23:49 Re: [HACKERS] psql and Control-C