"Roman Kononov" writes:
> test=# select date_trunc('week','0001-12-09 BC'::timestamp);
> ERROR: cannot calculate week number without year information
Hmph, this code is pretty bletcherous. Sleuthing in the CVS history, it
seems that the error check for "year zero" was put into isoweek2j (then
i
The following bug has been logged online:
Bug reference: 4702
Logged by: Roman Kononov
Email address: kono...@ftml.net
PostgreSQL version: 8.3.6 and older
Operating system: GNU/Linux x86_64
Description:refusal to compute date_trunc('week', '0001-12-09 BC');
Details:
Heikki Linnakangas writes:
>SELECT '("(1)")'::btype INTO bvar; -- Should work, but errors
No, because it's expecting the SELECT to yield a separate column for
each column of the composite variable bvar. Something like
SELECT ('("(1)")'::btype).* INTO bvar;
would be correct. To make it wo
Tested on 8.2, 8.3 and CVS HEAD:
CREATE TYPE atype AS (a int);
CREATE TYPE btype AS (compcol atype);
CREATE FUNCTION foofunc() RETURNS void AS $$
declare
avar atype;
bvar btype;
begin
SELECT '("(1)")'::btype INTO bvar; -- Should work, but errors
end;
$$ LANGUAGE plpgsql;
SELECT foofunc(
DGPickett wrote:
- Query times could be limited, by login id or class, so they error
out after N seconds. There could even be two thresholds, one long one
for the entire query and another, shorter one for time without a row
delivered or churned. This way, the user would not have to bother
admi
I do not see a features suggestion list, so here goes:
I suggest Postgres get these features:
- Query times could be limited, by login id or class, so they error
out after N seconds. There could even be two thresholds, one long one
for the entire query and another, shorter one for time without
Of course, anyone can make an error that causes a query to run
forever, just as easily as a spelling typo! :-)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hello,
We work in an institution for teaching and research and
we have a medium database using PostgreSQL, with around 290GB, where
most of the data refers to binary files (blobs).
Initially, I wonder if we can exchange information about the database
with respect to postgresql missmatches OIDs wh
