I get postgresql database at my work, it was managed by person whos not work anymore there, there is no documentation and I have very little experience with postgresql.
The thing is that one table is no longer updated, my question is how can I find in workbench what code actually updates the table. I was googling workbench documentation and also trying to find it in this program but with no luck.
I don't know anything about "workbench" but it doesn't seem as if this tool is going to help you much in your investigation.
As suggested by #AdamKG, scan your codebase.
If you have DB logs from when the table used to get updated, then you might be able to find clues from there: User IP, application name, DB user name, SQL, etc. This depends heavily on your DB logging parameters. And your logs retention policy, of course...
Related
I'm relatively new to working with databases and I'm having trouble with Azure Data Studio (v1.25.1) not displaying how many rows are being affected with UPDATE statements. I need to make some small changes to PostgreSQL databases in my day to day work role, and due to my lack of experience I want to be very cautious to avoid updating every row in the table.
When I run a simple SELECT statement, the messages pane displays how many rows were affected by my statement.
However, when I run an update statement, I'm not being provided any information on how many rows were affected.
I'm using transactions to ensure I catch any mistakes, but without any information being provided as to how many rows were affected, it's difficult to identify if I've made a mistake.
I've seen solutions using GET DIAGNOSTICS, but I'm not working with PL/pgSQL and so this won't work. I've looked for issues on the official Postgres extension github page (https://github.com/microsoft/azuredatastudio-postgresql) but can't find anything.
I'm not sure if this is an issue specific to Postgres, or if this is just an issue with Azure Data Studio.
If anyone could shed some light onto how to make sure this information displays then I'd be incredibly grateful.
I'm also new to stack overflow, and so please correct me if I've made any faux pas.
OS: Ubuntu 20.04
Azure-data-studio: v1.25.1
Postgres-extension: v0.2.7
I have to generate a report that shows eventual SQL injection attempts.
I've seen many threads about this topic and I have a general understanding of the argument, but I've never done an actual report of the possible attempts.
I was thinking to save the queries that my app executes (through forms and other actions on the website) into a table on the DB and then scan this table and look for specific words (like Union, Drop and the likes) to see if there's something suspicious going on.
This way, I can then show the table and the suspicious activities on an admin panel on the app for a quick check of the activities.
Do you guys think this is a viable solution? What would you recommend to do otherwise?
Thanks.
While the current connection is made to db1, I want to change privileges on db2. Like:
GRANT ALL PRIVILEGES ON SCHEMA "db2"."public" TO "user";
But this results in error, and PostgreSQL does not recognize the database qualifier in the statement! Is there any way I can do this without disconnecting from db1 and reconnecting to db2?
BTW, I'm commencing these commands from a programming language and not the psql.
[UPDATE]
As I was told in comments, it seems that this feature is intentionally blocked (due to implementation challenges or security reasons - I'm not sure).
In any case, I don't see a good reason for that and that's my personal opinion. If it is hard to implement, then it's a design flaw. And I think the security argument can be easily scratched as adding steps to the process for a user who's already been authenticated and authorized to do so, is not considered a better security.
Again, just my opinion.
In any case, I'm really thankful for all the time and effort put into PostgreSQL project. Thanks guys.
First, I don't know if this is by intent or by the lack of implementation but this is a long-standing behavior in PostgreSQL. There are no cross-database references. There are a number of reasons why at present there probably never will be, especially the difficulty in doing things like making the system catalogs behave properly. Basically, database A has no knowledge of the structures in database B.
Secondly, cross-database information sharing is also a little inconsistent in PostgreSQL. pg_locks (for some strange reason) shows all across all databases. So I am thinking that this is probably an organic development rather than people sitting down and coming up with a policy on this. Similarly, as you are probably aware, roles and users are cluster-global. So I can see why this would seem a little bit inconsistent.
The correct way to do this in PostgreSQL is to connect to the DB you want to manage permissions in. There is no other way currently for PostgreSQL to get access to the appropriate catalog entries and modify them and the changes are likely to be so breaking that such seems to me to be unlikely to ever happen.
I decided to give PostgreSQL a try. It looks really interesting, but it isn't very user friendly at all.
I got some great help from the PostgreSQL e-mail list, but they insist that the tool to use is the command-line editor (PSQL). Unfortunately, it's a total disaster. When I open it, it opens at least two instances, which soon multiply into a dozen. It also seems to somehow hijack my Apple terminal on my Mac. I can type the same command into two different terminal boxes and get two different results. I don't have a clue what's going on.
Anyway, to get to the point, PostgreSQL is obviously over my head. There's a local PostgreSQL users group that meets once a month - at night, when I'm working. But I'd like to try and make the very beginning of their next meeting and drop them a note. I'd like to hire someone to help me get PostgreSQL set up on my laptop and online, fix whatever the problem is and show me how to create a database and table.
Actually, I've already created a database and table, which I can access with pgAdmin III. But I can't see them with the shell/ terminal. So that's my question: If I can hire someone to get PostgreSQL up and running, will I be able to work with it using pgAdmin III or some other tool, or am I going to be chained to the shell (PSGL)?
If the shell/terminal is indispensable, then I think I'm going to abandon it. It looks like a great program, but I just don't have time to jump through all the hoops right now.
You don't need psql to use PostgreSQL. Many experienced users prefer it, but you can use nothing but PgAdmin and get by just fine. That's what a great many users do.
PostgreSQL is fine on Mac OS X. A number of core developers use Mac OS X and do their development on it. Much like many MySQL users use phpmyadmin, etc, and never use the mysql command line tool.
There were some packaging issues on OS X related to Apple's bundling of PostgreSQL but those are resolved in more recent versions of OS X.
There are also some challenges with different packages of PostgreSQL on OS X - EnterpriseDB, Macports, Homebrew, etc. But those are mostly a matter of documentation and user misunderstanding; each package is in its self just fine. Similar issues exist on Linux, where OS packages, PGDG packages, and EDB's packages can tread on each others' toes.
Characterising the PostgreSQL community as a "Microsoft/Linux fan club" is hilarious, by the way. Windows is tolerated at best by most of the core devs and users on the mailing list.
It's really hard to tell what problem you're encountering based on the description given. Maybe you have multiple different PostgreSQL packages installed, so you have more than one server instance, and are getting them confused? Similarly, I can't tell what's going on with the psql terminal link in the dock. I'd ignore it and use psql from the usual Apple Terminal.app if you want to use psql. Otherwise just use PgAdmin.
One area where you will run into trouble is that because most experienced users use psql, if you ask questions specific to PgAdmin or other tools, rather than PostgreSQL its self, people will pretty much shrug their shoulders and say "dunno, but you do it like in psql". I haven't used PgAdmin for my own stuff in years, and have to go hunting around in the manual if I want to figure out how to do something so I can explain it to somebody. Moreso with things like Navicat, which I've never used at all. The people who use those tools are usually not the ones spending their time helping other people out, so you get help from experienced and enthusiastic users who're also the ones most likely to use the expert-oriented tools.
Relevant link: http://phili.pe/posts/postgresql-on-the-command-line/
I've been using DBeaver to write and execute my Postgres queries because I don't like neither psql nor PgAdmin. Not that DBeaver is without its faults but at least it has decent code completion and an easy way to switch databases / schemas. In the end it's also about what you're used to and I guess coming form SQL Server with Management Studio I found this an easier way in into Postgres.
It's true that in most Postgres books psql is the standard but I usually try to convert the psql specific code to queries I can run in DBeaver, which is usually an interesting (although somewhat frustrating at times) exercise...
I just installed my oracle database and made some tables for school. My problem is that it looked kind of different because the one we use in school had no tables(clean and empty) but the one that I had installed is filled with tables that I do not understand(I did not make them either).
It is a new install I got from the official website and it had tables named like: AQ$_INTERNET_AGENT_PRIVS, AQ$QUEUES and much more. I have no idea where they come from and every time I go look at my tables I just get confused because of all these things mixed in.
Is it safe to remove them or are they important enough to keep? If removing them is a bad idea, what do I have to do so that I don't see them anymore and all that is listed are the tables that I have created myself?
Those are system tables, you're probably logging in to an account with DBA privileges. Create yourself a new schema (user_id/password) and don't give yourself dba privileges, then you can remain as ignorant as you want about what Oracle is doing under the hood.