Erik Wienhold writes:
> Could it be a bug? Materialized views are a Postgres extension[1] (I always
> thought they are standard.) But I'd expect them to be included when talking
> about "views". Maybe they are not included because they are considered being
> closer to physical tables[2] than vi
> On 02/12/2022 23:22 CET Jonathan Lemig wrote:
>
> It probably wouldn't hurt to have that added to the documentation. I'll post
> a message to pgsql-docs. Thanks again!
>
> Jon
Good idea!
Could it be a bug? Materialized views are a Postgres extension[1] (I always
thought they are standard.) B
It probably wouldn't hurt to have that added to the documentation.
I'll post a message to pgsql-docs. Thanks again!
Jon
On Fri, Dec 2, 2022 at 4:14 PM Jonathan Lemig wrote:
> Hi Erik - sorry I missed your reply when I replied to David's. That is
> indeed the issue. The object that the view i
On Fri, Dec 02, 2022 at 11:02:18AM -0500, Tom Lane wrote:
> Also, we've *never* had storage of the original text for views.
> I'm a little mystified by people claiming they use original
> text for vetting functions when they clearly have no equivalent
> ability for views ... or are your applicati
Hi Erik - sorry I missed your reply when I replied to David's. That is
indeed the issue. The object that the view is querying is a materialized
view.
Thanks for the link.
Jon
On Fri, Dec 2, 2022 at 3:33 PM Erik Wienhold wrote:
> > On 02/12/2022 21:51 CET Jonathan Lemig wrote:
> >
> > Has an
> On 02/12/2022 22:55 CET Jonathan Lemig wrote:
>
> drps=> select viewowner, schemaname, viewname from pg_views where viewname =
> 'platform_version_v';
> viewowner | schemaname | viewname
> ---++
> drps | event | platform_version_v
> (1 row)
>
> drps=> s
> On 02/12/2022 22:33 CET Erik Wienhold wrote:
>
>
> > On 02/12/2022 21:51 CET Jonathan Lemig wrote:
> >
> > Has anybody ever encountered this, and if so, did you find a resolution?
> > Or perhaps there other limitations with the VTU that I'm unaware of?
>
> Is the one view you cannot find in
Hi David,
This is specifically what I'm seeing:
drps=> \c
psql (12.11, server 12.9)
You are now connected to database "drps" as user "drps".
drps=> show search_path;
search_path
"$user", public, event
(1 row)
drps=> select viewowner, schemaname, viewname from pg_
> On 02/12/2022 21:51 CET Jonathan Lemig wrote:
>
> Has anybody ever encountered this, and if so, did you find a resolution?
> Or perhaps there other limitations with the VTU that I'm unaware of?
Is the one view you cannot find in view_table_usage a materialized view?
Because those are not covere
> If you want an audit comparison point, I'd suggest capturing
> the result of pg_get_functiondef or one of its sibling functions
> just after creating your function. "pg_dump -s" is another
> pretty credible mechanism for capturing schema details.
That's very good info, thank you. I guess freaki
On Fri, Dec 2, 2022 at 1:52 PM Jonathan Lemig wrote:
> Has anybody ever encountered this, and if so, did you find a resolution?
> Or perhaps there other limitations with the VTU that I'm unaware of?
>
>
Well, the query itself is available in the source code if you want to
experiment on your own.
Hi,
I am running Postgres 12.9 on FreeBSD.
I had a developer ask me the best way to determine a view's dependencies
(i.e. which tables/views are used in a view's query). In Oracle, I would
use the ALL_DEPENDENCIES dictionary view. I found a view called
information_schema.view_table_usage (VTU)
> On Dec 2, 2022, at 08:02, Tom Lane wrote:
>
> Pasi Oja-Nisula writes:
>> I would be perfectly satisfied, if the sql that produced the procedure
>> would be stored "as is" read-only copy when it was compiled.
> If you want an audit comparison point, I'd suggest capturing
> the result of pg_
Pasi Oja-Nisula writes:
> I would be perfectly satisfied, if the sql that produced the procedure
> would be stored "as is" read-only copy when it was compiled.
As I mentioned upthread, we used to have that behavior (store both
compiled form and original text) for column default expressions and
CH
On 2022-12-02 14:02:37 +0100, Daniel Gustafsson wrote:
> > On 2 Dec 2022, at 14:00, Pasi Oja-Nisula wrote:
> >
> > On Fri, 2 Dec 2022 at 02:24, raf wrote:
> >> Same here. Accessing the loaded stored procedure source
> >> is how I audit the state of stored procedures in the
> >> database against
On Fri, 2 Dec 2022 at 15:47, raf wrote:
> If you're concerned about tampering by
> customers/users/developers, you can either set
> permissions to prevent it in some cases, and when you
> can't prevent it, make it tamper-evident by logging
> actions to somewhere remote and monitoring for what
> co
Is there a way to reverse engineer the original code (or its equivalent) from
what is saved in the database?
> On 12/02/2022 8:48 AM Dominique Devienne wrote:
>
>
> On Thu, Dec 1, 2022 at 8:51 PM Tom Lane wrote:
> > Do you really fail to see the contradictions in this? You want the
> > data
>
> From a user point of view, can also be seen as a "regression",
> when an observable property of the system changes to a new
> different / incompatible way, to some extent. I'm not saying it is,
> still it is a change one discovers too late, creates pain to some,
> and is both worth reporting an
On Thu, Dec 1, 2022 at 8:51 PM Tom Lane wrote:
> Do you really fail to see the contradictions in this? You want the
> database to preserve the original DDL, but you also want it to update
> in response to subsequent alterations. You can't have both those
Hi. I probably didn't express myself cor
On Fri, Dec 02, 2022 at 03:00:09PM +0200, Pasi Oja-Nisula wrote:
> On Fri, 2 Dec 2022 at 02:24, raf wrote:
> > Same here. Accessing the loaded stored procedure source
> > is how I audit the state of stored procedures in the
> > database against the code in the code repository.
>
> Exactly. If o
On Fri, Dec 2, 2022 at 1:37 PM Laurenz Albe wrote:
> Great; then go ahead and use those databases, if it is important for you.
Now come on. We all love PostgreSQL.
But that doesn't mean we can't disagree on some decisions.
Especially when you are a USER of PostgreSQL, not a DEV of it,
and it's t
On Fri, 2 Dec 2022 at 15:02, Daniel Gustafsson wrote:
> How do you today prove that for other compiled programs in your system?
Good question. I guess I never considered database to be compiled.
How do you debug this kind of system? What if the you suspect that there is
a wrong version of proced
> On 2 Dec 2022, at 14:00, Pasi Oja-Nisula wrote:
>
> On Fri, 2 Dec 2022 at 02:24, raf wrote:
>> Same here. Accessing the loaded stored procedure source
>> is how I audit the state of stored procedures in the
>> database against the code in the code repository.
>
> Exactly. If our software is a
On Fri, 2 Dec 2022 at 02:24, raf wrote:
> Same here. Accessing the loaded stored procedure source
> is how I audit the state of stored procedures in the
> database against the code in the code repository.
Exactly. If our software is audited, how can I reliably prove to auditor
that the running ve
On Fri, 2022-12-02 at 08:49 +0100, Martijn Tonies (Upscene Productions) wrote:
> So do InterBase, Firebird, SQL Server, MySQL (except for Views, strangely
> enough),
> MariaDB, NexusDB, SQL Anywhere, and, frankly, all others I know of.
>
> And this is used all the time by database developers.
>
jack...@gmail.com
--
Hello, I'm trying to modify pg codes for my personal project. And after I
finish modify planner, I get this.
postgres=# create table tt(a int);
CREATE TABLE
postgres=# \d tt
ERROR: btree index keys must be ordered by attribute
the patches are below
0001-finis
On Thu, Dec 1, 2022 at 7:59 PM Tom Lane wrote:
> Amitabh Kant writes:
> > I tried the following query :
>
> > SELECT tstzmultirange(tstzrange('2022-11-25 00:00:00', '2022-11-30
> > 00:00:00', '[]')) -
> > range_agg(time_range) AS availability
> > FROM test_time_range
> > WHERE time_range && ts
27 matches
Mail list logo
