Re: Assign User Defined DataType To Columns

[David G. Johnston]

On Wed, Aug 2, 2023 at 9:24 AM Phani Prathyush Somayajula <
phani.somayaj...@pragmaticplay.com> wrote:

> Hi All,
>
>
>
> I’ve a user defined data type as :
>
> CREATE TYPE uibackend."_operation" (
>

If you find yourself writing user-space code that uses "_{data type}" you
are doing something wrong.  That implementation detail is not something
that is exposed to the user.  If you want to deal with arrays of a type you
say:  {data type}[]

So casting some random text column to an array of operation is simply:

operation_text_col::operation[]

And you can get rid of the above CREATE TYPE command altogether.

David J.

Re: Query Tool Initialization Error

[David G. Johnston]

On Sat, May 19, 2018 at 6:14 AM, Chris @ Home 
wrote:

> I decided to switch to SQL Server. Life is too short to debug open source
> database tools!
>
>
​Just for the record pgAdmin is a third-party tool unaffiliated with the
PostgreSQL Database Server project (for better and worse there isn't an
official GUI application)​.

I'm sure you can find a different open source or commercial tool that will
serve your needs and allow you to realize whatever advantages you imagined
when you initially choose to use the PostgreSQL Server.

David J.

Re: Table column headings PgAmin4

[David G. Johnston]

On Wed, Feb 7, 2018 at 1:00 PM, Strauch, Sheldon  wrote:

> Ted and David,
>
> Howdy! I too desperately crave this feature in pgAdmin. In light of the
> fact that there are now three of us interested in this, I have created the
> feature request in RedMine: https://redmine.postgresql.org/issues/3092
>
> Hopefully, this helps the cause...
>

I don't use pgAdmin - and would am more inclined to learn a tool that
facilitates CLI access for this kind of thing in any case.  Its just that
when I do have a need I can add the CREATE TABLE to a psql script easily
enough that having to run the import routine through anything other than
COPY (or \copy) doesn't seem worth the added dependency.

David J.
​

Re: Table column headings PgAmin4

[David G. Johnston]

On Wed, Feb 7, 2018 at 11:47 AM, Ted Jones  wrote:

> Hi David
>
> I'm sorry but I'm not sure what you mean! Can you give me a simple
> example? Thanks.
>
>
​Something like in the attached image.​

 [image: Inline image 1]

Re: Table column headings PgAmin4

[David G. Johnston]

On Wed, Feb 7, 2018 at 11:01 AM, Ted Jones  wrote:

> Hi Murtuza
>
> Thank you for your reply. Unfortunately it is not practical to use this
> approach when there may be 100s of columns! I will look at pgfutter.
>

​When faced with this situation, and feeling unmotivated to go learn a new
tool, I resort to a spreadsheet​.  You can easily build a CREATE TABLE
statement in the spreadsheet after split-copy-transpose-pasting the header
row (appending "text," to each row's column label is a simply formula).

David J.

Re: Problems connecting PGAdmin to server

[David G. Johnston]

On Mon, Jan 29, 2018 at 8:46 AM, Samuel Holmes 
wrote:

> I am using Pgadmin as a frontend to maintain a Postgresql database hosted
> on Heroku.  If I connect to the database from my home wifi connection, it
> connects successfully.  It also connects successfully if I tether using my
> mobile phone.  However if I use my university’s student WiFi, I cannot
> connect and I get the following error:
>
>
>
> could not connect to server: Connection timed out (0x274C/10060) Is
> the server running on host  () and accepting TCP/IP
> connections on port 5432?
>
>
>
> How do I even begin to troubleshoot this?  I have checked that Pgadmin has
> permission in my firewall (it does), and I have checked that port,
> username, host, and password are correct (which they are as it works from
> home).  I thought maybe the port was blocked, so I used an online port
> checker – while it DID say port 5432 was closed on my university WiFi it
> also says this when tethered with my phone – but the connection DOES work
> on my phone.
>

Two simple possibilities:
Heroku is blocking on their (the server) side, not yours (the client).​
The University is blocking outbound traffic on that port.

I suspect you can check and configure the first one; the second one you'd
need to inquire with your university's IT department.

You are using the same machine at home and at the university?  If so that
should preclude it being your machine (though its possible your firewall
has different settings when connected to the different wifi networks).

Online port checkers are prone to false negatives.

David J.

Re: function import/export pgadmin4

[David G. Johnston]

On Tue, Dec 19, 2017 at 10:42 AM, QUIDOZ Marie-Claude <
marie-claude.qui...@cefe.cnrs.fr> wrote:

> In the PGADMIN4 server version, you have programmed the COPY command. For
> a simple user (without right on the server), the \ COPY meta command will
> be more useful.
>

​pgAdmin should (I've only used it minimally and not v4) indeed implement
file export/import via SQL "COPY" (and a custom UI, not a query window) -
and would arrange for the proper command syntax and making the relevant
data available on the server's stdin (COPY FROM) or take the server's
response via stdout (COPY TO) and turn it into a file for you.

If you simply type "COPY" into a SQL query window and send it to the server
pgAdmin probably doesn't do anything special and you end up with whatever
normal behavior such a copy would entail.  That probably includes placing
non-SQL text (i.e., csv data) into the query screen and sending it to the
server for processing - just like you can in a psql script (i.e., COPY in
psql works with inline data).

pgAdmin doesn't have a text/CLI language that would control the application
like psql does.  Adding it simply for "\copy" is likely to fail a
cost/benefit analysis.​

In short, you can (probably) do everything you need to with the tools as
they exist today.  You might need to learn more about how they work, though.

David J.

Re: No commit nor Rollback button

[David G. Johnston]

On Tue, Oct 17, 2017 at 1:07 AM, Dave Page  wrote:

> I can see why for some people who choose to turn auto-commit/auto-rollback
> off they may be useful, however we cannot simply add new features every
> time someone asks for something. Doing so adds maintenance costs, and
> increases complexity of the UI for *everyone*. That is part of the reason
> why pgAdmin III became unmaintainable; we added too many features on a whim
> without giving enough thought to whether or not the added code and UI
> complexity was justified, and eventually ended up with a mess of
> spaghetti-code.
>
>
​So consider the lack of requests to be not so lacking anymore...

One concrete advantage to the buttons, and mind you I haven't actually used
pgAdmin4 but do use a GUI, is that in my GUI if you were to send the COMMIT
command to the server as text any and all result set tables that are
present on the current screen are removed the a new command result for the
commit response replaces them.  If one uses the button the result tables
are left alone.

Frankly, auto-commit mode can be dangerous so if you are advocating that
people simply use that and forget about manually committing altogether I
think you are misguided in your thinking.​  In the UI that I use if I send
a "begin" to the server then, and only then, do the commit/rollback buttons
appear (and auto-commit is disabled temporarily).  With that flow your
"end-user UI complexity" argument becomes significantly more specious and
you are just left with "code complexity".

David J.

Re: No commit nor Rollback button

[David G. Johnston]

On Mon, Oct 16, 2017 at 11:16 AM, Melvin Davidson 
wrote:

> *You don't need buttons.*
>

> *Just go to *
> *File*
> *  Preferences*
> *SQL Editor*
>
> *and change Auto commit?   to False*
>
> *   and Auto rollback? to False*
>
> *Or whatever you prefer.*
>
> *That is what those options are for!*
>
> *Or learn how to use a TRANSACTION in PostgreSQL.*
> *IE: *
> *BEGIN;*
>
>
​Personally, if I'm in a GUI I'd prefer buttons.  They both allow one to
quickly see whether they are in a transaction or not (by greying out the
buttons when their use is not applicable) and provide a mouse user a very
quick way to commit/rollback the query they just executed via clicking the
"run query" button.

This has absolutely nothing to do with "Auto Commit/Rollback" other than
the buttons would only be meaningful when said option is disabled.

​David J.