RE: How to keep format of views source code as entered?

2021-01-08 Thread Markhof, Ingolf
Thanks for your comments and thoughts. I am really surprised that PostgreSQL is unable to keep the source text of a view. Honestly, for me the looks like an implementation gap. Consider software development. You are writing code in C++ maybe on a UNIX host. And whenever you feed you source code

RE: How to keep format of views source code as entered?

2021-01-08 Thread Andreas Joseph Krogh
På fredag 08. januar 2021 kl. 09:38:29, skrev Markhof, Ingolf < ingolf.mark...@de.verizon.com >: Thanks for your comments and thoughts. I am really surprised that PostgreSQL is unable to keep the source text of a view. Honestly, for me the looks like

Re: How to keep format of views source code as entered?

2021-01-08 Thread Karsten Hilbert
Am Fri, Jan 08, 2021 at 08:38:29AM + schrieb Markhof, Ingolf: > I am really surprised that PostgreSQL is unable to keep the > source text of a view. Honestly, for me the looks like an > implementation gap. Consider software development. You are > writing code in C++ maybe on a UNIX host. And w

Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Thomas Kellerer
Hello, I wonder if it made sense to add a "TRUNCATE PARTITION" command to Postgres? Especially during bulk loads it's more efficient to TRUNCATE a partition if I know I want to replace all rows, rather than doing a DELETE. Currently this requires dynamic SQL which isn't always feasible (and mi

Re: How to keep format of views source code as entered?

2021-01-08 Thread Tim . Colles
On Fri, 8 Jan 2021, Karsten Hilbert wrote: Am Fri, Jan 08, 2021 at 08:38:29AM + schrieb Markhof, Ingolf: I am really surprised that PostgreSQL is unable to keep the source text of a view. Honestly, for me the looks like an implementation gap. Consider software development. You are writing

RE: Autovacuum not functioning for large tables but it is working for few other small tables.

2021-01-08 Thread M Tarkeshwar Rao
Hi all, As we know, the VACUUM VERBOSE output has a lot of dependencies from production end and is indefinite as of now. We don’t have any clue till now on why exactly the auto-vacuum is not working for the table. So we need to have a work around to move ahead for the time being. Can you plea

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread legrand legrand
Hello, maybe a naïve plpgsql as proposed in https://www.postgresql-archive.org/Partitionning-support-for-Truncate-Table-WHERE-td5933642.html may be an answer Regards PAscal -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Thomas Kellerer
legrand legrand schrieb am 08.01.2021 um 14:57:> maybe a naïve plpgsql as proposed in https://www.postgresql-archive.org/Partitionning-support-for-Truncate-Table-WHERE-td5933642.html may be an answer Yes I am aware of that (and that's what I have used so far) - I just thought it would make li

Missing declaration of _PG_init()

2021-01-08 Thread Jack Orenstein
I am writing an extension. The docs describe a _PG_init function that will be called upon loading the shared library (https://www.postgresql.org/docs/12/xfunc-c.html). I include postgres.h and fmgr.h, but on compilation, _PG_init has not been declared. Grepping the postgres source, _PG_init appears

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Michael Lewis
On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer wrote: > Hello, > > I wonder if it made sense to add a "TRUNCATE PARTITION" command to > Postgres? > > Especially during bulk loads it's more efficient to TRUNCATE a partition > if I know I want to replace all rows, rather than doing a DELETE. > > Cu

Re: Missing declaration of _PG_init()

2021-01-08 Thread Laurenz Albe
On Fri, 2021-01-08 at 09:49 -0500, Jack Orenstein wrote: > I am writing an extension. The docs describe a _PG_init function that will be > called upon > loading the shared library (https://www.postgresql.org/docs/12/xfunc-c.html). > I include > postgres.h and fmgr.h, but on compilation, _PG_init

Re: How to keep format of views source code as entered?

2021-01-08 Thread Tom Lane
"Markhof, Ingolf" writes: > I am really surprised that PostgreSQL is unable to keep the source text > of a view. Honestly, for me the looks like an implementation gap. Perhaps, but the "gap" is wider than you seem to think. Consider CREATE TABLE t1 (f1 int, f2 text); CREATE VIEW v1 AS SELECT f2

Re: Missing declaration of _PG_init()

2021-01-08 Thread Tom Lane
Jack Orenstein writes: > Should _PG_init(void) be declared in someplace included by postgres.h or > fmgr.h? No, because it's something a given module might or might not provide. Also, a global extern might give the impression that this was a global function that the core code provides, rather tha

Re: How to keep format of views source code as entered?

2021-01-08 Thread Adrian Klaver
On 1/8/21 12:38 AM, Markhof, Ingolf wrote: Thanks for your comments and thoughts. I am really surprised that PostgreSQL is unable to keep the source text of a view. Honestly, for me the looks like an implementation gap. Consider software development. You are writing code in C++ maybe on a UNI

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Thomas Kellerer
Michael Lewis schrieb am 08.01.2021 um 16:32: On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer mailto:sham...@gmx.net>> wrote: Hello, I wonder if it made sense to add a "TRUNCATE PARTITION" command to Postgres? Especially during bulk loads it's more efficient to TRUNCATE a partition

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Michael Lewis
On Fri, Jan 8, 2021 at 9:38 AM Thomas Kellerer wrote: > Michael Lewis schrieb am 08.01.2021 um 16:32: > > On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer sham...@gmx.net>> wrote: > > > > Hello, > > > > I wonder if it made sense to add a "TRUNCATE PARTITION" command to > Postgres? > > > >

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Thomas Kellerer
Michael Lewis schrieb am 08.01.2021 um 17:47: > For me, it seems too easily error prone such that a single typo in > the IN clause may result in an entire partition being removed that > wasn't supposed to be targeted. I don't see how this is more dangerous then:      del

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread legrand legrand
What is interesting here with the TRUNCATE WHERE (and in the proposed plpgsql) is to offer the end user a way to perform a transparent truncate or delete totally independent of the partitioning scheme (if any, or even if it has changed). -- Sent from: https://www.postgresql-archive.org/PostgreSQ

Re: Suggestion: provide a "TRUNCATE PARTITION" command

2021-01-08 Thread Michael Lewis
On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer wrote: > Michael Lewis schrieb am 08.01.2021 um 17:47: > > > For me, it seems too easily error prone such that a single typo in > > > the IN clause may result in an entire partition being removed that > > > wasn't supposed to be targe

Finding memory corruption in an extension

2021-01-08 Thread Jack Orenstein
An extension I'm creating is causing Postgres to crash, almost certainly due to memory corruption. I am using palloc0/pfree, calling SET_VARSIZE, and generally following the procedures documented here: https://www.postgresql.org/docs/12/xfunc-c.html. I am also testing my code outside of Postgres (

Re: Finding memory corruption in an extension

2021-01-08 Thread Pavel Stehule
Hi pá 8. 1. 2021 v 18:48 odesílatel Jack Orenstein napsal: > An extension I'm creating is causing Postgres to crash, almost certainly > due to memory corruption. I am using palloc0/pfree, calling SET_VARSIZE, > and generally following the procedures documented here: > https://www.postgresql.org

Re: Finding memory corruption in an extension

2021-01-08 Thread Tom Lane
Pavel Stehule writes: > pá 8. 1. 2021 v 18:48 odesílatel Jack Orenstein napsal: >> I'm interested in advice on how to go about hunting down my problem. >> Something along the lines of a debugging malloc, or valgrind, for Postgres. > The basic feature is using postgres compiled with --enable-cass

Re: How to keep format of views source code as entered?

2021-01-08 Thread raf
On Fri, Jan 08, 2021 at 08:38:29AM +, "Markhof, Ingolf" wrote: > Thanks for your comments and thoughts. > [...] > And you could not even store your source code on the UNIX > system. Instead, you'd be forced to do so in a separate system, like > GitHub. Stupid, isn't it? Right. > [...] > Reg

Re: Using more than one LDAP?

2021-01-08 Thread Stephen Frost
Greetings, * Paul Förster (paul.foers...@gmail.com) wrote: > Ok, since LDAP doesn't work that way, I either need to build GSSAPI packages > and have the AD admins to provide me with the keytab file or make the > transition a "hard" one, i.e. no transition phase. Though I'd rather have > liked t

Re: How to keep format of views source code as entered?

2021-01-08 Thread Tim Cross
Adrian Klaver writes: > On 1/8/21 12:38 AM, Markhof, Ingolf wrote: >> Thanks for your comments and thoughts. >> >> I am really surprised that PostgreSQL is unable to keep the source text >> of a view. Honestly, for me the looks like an implementation gap. >> Consider software development. You a

Re: Using more than one LDAP?

2021-01-08 Thread Paul Förster
Hi Stephen, > On 08. Jan, 2021, at 22:59, Stephen Frost wrote: > > Done correctly, the developers will hopefully be going from "this stupid > thing prompts me to provide a username/password in order to log in" to > "no more prompt for logging in, it just *works*". Further, as Magnus > explained