How to maintain CREATE VIEW script in postgres rather than VIEW DEFINITION - postgresql

I am using Postgres Version 9.1 and am having some trouble reviewing past VIEWS that I have created.
Once I create a VIEW, Postgres jumbles up the CREATE VIEW text so it is very unreadable.
For instance, I might create a simple VIEW as:
create view some_view as
select *
from some_table
where some_column = 'some_value';
This then turns into something way more complicated as:
select [all columns...]
from some_table
where (((some_column = 'some_value')));
Now, this is a simple example - however when you get into multiple JOINS and WHERE clauses or SUBQUERIES it gets nearly impossible to read so as to edit the VIEW at a later date.
(The exact location the VIEWS are stored is in information_schema.pg_views if anybody cares to look.)
For that reason I save my CREATE VIEW scripts as a separate .sql file, however this can get taxing and is obviously has the liability of not being sync'd with the current VIEW in the Postgres Database (if you update the VIEW but don't update the .sql file for instance).
It would be MUCH more simple if the plain text of the CREATE VIEW was saved.
When I create a FUNCTION, it saves the script entirely as is with all white-space, etc.
This makes it very simple, at a later date, to review it and see if it needs to be fixed up or spot possible errors.
So my question is if there is some place in the Postgres database where the actual plain-text is saved of the CREATE VIEW statement for later review/editing.
Thank you.

As found, the correct answer is to:
a) Maintain your SQL Scripts in separate files
b) Have a proper versioning system (Git, etc.)
c) Deploy from the versioning system
Done Deal.

Related

Postgresql: create view and use of default tablespace?

When I try to create a view in PostgreSQL 13 I get an error saying: "permission denied for tablespace tbs_dft". As you can see I've changed the system default tablespace. The problem is easy to fix by granting create on tablespace 'tbs_dft'. But my question is: why does it need to access the 'default tablespace' when creating a view containing a simple select statement? Although this is not a practical issue I am trying to learn Postgresql having come from Oracle and hence I'm not sure what it is I don't understand about the way View creation works in Postgresql.
Any information gratefully received.
The reason is that this check is done whenever a relation is created (in DefineRelation in src/backend/commands/tablecmds.c). A relation is anything stored in pg_class: a table, an index, a sequence, a composite type, a view or a materialized view.
Now views or composite types do not have data files, so the check could be skipped in this case. If that is important for you, get in touch with development on the pgsql-hackers mailing list. This could be improved in my opinion.
Here is the code in question:
/* Check permissions except when using database's default */
if (OidIsValid(tablespaceId) && tablespaceId != MyDatabaseTableSpace)
{
AclResult aclresult;
aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(),
ACL_CREATE);
if (aclresult != ACLCHECK_OK)
aclcheck_error(aclresult, OBJECT_TABLESPACE,
get_tablespace_name(tablespaceId));
}

How do I generate a list of views dependent on a certain table in postgresql?

I need to update a mapping table in postgresql, but of course it won't allow me to replace/drop the original table as there are dependencies.
The error message details does list the dependent views, but I'd like to generate a list programmatically so that I can make temp views while I drop my original mapping table and migrate the views back afterwards.
Prefer not to do this in SQL Shell incidentally. Any pointers would be much appreciated.

DB2 AS400 Triggers

I've been tasked with finding a way to migrate data into a DB2 AS400 database. When the data is entered (currently manually) on the front end, the system is doing some calculations and inserting the results in a table.
My understanding is that it's using a trigger to do so. I don't know very much about this stuff, but I have written code to directly insert values into that same table. Is there a way for me to figure out what trigger is being fired when users enter data manually?
I've looked in QSYS2/SYSTRIGGERS and besides not making much sense to me, I see no triggers that belong to the SCHEMA with my table in it.
Any help here would be awesome, as I am stuck.
SELECT *
FROM QSYS2.SYSTRIGGERS
WHERE TABSCHEMA = 'MYSCHEMA'
AND TABNAME = 'MYTABLE'
Should work fine.
If you'd prefer to use a 5250 command line, the Display File Description (DSPFD) command will show you the triggers on a file (table)
DSPFD FILE(MYSCHMA/MYTABLE) TYPE(*TRG)
Lastly, trigger information is available via the IBM i Navigator GUI. Either the older fat client version or the newer web based one.

Is it possible to create table templates in Filemaker?

I'm using Filemaker Pro 12 and I was wondering if there is a way of creating a template for tables. There are a number of fields I'm placing in my tables that are identical utility-fields like modification time-stamp, active/inactive flags, etc. I was hoping there was a way that I could define the skeleton of each table somehow instead of having to manually add these identical fields every time.
If you are using the Advanced version, you can copy&paste fields among tables/files.
Using the regular version, you can import records from your "default" table and specify [New Table...] as the target table. This will recreate the source table's structure in the target file. The source table does not have to contain any records for this to work.
To expand a little bit on michael-hor257k's answer, if you're using FileMaker Pro Advanced, a good practice is to create a "Default" table that has your core utility fields. When you want to make a new table in Manage Database, instead:
Highlight the Default table,
Copy & Paste the table, then
Rename the new table.

Silverlight WCF RIA Service select from SQL View vs SQL Table

I have arrived at this dilemma via a tortuous and frustrating route, but I'll start with where I am right now. For information I'm using VS2010, Silverlight 5 and the latest versions of the Silverlight and RIA Toolkits, SDKs etc.
I have a view in my database (it's actually now an indexed view, but that has made no difference to the behaviour). For testing purposes (and that includes testing my sanity) I have duplicated the view as a Table (ie identical column names and definitions), and inserted all the view rows into the table. So if I SELECT * from the view or the table in Query Analyzer, I get identical results. So far so good.
I create an EDF model in my Silverlight Business Application web project, including all objects.
I create a Domain Service based on the model, and it creates ContextTypes and metadata for both the View and the Table, and associated Query objects.
If I populate a Silverlight ListBox in my Silverlight project via the Table Query, it returns all the data in the table.
If I populate the same ListBox via the View Query, it returns one row only, always the first row in the collection, however it is ordered. In fact, if I delve into the inner workings via the debugger, when it executes the ObjectContext Query in the service, it returns a result set of the correct number of rows, but all the rows are identical! If I order ascending I get n copies of the first row, descending I get n copies of the last row.
Can anyone put me out of my misery here, and tell me why the View doesn't work?
Ade
OK, well that was predictable - nearly every time I ask a question on a forum I stumble across the answer while I'm waiting for responses to flood in!
Despite having been through the metadata and model.designer files and made sure that all "view" and "table" class/method definitions etc were identical, it was still showing the exasperating difference in behaviour between view and table queries. So the problem just had to be caused by the database, right?
Sure enough, I hadn't noticed myself creating NOT NULL columns when I created the "identical" Table version of my view! Even though I was using a SELECT NEWID() to create a unique key column on the view, the database insisted that the ID column in the view was NULLABLE, and it was apparently this which was causing the problem.
To save some storage space I switched from using NEWID() to using ROW_NUMBER() to create my key column, but still had the "NULLABLE" property problem. SO I then changed it to
SELECT ISNULL(ROW_NUMBER() (OVER...) , -1)
for the ID column, and at last the column in the view was created NOT NULL! Even though neither NEWID() nor ROW_NUMBER() can ever generate NULL output, it seems you have to hold SQL Server's hand and reassure it by using the ISNULL operator before it will believe itself.
Having done this, deleted/recreated my model and service files, everything burst into glorious technicolour life without any manual additions of [Key()] properties or anything else. The problem had been with the database all along, and NOT with the Model/Service/Metadata definitions.
Hope this saves someone some time. Now all I need to do is work out why the original stored procedure method I started with two days ago doesn't work - but at least I now have a hint!
Ade