Hi and thanks for answer,
Nope. The problem is suggested, if not exactly clearly explained,
by the error message: casting a literal to ddate isn't a guaranteed
fixed process. Wasn't clear enought to me.For example, suppose you created this table and then
did
alter domain ddate add check
=?iso-8859-1?Q?M=E1rcio_Ant=F4nio_Sepp?= writes:
> The follow error occur:
> SQL Error [42804]: ERROR: specified value cannot be cast to type ddate for
> column "d"
> Detalhe: The cast requires a non-immutable conversion.
> I cannot use domain in this case?
Nope. The problem is suggested, if
Hi,
This query works fine:
create table t1
(d date)
PARTITION BY RANGE (d);
CREATE TABLE t1_p1 PARTITION OF t1 FOR VALUES FROM ('2000-01-01') TO
('2019-01-01');
Same query, but now (using domain):
CREATE DOMAIN ddate
AS date;
create table t1
(d ddate)
On Tue, Sep 11, 2018 at 04:32:27PM +0200, Peter Eisentraut wrote:
> I recommend letting this bake in the master branch for a while. There
> are a lot weirdly patched and alternative OpenSSL versions out there
> that defy any documentation.
Good point. Such things have bitten in the past. Okay,
On 11/09/2018 05:02, Michael Paquier wrote:
> Hence, intrinsically, we are in contradiction with the upstream docs. I
> have worked on the problem with the patch, which works down to OpenSSL
> 0.9.8, and should fix your issue. This is based on what you sent
> previously, except that I was not
On Tue, 11 Sep 2018 at 13:56, Arup Rakshit wrote:
> I have define a simple B Tree index on column *country* for users table. I
> don’t understand why the order by column not using the index scan when
> using *distinct* keyword in the select clause. Can anyone explain what is
> happening here?
>
Arup Rakshit writes:
> I have define a simple B Tree index on column *country* for users table. I
> don’t understand why the order by column not using the index scan when using
> *distinct* keyword in the select clause. Can anyone explain what is happening
> here?
Doesn't look complicated to
On 9/11/18 1:41 AM, Csaba Ragasits wrote:
Hello,
We would like to migrate from 8.3 to 10 version. We've hundreds
databases with different structures. That reason we're working on an
automatic data comparing process.
I've found the following storage settings:
- pg83: Date/time type storage:
I have define a simple B Tree index on column *country* for users table. I
don’t understand why the order by column not using the index scan when using
*distinct* keyword in the select clause. Can anyone explain what is happening
here?
aruprakshit=# \d users;
Then fix your field-based data comparing mechanism.
On 09/11/2018 03:41 AM, Csaba Ragasits wrote:
Hello,
We would like to migrate from 8.3 to 10 version. We've hundreds databases
with different structures. That reason we're working on an automatic data
comparing process.
I've found the
Hello,
We would like to migrate from 8.3 to 10 version. We've hundreds databases
with different structures. That reason we're working on an automatic data
comparing process.
I've found the following storage settings:
- pg83: Date/time type storage: 64-bit integers
- pg10: Date/time
Here is some data from our production. I hope it can be of any use to you.
- System 1:
hiper=> select
bucket
,count(*) entries
,max(calls) max_calls
,round(sum(total_time)) total_time
,round((100*sum(total_time)/avg(total_total_time))::numeric,2)
Hi Adrian,
thanks for the encouragement. If anyone can comment on the code, I'd
still be very interested.
Cheers,
Lutz
On Thursday, 06.09.2018 06:27:14 Adrian Klaver wrote:
> On 09/03/2018 09:11 AM, Lutz Gehlen wrote:
> > Hello all,
> >
> > unfortunately, I have so far not received a reply
13 matches
Mail list logo
