"Nate Carson" writes:
> Description:Composite Type Handles Null Incorrectly
So far as I can see, this script just shows that is null/is not null
on a composite value behave as specified in the manual:
Note: If the expression is row-valued, then IS NULL is true when the
row expres
The following bug has been logged online:
Bug reference: 5658
Logged by: Sangmin Ryu
Email address: neoc...@gmail.com
PostgreSQL version: 8.3, 8.4.4
Operating system: Ubuntu 8.04 , Ubuntu 10.04
Description:'at time zone {timezone description}' can't recognize
many tim
"Sangmin Ryu" writes:
> 'at time zone {timezone description}' don't recognize many time zone
> abbreviations.
This is configurable. See
http://www.postgresql.org/docs/8.4/static/datetime-config-files.html
In general our intent is not to try to put every timezone abbreviation
in the world into t
Two small fixes for hstore-new.
The hstore_compat one is arguable as to what is the best approach; the
assert that was there was just wrong, but I have been unable after
considerable searching to find any architectures that would fail the
check. The version in this patch will just treat any old-fo
Andrew Gierth writes:
> Two small fixes for hstore-new.
> The hstore_compat one is arguable as to what is the best approach; the
> assert that was there was just wrong, but I have been unable after
> considerable searching to find any architectures that would fail the
> check.
[ scratches head...
Andrew Gierth writes:
> The gist one is just that the old code was abusing DatumGetHStoreP by
> applying it to something that wasn't an hstore. This didn't matter
> before the format upgrade code was put in, and it didn't show up in
> tests because you need to index a very large number of hstores
I wrote:
> Andrew Gierth writes:
>> The hstore_compat one is arguable as to what is the best approach; the
>> assert that was there was just wrong, but I have been unable after
>> considerable searching to find any architectures that would fail the
>> check.
> [ scratches head... ] It looks like
> "Tom" == Tom Lane writes:
>> Two small fixes for hstore-new.
>> The hstore_compat one is arguable as to what is the best approach; the
>> assert that was there was just wrong, but I have been unable after
>> considerable searching to find any architectures that would fail the
>> check.
> "Tom" == Tom Lane writes:
>> The gist one is just that the old code was abusing DatumGetHStoreP
>> by applying it to something that wasn't an hstore. This didn't
>> matter before the format upgrade code was put in, and it didn't
>> show up in tests because you need to index a very large
