postgresql创建视图权限的简单介绍

Postgresql创建视图后修改基础表的问题

针对上面的select * 创建的视图获取到基础表的所有字段内容，我们做一个测试，不难发现在基础表上新增字段后，对已建的视图是没有影响的，新的字段内容并不会自动添加到视图上。

对于被视图引用的字段，是不允许被修改类型的，如果需要修改类型，需要先删掉视图，修改后再重建视图。

可以看到修改基础表的字段名，对应视图的的字段名称没有自动同步过来，是没有生效的。

同样，被视图引用的字段，是不允许被修改字段长度的。

除了以上所提到的问题，还有其他的内容，欢迎遇到问题的pger前来补充。

postgresql怎么给一个用户赋予权限

grant db_role1 to db_user1,db_user2; 意为：给用户1,2赋予角色1,两个用户就拥有了角色1对应的权限。

1、角色

PostgreSQL使用角色的概念管理数据库访问权限。 根据角色自身的设置不同，一个角色可以看作是一个数据库用户，或者一组数据库用户。 角色可以拥有数据库对象（比如表）以及可以把这些对象上的权限赋予其它角色， 以控制谁拥有访问哪些对象的权限。

2、角色的权限

一个数据库角色可以有很多权限，这些权限定义了角色和拥有角色的用户可以做的事情。

3、用户

其实用户和角色都是角色，只是用户是具有登录权限的角色。

4、赋予角色控制权限

可以使用GRANT 和REVOKE命令赋予用户角色，来控制权限。

如：

create role db_role1 createdb createrole; --创建角色1

grant db_role1 to db_user1,db_user2; --给用户1,2赋予角色1,两个用户就拥有了创建数据库和创建角色的权限

revoke db_role1 from db_user1; --从用户1移除角色1，用户不再拥有角色1的权限。

扩展资料

1、角色权限相关脚本

create role db_role1 LOGIN; --创建具有登录权限的角色db_role1

create role db_role2 SUPERUSER; --创建具有超级用户权限的角色

create role db_role3 CREATEDB; --创建具有创建数据库权限的角色

create role db_role4 CREATEROLE --创建具有创建角色权限的角色

alter role db_role1 nologin nocreatedb; --修改角色取消登录和创建数据库权限

2、用户相关脚本

create user db_user1 password '123'; --创建用户

create role db_user1 password '123' LOGIN; --同上一句等价

drop user db_user1; --删除用户

alter user db_user1 password '123456'; --修改密码

alter user db_user1 createdb createrole; --对用户授权

参考资料

百度百科-postgresql

PostgreSQL 源码解读（24）- 查询语句#9（查询重写）

本节简单介绍了PG查询语句优化部分查询重写相关的内容。查询重写在pg_rewrite_query函数中实现，该函数位于文件postgres.c中。

可以把查询重写系统当作某种宏展开的机制。

创建视图的SQL命令:

与下面两个命令相比没有什么不同:

查询重写前的Query结构:

查询重写后的Query结构:

pg_rewrite_query

QueryRewrite

fireRIRrules

ApplyRetrieveRule

SQL语句:

启动gdb，跟踪调试：

RewriteRule

1、查询重写：简单介绍了查询重写的基本概念以及改写前后的异同；

2、重写实现：通过跟踪分析，PG利用系统定义的规则进行重写，定义的规则Actions为Query结构，重写后在Query中把视图转变为子查询。

mysql front与mysql有什么区别 知乎

这两个产品都属于开放源码的一员，性能和功能都在高速地提高和增强。MySQL AB的人们和PostgreSQL的开发者们都在尽可能地把各自的数据库改得越来越好，所以对于任何商业数据库使用其中的任何一个都不能算是错误的选择。

MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。

这样的两种背景直接导致了各自固有的优点和缺点。

1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣称速度是他们追求的主要目标之一，基于这个原因，MySQL在以前的文档中也曾经说过并不准备支持事务和触发器。但是在最新的文档中，我们看到MySQL 4.0.2-alpha已经开始支持事务，而且在MySQL的TODO中，对触发器、约束这样的注定会降低速度的功能也列入了日程。但是，我们仍然有理由相信，MySQL将有可能一直保持速度的优势。

2、MySQL比PostgreSQL更流行，流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。

3、与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在 NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。

4、MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。

5、MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。

6、MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的 INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限， PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。

7、由于MySQL 4.0.2-alpha开始支持事务的概念，因此事务对于MySQL不再仅仅成为劣势。相反，因为MySQL保留无事务的表类型。这就为用户提供了更多的选择。

8、MySQL的MERGE表提供了一个独特管理多个表的方法。

9、MySQL的myisampack可以对只读表进行压缩，此后仍然可以直接访问该表中的行。

1、对事务的支持与MySQL相比，经历了更为彻底的测试。对于一个严肃的商业应用来说，事务的支持是不可或缺的。

2、MySQL对于无事务的MyISAM表。采用表锁定，一个长时间运行的查询很可能会长时间地阻碍对表的更新。而PostgreSQL不存在这样的问题。

3、PostgreSQL支持存储过程，而目前MySQL不支持，对于一个严肃的商业应用来说，作为数据库本身，有众多的商业逻辑的存在，此时使用存储过程可以在较少地增加数据库服务器的负担的前提下，对这样的商业逻辑进行封装，并可以利用数据库服务器本身的内在机制对存储过程的执行进行优化。此外存储过程的存在也避免了在网络上大量的原始的SQL语句的传输，这样的优势是显而易见的。

4、对视图的支持，视图的存在同样可以最大限度地利用数据库服务器内在的优化机制。而且对于视图权限的合理使用，事实上可以提供行级别的权限，这是MySQL的权限系统所无法实现的。

5、对触发器的支持，触发器的存在不可避免的会影响数据库运行的效率，但是与此同时，触发器的存在也有利于对商业逻辑的封装，可以减少应用程序中对同一商业逻辑的重复控制。合理地使用触发器也有利于保证数据的完整性。

6、对约束的支持。约束的作用更多地表现在对数据完整性的保证上，合理地使用约束，也可以减少编程的工作量。

7、对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。

8、支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。

9、PostgreSQL可以更方便地使用UDF(用户定义函数)进行扩展。

这个问题很难说得清，而

且事实上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的选择。如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的。1、如果你的操作系统是Windows，你应该使用MySQL。

2、如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。

3、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如是一个论坛和社区，你应该使用MySQL。

4、你的应用是一个严肃的商业应用，对数据完整性要求很高。而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。

5、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。

6、你是一个数据库内核的狂热爱好者，你甚至希望拥有你自己版本的数据库，毫无疑问，你必须使用PostgreSQL，没准下一个PostgreSQL版本中某一个模块的作者就是你。

以上只是作者从自己的理解尽量客观公正地评价MySQL和PostgreSQL的优劣。其中的带有倾向性的意见只代表作者个人观点，有关这两个数据库，欢迎广大朋友提出自己的看法。

postgresql创建视图权限的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、postgresql创建视图权限的信息别忘了在本站进行查找喔。