Hi, Clemens, et al,
On Tue, Dec 25, 2018 at 12:23 AM Clemens Ladisch wrote:
>
> Igor Korot wrote:
> >Is there a way to write [LISTEN/NOTIFY] with the ODBC interface?
>
> At the moment, no.
>
> ODBC is a standard interface, so there are no functions for this defined.
>
> It might be possible to ad
Igor Korot wrote:
>Is there a way to write [LISTEN/NOTIFY] with the ODBC interface?
At the moment, no.
ODBC is a standard interface, so there are no functions for this defined.
It might be possible to add PG-specific extensions to the ODBC driver,
but this has not (yet) be done.
Regards,
Cleme
Hi,
On Mon, Dec 24, 2018 at 5:25 AM Danny Severns wrote:
>
> Is your question "can it be done" or "is someone willing to do it" or both?
Pretty much both.
Looking at the sample on the page it retrieves the connection socket.
And I know that there is no ODBC function that can retrieve this.
So
Hello All
We got to the bottom of this in the end - it was due to a misconfiguration that
resulted in random corruption of WAL archives.
Part of the problem was the use of 'pigz' (multi-threaded gzip tool) for
compression of the WAL files, which in our case led to a file that decompresses
with
Hi!
On Mon, Dec 24, 2018 at 1:31 AM George Neuner wrote:
> Did you execute the view or simply define it? I think the table is
> created the 1st time the view is executed.
View is populated with data and I can select from it. Still, I cannot
find any table which would look like it in pg_tables?
On Mon, 24 Dec 2018 01:16:53 -0800, Mitar wrote:
>
>I am unable to find cache table's name. :-(
>
Did you execute the view or simply define it? I think the table is
created the 1st time the view is executed.
George
Hi!
I am unable to find cache table's name. :-(
Mitar
On Mon, Dec 24, 2018 at 1:01 AM Mitar wrote:
>
> Hi!
>
> On Sun, Dec 23, 2018 at 11:59 PM George Neuner wrote:
> > IIRC the cache table's name is generated. I don't know the proper
> > incantations to get it from the catalogs, but an easy
Hi!
On Sun, Dec 23, 2018 at 11:59 PM George Neuner wrote:
> IIRC the cache table's name is generated. I don't know the proper
> incantations to get it from the catalogs, but an easy way to find it
> is to put the materialized view into its own tablespace, then search
> pg_tables for objects in t
Hi!
On Mon, Dec 24, 2018 at 12:20 AM George Neuner wrote:
> Also remember that you may have to deal with DELETEd rows. If you
> can't send row data by NOTIFY, then the client HAS to cache the whole
> view anyway to see what's been deleted.
Client-side (web browser) is caching the view (because i
Hi!
On Mon, Dec 24, 2018 at 12:31 AM George Neuner wrote:
> You're still thinking in terms of deltas for the whole table. Think
> individual rows instead.
>
> With a BY ROW trigger, the difference between the NEW and OLD
> variables lets you see the changes to the particular row.
I was thinking
On Sun, 23 Dec 2018 20:21:22 -0800, Mitar wrote:
>Currently I am doing:
>
>CREATE TRIGGER some_trigger AFTER UPDATE ON my_table REFERENCING NEW
>TABLE AS new_table OLD TABLE AS old_table FOR EACH STATEMENT EXECUTE
>FUNCTION my_trigger();
>
>In my trigger I do:
>
>PERFORM * FROM ((TABLE new_table
On Sun, 23 Dec 2018 10:10:50 -0800, Mitar wrote:
>I can then wire triggers on underlying tables to REFRESH materialized
>views automatically. Is there some easy way to debounce those
>refreshes? If I just blindly trigger REFRESH in every row trigger,
>this could do a lot of work. I would prefer t
12 matches
Mail list logo
