Re: schema diff tool problem with owner statements

[Akshay Joshi]

Hi

On Fri, Nov 12, 2021 at 8:47 PM  wrote:

> Thanks for the reply, comment embedded below:
> On 11/11/21 11:58 PM, Akshay Joshi wrote:
>
> Hi
>
> On Fri, Nov 12, 2021 at 12:45 AM  wrote:
>
>> I'm trying to compare 2 schemas (devschema is the source and testschema
>> is the target) and generate a script that can be run on the target that
>> will create the missing tables.  I ran the schema diff, and it generated
>> items like this:
>>
>> CREATE TABLE IF NOT EXISTS tablename
>> (
>> fields, etc
>> )
>> TABLESPACE pg_default;
>>
>> ALTER TABLE IF EXISTS public.tablename
>>  OWNER to devschema;
>>
>>
>> When I run the script on testschema, I don't want it trying to alter the
>> owner of the table because that statement will fail anyway.
>>
>> I found a setting in "preferences" called "ignore owner", and set it to
>> true (If set to True, then the Schema Diff tool ignores the owner while
>> comparing the objects.)
>>
>> However, this setting has no effect.  The alter table statements still
>> get generated, and I am left to remove them manually.
>>
>> If there is something I'm doing wrong please let me now.  I swear this
>> setting worked many months ago when I used this tool, but it seems to
>> not be working now.
>>
>> Version 6.1 (downloaded and updated today)
>>
>
> This is by design, as at the time of comparison or generating the
> script we can't check the owner is exist on the target schema or not.
> Consider the case where the owner exists and the user wants to run the same
> DDL statement. I think the user needs to manually change the ow
>
> ner. There is a find and replace option in the query tool by which we can
> easily replace.
>
> Maybe I'm missing something (I don't know a lot about postgres internals,
> all I want is to copy tables over).  That setting in the preferences SEEMS
> to be what I need here.  I'd simply like the diff tool to ignore the
> differences in the owner, and not generate the "ALTER TABLE IF EXISTS
> public.tablename  OWNER to devschema;" statement.  My script will run fine
> on the target if I delete all those alter table statements, and it will
> also run fine if I search and replace 'devschema' with 'testschema', but
> I'd rather not have to do either of those.  Isn't this a common use case
> when the user wants to get 2 schemas "in sync" but they don't care about
> the fact that the owner of the objects on the source and target is
> different..?
>

I understood the scenario, but the most common use case that I have
seen is to make 2 schemas "in sync" with the appropriate owner. In such a
case, users will have to write the complete ALTER statement for each object
which is more time-consuming (find all the create statements and write
ALTER..) then find and replace.

I'll suggest you create a new feature request
https://redmine.postgresql.org/projects/pgadmin4/issues/new will check the
feasibility.

>
>> Thank you,
>>
>> Wes
>>
>>
>>
>>
>
> --
> *Thanks & Regards*
> *Akshay Joshi*
> *pgAdmin Hacker | Principal Software Architect*
> *EDB Postgres *
>
> *Mobile: +91 976-788-8246 *
>
>

-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

Re: pgadmin4 for fedora 35

[Dave Page]

Hi

On Sat, Nov 13, 2021 at 3:48 PM toni incog  wrote:

> Lo and behold, I just upgraded a laptop to f35 with pgadmin4 still
> installed and it was enough to install python9 to get a running
> desktop version. So when upgrading don't rm pgadmin, disable the
> pgadmin repo and afterwards install python9. Not sure if that will
> work for the web version.
>

That's good to know - thanks for the info.


>
> On Tue, 9 Nov 2021 at 17:35, richard coleman
>  wrote:
> >
> > Dave,
> >
> > Good to know,
> >
> > thanks,
> > rik.
> >
> >
> > On Tue, Nov 9, 2021 at 8:43 AM Dave Page 
> wrote:
> >>
> >> Hi
> >>
> >> On Tue, Nov 9, 2021 at 12:41 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
> >>>
> >>> Dave,
> >>>
> >>> Have you ever considered using something like flatpak (
> https://flatpak.org/ ) for the Linux versions of pgAdmin?  It might; make
> it easier to handle the many different distributions, and deal with the
> different release schedules of the many dependencies that pgAdmin relies
> upon.
> >>
> >>
> >> Technologies like Flatpak make it significantly harder to maintain
> applications like pgAdmin, and for system administrators to ensure their
> systems are secure. This is primarily because they bundle third party
> libraries within the application package, which means that every time there
> is a security update to a library such as OpenSSL, we need to update the
> package we distribute, and the system administrator can't simply do a yum
> update or equivalent and be sure that their system is as secure as
> possible. It also means end users need to install a separate package
> management tool from the one that is native to their system.
> >>
> >> So, whilst (if we had the resources) I wouldn't object to supporting
> Flatpak and similar, I would certainly not want them to replace the
> standard native packages as the primary offering.
> >>
> >>>
> >>>
> >>> Just a thought.
> >>>
> >>> rik.
> >>>
> >>>
> >>> On Tue, Nov 9, 2021 at 4:23 AM Dave Page 
> wrote:
> 
> 
> 
>  On Tue, Nov 9, 2021 at 8:11 AM toni incog 
> wrote:
> >
> > fwiw That didn't work out. Symlinks where pointing to 3.9 though I
> > stopped at  Failed to exec Python script file
> > '/usr/pgadmin4/web/pgAdmin4.wsgi'... ModuleNotFoundError: No module
> > named 'flask'
> 
> 
>  :-(.
> 
> >
> > I guess I've to practice some patience.
> 
> 
>  Yeah, unfortunately. The issue is that one of the upstream libraries
> we use doesn't have a release that supports Python 3.10 yet. We have all
> the build system etc. setup and ready to go, but until they put out a new
> release we're kinda stuck.
> 
> >
> >
> > On Mon, 8 Nov 2021 at 10:01, toni incog 
> wrote:
> > >
> > > Ok, then I give that a try, thx!
> > >
> > > On Mon, 8 Nov 2021 at 09:56, Dave Page 
> wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Nov 8, 2021 at 8:34 AM Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Nov 8, 2021 at 1:28 PM toni incog 
> wrote:
> > > >>>
> > > >>> No easy way to fallback to python 3.9 in f35? 3.9 is
> installable fwiw
> > > >>
> > > >> I'm not aware of any. @Dave do you have any ?
> > > >
> > > >
> > > > The F34 packages might work if you have 3.9 installed (I *think*
> the symlinks in our venv should still point to the correct locations in
> that case). There may be other things that don't work though.
> > > >
> > > >>>
> > > >>>
> > > >>> On Mon, 8 Nov 2021 at 06:17, Aditya Toshniwal
> > > >>>  wrote:
> > > >>> >
> > > >>> > Hi Toni,
> > > >>> >
> > > >>> > All of the python packages used by pgAdmin are not yet
> available for 3.10. We're continuously testing pgAdmin on v3.10 to make it
> work.
> > > >>> > Once pgAdmin works on v3.10, F35 builds can be made
> available.
> > > >>> >
> > > >>> > On Sat, Nov 6, 2021 at 6:35 PM toni incog <
> toni.in...@gmail.com> wrote:
> > > >>> >>
> > > >>> >> No yum repos for f35 yet. Using the 34 repos has troubles
> with f35
> > > >>> >> python3.10. Any fast solution for this? Is installing
> python3.9 an
> > > >>> >> option. I'm not familiar with this pyhton world but became
> dependend
> > > >>> >> on pgadmin4.
> > > >>> >>
> > > >>> >> thx
> > > >>> >>
> > > >>> >>
> > > >>> >
> > > >>> >
> > > >>> > --
> > > >>> > Thanks,
> > > >>> > Aditya Toshniwal
> > > >>> > pgAdmin Hacker | Software Architect | edbpostgres.com
> > > >>> > "Don't Complain about Heat, Plant a TREE"
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Thanks,
> > > >> Aditya Toshniwal
> > > >> pgAdmin Hacker | Software Architect | edbpostgres.com
> > > >> "Don't Complain about Heat, Plant a TREE"
> > > >
> > > >
> > > >
> > > > --
> > > > Dave Page
> > > > VP, Chief A