Re: Extra Paranthesis on joins on saving a view

Thanks for your reply on all the items. I've created a ticket with ID 6061 for the parens issue.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 3, 2020 12:50 AM, Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com> wrote:

> Hi Alex,
>
> On Thu, Dec 3, 2020 at 7:14 AM Alex Williams <valenceshell(at)protonmail(dot)com> wrote:
>
>> Hi,
>>
>> I'm not sure if this is something new but in previous versions of pgadmin (currently using 4.27 where this is happening,) when creating a view, more or less, my original sql was maintained, but now it's mangling the joins like MS Access does with the Jet database with lots of parenthesis's (yes, I still use Access 2000.) Is there a way to disable this? I find it very difficult to parse and wind up removing them all only to have come back when saved when I'm done modifying / saving the view.
>
> Can you please log the request here - https://redmine.postgresql.org/projects/pgadmin4/issues/new with sample DDL so we can work on it ?
>
>> Also, can you:
>> 1. Allow renaming tables/functions/etc... without having to invoke properties....it's very slow sometimes to bring up that dialog....and sometimes I use rename just to copy a object name, not to rename it.
>
> You can drag the object directly to query tool, it will copy the object name and paste it.
>
>> 2. When running View/Edit->First 100 Rows, can you not lock it, i.e., it's a convenient way to have the select statement written without typing and then you add the predicates/joins.
>
> Yes there is a similar request logged, and will be considered for a future release.
>
>> 3. When creating a table, can you please allow rearranging of the columns.
>
> Rearranging columns is not traditionally supported by PostgreSQL. One needs to create a new table with new column order, copy the data to the new table, drop the old table and rename the new one. pgAdmin does not want to go in this complexity as it is prone to error and might cause user data loss. Unfortunately, this request cannot be completed as of now.
>
>> Thanks,
>>
>> Alex
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin hacker | Sr. Software Engineer | edbpostgres.com
> "Don't Complain about Heat, Plant a TREE"