"David E. Wheeler" writes:
> On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
>> I gave my reasoning before: widening this API has possibly nontrivial
>> future maintenance costs, and the actual use-case for the data is
>> unconvincing.
> It seems to me that the immediate patch to simply copy zone.t
On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-case for the data is
unconvincing.
It seems to me that the immediate patch to simply copy zone.tab has no
effect on the API. That's
>Surely we'd have seen more complaints, then.
> regards, tom lane
This gets a definite +1 here as we are using "SET TIMEZONE" at the
beginning of each transaction so that each user sees/records dates
automatically in whatever timezone they have associated with them.
Works bea
On Fri, Apr 10, 2009 at 3:01 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Tom,
>>> Like what? I do not actually believe that anyone needs an
>>> interactive geographical timezone selector based on
>>> pg_timezone_names.
>
>> Actually, considering that PostgreSQL is the leading open source GIS
>>
David Fetter writes:
> You're setting a pretty high bar here for a pretty small change which
> will cause a pretty large increase in convenience. What is the actual
> problem here?
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-
On Fri, Apr 10, 2009 at 03:01:05PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > Tom,
> >> Like what? I do not actually believe that anyone needs an
> >> interactive geographical timezone selector based on
> >> pg_timezone_names.
>
> > Actually, considering that PostgreSQL is the leading open
Josh Berkus writes:
> Tom,
>> Like what? I do not actually believe that anyone needs an
>> interactive geographical timezone selector based on
>> pg_timezone_names.
> Actually, considering that PostgreSQL is the leading open source GIS
> database, I expect that a *lot* of people want this.
Sur
Tom,
Like what? I do not actually believe that anyone needs an
interactive geographical timezone selector based on
pg_timezone_names.
Actually, considering that PostgreSQL is the leading open source GIS
database, I expect that a *lot* of people want this. Or, at least,
enough data to ad
and...@tao11.riddles.org.uk (Andrew Gierth) writes:
> The usual conversation goes something like this (generally following
> on from some discussion of how to do timezone conversions):
>
> Q: how do I get the list of available zone names?
>
> A: see pg_timezone_names
>
> Q: but there's 1650/1400
> "Tom" == Tom Lane writes:
> David Fetter writes:
>> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>>> I still see no point in this unless we expose the information in
>>> pg_timezone_names, which requires rather more than a one-line patch.
>> There's really no point, and
> "Alvaro" == Alvaro Herrera writes:
>> Andrew did, in fact, submit the patch to install zone.tab.
Alvaro> Hmm, yeah, that he did. (Seems to be missing "make
Alvaro> uninstall" support though.)
The rm -rf in the uninstall rule seems to be sufficient for that.
(What _is_ missing, as I s
David E. Wheeler wrote:
> On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
>
>> Agreed, it seems to me that a patch to install zone.tab during "make
>> install" could be applied at this time (before beta so that packagers
>> don't complain that we didn't give them time to fix their file lists).
>>
On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
Agreed, it seems to me that a patch to install zone.tab during "make
install" could be applied at this time (before beta so that packagers
don't complain that we didn't give them time to fix their file lists).
A more complete patch can be discuss
David Fetter writes:
> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
>> I still see no point in this unless we expose the information in
>> pg_timezone_names, which requires rather more than a one-line patch.
> There's really no point, and a lot of good stuff lost,
Like what? I do n
David Fetter wrote:
> On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
> > Andrew Gierth writes:
> > > At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED
> > > WHERE IT BELONGS rather than simply ignored, so that even if
> > > further requests to include the information in
On Mon, Apr 06, 2009 at 08:48:55PM -0400, Tom Lane wrote:
> Andrew Gierth writes:
> > At the VERY LEAST, can we PLEASE have the zone.tab file INSTALLED
> > WHERE IT BELONGS rather than simply ignored, so that even if
> > further requests to include the information in a system view go
> > unheard b
On Apr 6, 2009, at 5:48 PM, Tom Lane wrote:
Andrew Gierth writes:
At the VERY LEAST, can we PLEASE have the zone.tab file
INSTALLED WHERE IT BELONGS rather than simply ignored, so that even
if
further requests to include the information in a system view go
unheard by -hackers, I can at leas
Andrew Gierth writes:
> At the VERY LEAST, can we PLEASE have the zone.tab file
> INSTALLED WHERE IT BELONGS rather than simply ignored, so that even if
> further requests to include the information in a system view go
> unheard by -hackers, I can at least provide a pgfoundry module or
> something
Back before 8.2 came out, I posted:
> Any view over the full timezone names should also include the
> corresponding data from zone.tab in the timezone library source.
I got no meaningful response to this (Tom responded with an erroneous
statement and ignored my explanation of his mistake).
Back
19 matches
Mail list logo
