Horton

Re: [HACKERS] proposal: schema variables

Pavel Luzanov <p.luzanov@postgrespro.ru>

View thread
From: Pavel Luzanov <p.luzanov@postgrespro.ru>
To: pgsql-hackers@lists.postgresql.org
Date: 2018-08-23T12:39:07Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

On 23.08.2018 12:46, Fabien COELHO wrote:
> I do not understand your point, as usual. I raise a factual issue 
> about security, and you do not answer how this can be solved with your 
> proposal, but appeal to argument of authority and declare your "strong 
> opinion".
>
> I do not see any intrinsic opposition between having session objects 
> and transactions. Nothing prevents a session object to be 
> transactional beyond your willingness that it should not be.
>
> Now, I do expect all PostgreSQL features to be security-wise, whatever 
> their scope.
>
> I do not think that security should be traded for "cheap & fast", esp 
> as the sole use case for a feature is a security pattern that cannot 
> be implemented securely with it. This appears to me as a huge 
> contradiction, hence my opposition against this feature as proposed.

I can't to agree with your position.

Consider this example.
I want to record some inappropriate user actions to audit table and 
rollback transaction.
But aborting transaction will also abort record to audit table.
So, do not use tables, becouse they have security implications.

This is very similar to your approach.

Schema variables is a very needed and important feature, but for others 
purposes.

-----
Pavel Luzanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company