> -----Original Message-----
> From: Andreas Pflug [mailto:[EMAIL PROTECTED]
> Sent: 20 January 2006 13:11
> To: Dave Page
> Cc: Francisco Leovey; pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Pgadmin III not honoring DATESTYLE
>
> > pgAdmin II is a totally different codebase, which we
> learned a lot from.
> > One of those things was that having differing datestyles
> can lead to
> > confusion and accidental data corruption (if you've ever
> had to try to
> > fix the dates in a multi-million row table you'll know
> where I'm coming
> > from). As I said in an earlier email, if someone want's to
> write a patch
> > that makes honouring DATESTYLE a non-default option, then we'll
> > certainly consider including it, however this is not
> something I intend
> > to work on.
>
> Changing DATESTYLE is NOT acceptable, like we don't have an encoding
> option. Both ENCODING and DATESTYLE are options that are selected to
> guarantee a _machine_ readable format. I won't allow this to be mixed
> with GUI representation.
I wasn't suggesting we do that, though I'll grant you I could have
phrased it a whole lot better. pgAdmin will always use ISO internally,
but it could - as a non-default option - display dates in the format
specified by the datestyle in the edit grid etc.
> However, it would be possible (actually: still planned) to have the
> _display_ dependent on locale settings, including usage of a
> date entry
> control.
Locale is definitely far more acceptable than datestyle - that would at
least be consistent across all connected servers and databases which is
my main concern.
Magnus raised an interesting point on IM - it would be useful to honour
datestyle in the query tool so that data can be exported in the desired
format more easily.
Regards, Dave.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
