Thanks for taking this up.
24.10.2024 22:44:11 Adrian Klaver :
>
> 1) Have you looked at?:
>
> https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-USING-INHERITANCE
I do not feel it applies to my case. I tried to create a partitioned table that
inherits columns from
24.10.2024 22:58:39 David G. Johnston :
>
> My impression of things is that directly using “inherit” for table creation
> is considered deprecated at this point. No one has interest in expanding on
> the feature nor even recommends it be used in new development. That
> particular unique featu
Hi
Up to version 17, partitioning of tables inheriting from other tables
is not possible.
psql:../code_files/data_storage/PostgreSQL/tables/TOPO_FILES.pg_sql:68:
ERROR: no se puede crear una tabla particionada como hija de herencia
Are there plans to support this in the future? I could not
On Thursday, October 24, 2024, wrote:
>
> Up to version 17, partitioning of tables inheriting from other tables is
> not possible.
>
>> psql:../code_files/data_storage/PostgreSQL/tables/TOPO_FILES.pg_sql:68:
>> ERROR: no se puede crear una tabla particionada como hija de herencia
>>
>
> Are ther
Hi,
Please find the complete stack trace, the language is C and thread here was
just performing the operation of fetching records from the postgresDB using
SQL_get_tpf_rw() function for which I've also attached implementation here
as well
Stack trace of thread 966070:
Hi,
Is this a complete backtrace?
Can you post a complete backtrace? We need to see if there is a reference
to your application code?
What language is it written in?
What operation this thread was performing?
Thank you.
On Thu, Oct 24, 2024 at 11:12 AM Sasmit Utkarsh wrote:
>
> Dear PostgreSQL
Dear PostgreSQL Community Team,
I hope this message finds you well. I am reaching out for assistance with
an issue encountered in our application, which communicates with PostgreSQL
using the libpq client library.
*Issue Details:*
We have observed a problem where one of the application's threads
>
> Additionally in the plan which mysql makes and showing the highest
> response time, is it suffering because of differences of the speed of the
> underlying IO/storage or is it just because of the optimization features
> which are available in postgres and not there in mysql ? Trying to
> unders
Hi,
I am just thinking, when DEFAULT CURRENT_DATE is being used in table
definition then why the function is again being used in INSERT statement
why not use
default. Here is sample
edb=# create table date_test (id int, hiredate date default current_date);
CREATE TABLE
edb=# insert into date_tes
