On 05/04/2023 11:23, Erik Wienhold wrote:
Judging by the commit message and changed test cases, probably:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911
That's the one. I can't see which pg version(s) this turned up in.
I was looking at perl CPAN Module (DateTime::Format::Pg) and saw that it did
something that seemed odd to me with time zones, based on the comment:
# For very early and late dates, PostgreSQL always returns times in
# UTC and does not tell us that it did so.
Early is before 1901-12-14 a
On 03/07/2019 20:36, Tom Lane wrote:
>
> It looks like what's happening is that the result of my_from_local()
> is being stored into the table as an anonymous record value rather
> than a value of type my_timestamp. (The originating session can figure
> out what the anonymous record type is, but n
> It seems a bug to me. Can you share an anonymized/simplified definition
> of that table that reproduces the problem?
>
Ok See attached sql set up. I guess you need to to a createdb first.
so :
testdb=# \i db.sql
DROP TRIGGER
DROP TABLE
...
testdb=# select * from user_passwords ;
name | times
On 06/06/2019 14:35, Adrian Klaver wrote:
> On 6/6/19 4:02 AM, Steve Rogerson wrote:
>> I've just updated my laptop to pg11 and I'm getting a problem. I'm trying to
>> keeps the details confidential, so somewhat vague I'm afraid.
>>
>> sjr_local1db=&
I've just updated my laptop to pg11 and I'm getting a problem. I'm trying to
keeps the details confidential, so somewhat vague I'm afraid.
sjr_local1db=> select count(*) from user_passwords ;
ERROR: record type has not been registered
sjr_local1db=> insert into user_passwords (name, "timestamp"
On 27/03/18 15:44, Paul Jungwirth wrote:
> SELECT c.conname,
> ...
This just does a variation on select * from
information_schema.check_constraints, and has the same issue, that is the the
returned value for the constraint is not what I give when I create it - but
some 'normalised' vers
williamI am trying to add/change a constraint programmatically, but not if it
already exists, and is the same as before.
I can so something like (may not be precise ...)
select check_clause from information_schema.check_constraints where
constraint_name = 'my-name'
but this returns that clause
