>> And yes, probably you need to change the way you reply to email on
>> this list. Top-posting is generally avoided. See
>> https://wiki.postgresql.org/wiki/Mailing_Lists.
>Thanks for bringing this into the discussion :)
Thinking these days more about this topic, subscriber name is not a bad
On Wed, Nov 30, 2022 at 2:09 PM Stavros Koureas
wrote:
>
>
>
> Στις Τρί 29 Νοε 2022 στις 3:27 μ.μ., ο/η Ashutosh Bapat
> έγραψε:
> > That would be too restrictive - not necessarily in your application
> > but generally. There could be some tables where consolidating rows
> > with same PK from
Στις Τρί 29 Νοε 2022 στις 3:27 μ.μ., ο/η Ashutosh Bapat <
ashutosh.bapat@gmail.com> έγραψε:
> That would be too restrictive - not necessarily in your application
> but generally. There could be some tables where consolidating rows
> with same PK from different publishers into a single row in
On Fri, Nov 25, 2022 at 4:13 PM Stavros Koureas
wrote:
>
> Yes, if the property is on the subscription side then it should be applied
> for all the tables that the connected publication is exposing.
> So if the property is enabled you should be sure that this origin column
> exists to all of
Sure I understand and neither do I have good knowledge of what else could
be influenced by such a change.
If the value of the column is the subscriber name has no benefit to this
idea of merging multiple upstreams with same primary keys, later you
describe the "connection dbname", yes this could
On Fri, Nov 25, 2022 at 9:43 PM Stavros Koureas
wrote:
>
> Yes, if the property is on the subscription side then it should be applied
> for all the tables that the connected publication is exposing.
> So if the property is enabled you should be sure that this origin column
> exists to all of
Yes, if the property is on the subscription side then it should be applied
for all the tables that the connected publication is exposing.
So if the property is enabled you should be sure that this origin column
exists to all of the tables that the publication is exposing...
Sure this is the
On Wed, Nov 23, 2022 at 4:54 AM Peter Smith wrote:
>
> On Wed, Nov 23, 2022 at 7:38 AM Stavros Koureas
> wrote:
> >
> > Reading more carefully what you described, I think you are interested in
> > getting something you call origin from publishers, probably some metadata
> > from the
Just one correction for the subscriber
On Subscriber:
test_sub=# CREATE TABLE tab(id int *pkey*, description varchar,
subscription varchar *pkey*);
CREATE TABLE
The subscription table should have the same primary key columns as the
publisher plus one more.
We need to make sure that on update
It's easy to answer this question.
Imagine that in a software company who sells the product and also offers
reporting solutions, the ERP tables will not have this additional column to
all the tables.
Now the reporting department comes and needs to consolidate all that data
from different
On Wed, Nov 23, 2022 at 1:40 AM Stavros Koureas
wrote:
>
> Reading more carefully what you described, I think you are interested in
> getting something you call origin from publishers, probably some metadata
> from the publications.
>
> This identifier in those metadata maybe does not have
On Tue, Nov 22, 2022 at 6:22 PM Stavros Koureas
wrote:
>
> Sure, this can be implemented as a subscription option, and it will cover
> this use case scenario as each subscriber points only to one database.
> I also have some more analytical/reporting use-cases which need additions in
>
On Wed, Nov 23, 2022 at 7:38 AM Stavros Koureas
wrote:
>
> Reading more carefully what you described, I think you are interested in
> getting something you call origin from publishers, probably some metadata
> from the publications.
>
> This identifier in those metadata maybe does not have
Reading more carefully what you described, I think you are interested in
getting something you call origin from publishers, probably some metadata from
the publications.
This identifier in those metadata maybe does not have business value on the
reporting side. The idea is to use a value which
Sure, this can be implemented as a subscription option, and it will cover
this use case scenario as each subscriber points only to one database.
I also have some more analytical/reporting use-cases which need additions
in logical-replication, I am not sure if I need to open
different discussions
On Mon, Nov 21, 2022 at 5:05 PM Ashutosh Bapat
wrote:
>
> On Sat, Nov 19, 2022 at 6:47 PM Stavros Koureas
> wrote:
> >
> > What does not support is the option for defining custom column expressions,
> > as keys or values, into the upstream (publication). This will give more
> > flexibility
On Sat, Nov 19, 2022 at 6:47 PM Stavros Koureas
wrote:
>
> Hi all,
>
> Working with PostgreSQL Logical Replication is just great! It helps a lot
> doing real time replication for analytical purposes without using any other
> 3d party service. Although all these years working as product
Hi all,
Working with PostgreSQL Logical Replication is just great! It helps a lot
doing real time replication for analytical purposes without using any other
3d party service. Although all these years working as product architect of
reporting i have noted a few requirements which are always a
18 matches
Mail list logo
