Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsprM-0001yz-1K for pgsql-admin@arkaria.postgresql.org; Wed, 31 Jul 2019 14:45:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hsprK-0008BD-91 for pgsql-admin@arkaria.postgresql.org; Wed, 31 Jul 2019 14:45:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsprJ-0008B5-Tm for pgsql-admin@lists.postgresql.org; Wed, 31 Jul 2019 14:45:42 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hspqw-0003Te-JY for pgsql-admin@lists.postgresql.org; Wed, 31 Jul 2019 14:45:41 +0000 Received: by mail-wm1-x32a.google.com with SMTP id h19so1468917wme.0 for ; Wed, 31 Jul 2019 07:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=lrbUQ0Fcb5G6e/oonbk0mzaGShs0ZKr3pKS49fDAlfI=; b=PtPkVrd55f4ihQFHUsR1pQ0wgfVv1WavlbUf2OEk/UWG19Sn5TUPBJqxojXKBaziC+ mpv2PGZe8yKpIj2pcRrZnNCuK4AgYV9De+5SM9j2g2R5XBUymJCDqLo9KfSxD68N5bU7 GupFBmKiLhTiiR3kKid+ylhlXDtqx/jcZEnjVr/nYjHJN+aa4kQecyTXToHwe6xVU5TP 6GMvOg+peVW9EcTELu1BDjdCclpUFqAhkNqtZxioqSqeOcI1ZhupNXnA45AwjTrap6ee CiUZUaZ0Wfg4X6cJJYu5WZCYMU82ZCG0s7FU0NxDQQyv2nNF2k57Y5/s+JPsOVLk+wuJ ysjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=lrbUQ0Fcb5G6e/oonbk0mzaGShs0ZKr3pKS49fDAlfI=; b=n/lPggOcwfyqar3VfqaNVe5nPSrRQ3msN8g+nChG6PZHeHUkbZhaDCP8H1SXUoZS5I ZfyzDYjpNPtR3U0Psgb8qUAZeOyBZnL2Am+/4hRzqvRGvBsCatWBzMfXRTJ61AL/d9cC FlRSfo1T1gP5/IyygrbtfZ0VXI7U4rcS13czC1xl2OVZQivyp8sd7N3pFxP2WYh8WRvI AFKnI97sjpzBrhP/VzNiycSheSC2IMJdvmblgJ6DboZdXHqwUDj2YDpypCKIKKN5hYw/ BuxTcJFPBxMz5TEqT33oB3iVYyXJiflYDReN6fBKYXF7UWe2Mt6oDDhEWamV7kc8/pEu CY8Q== X-Gm-Message-State: APjAAAVxcKccjpNIFRJ8GTtJqp3oAxGTUIcI6i3uFlgAqZ115oGnP3pL qL7DkbdNroBbX5QrX4vL5wrqz9jd7Yc= X-Google-Smtp-Source: APXvYqy/WuKgwHN/sLrb97H0bVVjNOtk4MDmbptNuJK2s49JlwFDfFJfFWVjdkWLgEc5sNz1x5tpAg== X-Received: by 2002:a05:600c:214c:: with SMTP id v12mr111404485wml.28.1564584313805; Wed, 31 Jul 2019 07:45:13 -0700 (PDT) Received: from [192.168.0.210] (melany.rs. [178.254.155.58]) by smtp.gmail.com with ESMTPSA id j10sm118639911wrd.26.2019.07.31.07.45.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 07:45:12 -0700 (PDT) To: pgsql-admin@lists.postgresql.org From: Milan Oparnica Subject: Managing 'Operators' in pgAdmin4 Message-ID: <3bfeb282-9b69-c636-309d-bb8b59b6e632@gmail.com> Date: Wed, 31 Jul 2019 16:45:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A0E089CDED762AC570A410F7" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------A0E089CDED762AC570A410F7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I like the fresh and modern approach that pgAdmin4 offers, updating instantly when new versions pop-up praying to find few options I still miss from pgAdmin3. Working with 'Operators' objects ==================== Is there any chance you could reconsider the decision not to support Operators objects in pgAdmin4 ? I'm sure we're not the only one to use them - as they proved to be a great tool when migrating software from other database platforms. They provide easiest way of handling certain date and string crucial operations that differ from pg implementation. Best regards, Milan Oparnica --------------A0E089CDED762AC570A410F7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello,

I like the fresh and modern approach that pgAdmin4 offers, updating instantly when new versions pop-up praying to find few options I still miss from pgAdmin3.

Working with 'Operators' objects
====================

Is there any chance you could reconsider the decision not to support Operators objects in pgAdmin4 ?
I'm sure we're not the only one to use them - as they proved to be a great tool when migrating software from other database platforms.

They provide easiest way of handling certain date and string crucial operations that differ from pg implementation.


Best regards,

Milan Oparnica

--------------A0E089CDED762AC570A410F7--