Re: Design of pg_stat_subscription_workers vs pgstats

On Sat, Feb 19, 2022 at 9:02 AM Andres Freund wrote: > > Even leaving everything else aside, a key of (dboid, subid, subrelid), > where > subrelid can be NULL, but where (dboid, subid) is *not* unique, imo is poor > relational design. What is the justification for mixing relation specific > and

Re: Design of pg_stat_subscription_workers vs pgstats

On Saturday, February 19, 2022, Amit Kapila wrote: > On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston > wrote: > > > > On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada > wrote: > >> > >> > >> Here is the summary of the discussion, changes, an

Re: Design of pg_stat_subscription_workers vs pgstats

On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada wrote: > > Here is the summary of the discussion, changes, and plan. > > 1. Move some error information such as the error message to a new > system catalog, pg_subscription_error. The pg_subscription_error table > would have the following columns: >

Re: Storage for multiple variable-length attributes in a single row

On Mon, Feb 7, 2022 at 9:58 AM Esteban Zimanyi wrote: > > As suggested by David, this goes beyond the "traditional" usage of > PostgreSQL. Therefore my questions are > * What is the suggested strategy to splitting these 2K attributes into > vertically partitioned tables where the tables are linke

Re: Storage for multiple variable-length attributes in a single row

On Mon, Feb 7, 2022 at 8:44 AM Esteban Zimanyi wrote: > May I kindly ask your insight about a question I posted 1 month ago and > for which I never received any answer ? > -hackers really isn't the correct place for usage questions like this - even if you are creating a custom type (why you are

Re: Design of pg_stat_subscription_workers vs pgstats

On Wednesday, February 2, 2022, Masahiko Sawada wrote: > and have other error > information in pg_stat_subscription_workers view. > What benefit is there to keeping the existing collector-based pg_stat_subscripiton_workers view? If we re-write it using shmem IPC then we might as well put everyt

Re: Unclear problem reports

On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian wrote: > I consider these as problems that need digging to find the cause, and > users are usually unable to do sufficient digging, and we don't have > time to give them instructions, so they never get a reply. > > Is there something we can do to impro

Re: warn if GUC set to an invalid shared library

On Tue, Feb 1, 2022 at 11:06 PM Maciek Sakrejda wrote: > I tried running ALTER SYSTEM and got the warnings as expected: > > postgres=# alter system set shared_preload_libraries = > no_such_library,not_this_one_either; > WARNING: could not access file "$libdir/plugins/no_such_library" > WARNING:

Re: Design of pg_stat_subscription_workers vs pgstats

On Wed, Feb 2, 2022 at 5:08 AM Amit Kapila wrote: > On Wed, Feb 2, 2022 at 1:06 PM David G. Johnston > wrote: > > ... > > > > I already explained that the concept of err_cnt is not useful. The fact > that you include it here makes me think you are still thinking

Re: Design of pg_stat_subscription_workers vs pgstats

On Tue, Feb 1, 2022 at 11:55 PM Amit Kapila wrote: > On Wed, Feb 2, 2022 at 9:41 AM David G. Johnston > wrote: > > > > On Tue, Feb 1, 2022 at 8:07 PM Amit Kapila > wrote: > >> > >> On Tue, Feb 1, 2022 at 11:47 AM Masahiko Sawada > wrote: > >

Re: Design of pg_stat_subscription_workers vs pgstats

On Tue, Feb 1, 2022 at 8:07 PM Amit Kapila wrote: > On Tue, Feb 1, 2022 at 11:47 AM Masahiko Sawada > wrote: > > > > > I see that it's better to use a better IPC for ALTER SUBSCRIPTION SKIP > > feature to pass error-XID or error-LSN information to the worker > > whereas I'm also not sure of the

Re: substring odd behavior

On Thu, Jan 27, 2022 at 7:22 PM Regina Obe wrote: > Is this intentional behavior? > > -- I can do this > SELECT substring('3.2.0' from '[0-9]*\.([0-9]*)\.'); > > -- But can't do this gives error syntax error at or near "from" > SELECT pg_catalog.substring('3.2.0' from '[0-9]*\.([0-9]*)\.'); > > s

Re: Design of pg_stat_subscription_workers vs pgstats

On Thu, Jan 27, 2022 at 2:15 PM Andres Freund wrote: > Another related thing is that using a 32bit xid for allowing skipping is a > bad > idea anyway - we shouldn't adding new interfaces with xid wraparound > dangers - > it's getting more and more common to have multiple wraparounds a day. An >

Re: Design of pg_stat_subscription_workers vs pgstats

On Thu, Jan 27, 2022 at 5:08 AM Amit Kapila wrote: > On Thu, Jan 27, 2022 at 11:16 AM Andres Freund wrote: > > > > On 2022-01-25 20:27:07 +0900, Masahiko Sawada wrote: > > > > > There will be some challenges in a case where updating > pg_subscription_rel > > > also failed too (what to report to

Re: Output clause for Upsert aka INSERT...ON CONFLICT

On Thursday, January 27, 2022, Anand Sowmithiran wrote: > > However, the MS SQL server MERGE command also does 'delete' using the > 'when not matched' clause, is there an equivalent ? > PostgreSQL does not have a merge command feature. Just the subset of behavior that is INSERT…on conflict Davi

Re: Output clause for Upsert aka INSERT...ON CONFLICT

On Wednesday, January 26, 2022, Anand Sowmithiran wrote: > The INSERT...ON CONFLICT is used for doing upserts in one of our app. > Our app works with both MS SQL and Postgresql, based on customer needs. > > Unlike the MS SQL MERGE command's OUTPUT clause that gives the $action >

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 25, 2022 at 9:16 PM Amit Kapila wrote: > On Wed, Jan 26, 2022 at 9:36 AM Masahiko Sawada > wrote: > > On Wed, Jan 26, 2022 at 12:54 PM Amit Kapila > wrote: > > > > > > > > > Probably, we also need to consider the case where the tablesync > worker > > > > entered an error loop and th

Re: Skipping logical replication transactions on subscriber side

On Mon, Jan 24, 2022 at 12:59 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > > > 5(out). wait for the user to manually restart the replication stream >> >> Do you mean that there always is user intervention after error so the >> replication str

Re: JSONB docs patch

On Tue, Jan 25, 2022 at 3:38 PM Mikhail Dobrinin wrote: > Hello, > > I have come across some missing documentation that I think could benefit > the community. > > Several functions like `jsonb_exists`, `jsonb_exists_any`, > `jsonb_exists_all` have existed for many PG versions but were not > docum

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 25, 2022 at 8:33 AM Masahiko Sawada wrote: > Given that we cannot use rely on the pg_stat_subscription_workers view > for this purpose, we would need either a new sub-system that tracks > each logical replication status so the system can set the error XID to > subskipxid, or to wait f

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 25, 2022 at 8:09 AM Masahiko Sawada wrote: > On Tue, Jan 25, 2022 at 11:58 PM David G. Johnston > wrote: > > > > On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada > wrote: > >> > >> Yeah, I think it's a good idea to clear the subskipxid af

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 25, 2022 at 7:47 AM Masahiko Sawada wrote: > Yeah, I think it's a good idea to clear the subskipxid after the first > transaction regardless of whether the worker skipped it. > > So basically instead of stopping the worker with an error you suggest having the worker continue applying

Re: Skipping logical replication transactions on subscriber side

On Tue, Jan 25, 2022 at 5:52 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 25.01.22 06:18, Amit Kapila wrote: > > I think to avoid this we can send a message to clear this (at least to > > clear XID in the view) after skipping the xact but there is no > > guarantee that it w

Re: Skipping logical replication transactions on subscriber side

On Monday, January 24, 2022, Amit Kapila wrote: > On Mon, Jan 24, 2022 at 1:30 PM David G. Johnston > wrote: > > > > That said, at present my two dislikes: > > > > 1) ALTER SYSTEM SKIP accepts any xid value (I need to consider further > the timing of when thi

Re: Skipping logical replication transactions on subscriber side

On Sun, Jan 23, 2022 at 11:55 PM Masahiko Sawada wrote: > On Mon, Jan 24, 2022 at 1:49 PM David G. Johnston > wrote: > > > > On Sun, Jan 23, 2022 at 8:35 PM Amit Kapila > wrote: > >> > >> > I really dislike the user experience this provides, and gi

Re: Skipping logical replication transactions on subscriber side

On Sun, Jan 23, 2022 at 8:35 PM Amit Kapila wrote: > > I really dislike the user experience this provides, and given it is new > in v15 (and right now this table seems to exist solely to support this > feature) changing this seems within the realm of possibility. I have to > imagine these workers

Re: Bogus duplicate command issued in pg_dump

On Sun, Jan 23, 2022 at 7:25 PM Michael Paquier wrote: > On Sun, Jan 23, 2022 at 01:31:03PM -0500, Tom Lane wrote: > > We could consider a more global change to get rid of using > > appendPQExpBuffer where it's not absolutely necessary, so that > > there are fewer bad examples to copy. Another i

Re: Bogus duplicate command issued in pg_dump

On Sun, Jan 23, 2022 at 11:31 AM Tom Lane wrote: > > res = ExecuteSqlQueryForSingleRow(fout, upgrade_query->data); > ... > appendPQExpBuffer(upgrade_query, > "SELECT t.oid, t.typarray " > ... > res = ExecuteSqlQueryForSingleRow(fou

Re: Skipping logical replication transactions on subscriber side

On Sat, Jan 22, 2022 at 9:21 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Sat, Jan 22, 2022 at 2:41 AM Amit Kapila > wrote: > >> >> > Additionally, the description for pg_stat_subscription_workers should >> describe what happens

Re: Skipping logical replication transactions on subscriber side

On Sat, Jan 22, 2022 at 2:41 AM Amit Kapila wrote: > On Sat, Jan 22, 2022 at 12:41 PM David G. Johnston > wrote: > > > > On Fri, Jan 21, 2022 at 10:30 PM Amit Kapila > wrote: > >> > >> On Fri, Jan 21, 2022 at 10:00 PM David G. Johnston > >> wrot

Re: Document atthasmissing default optimization avoids verification table scan

On Saturday, January 22, 2022, James Coleman wrote: > On Sat, Jan 22, 2022 at 12:35 AM David G. Johnston > wrote: > > > > On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote: > >> > >> > >> > Really? That's horrid, because that's direc

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 10:30 PM Amit Kapila wrote: > On Fri, Jan 21, 2022 at 10:00 PM David G. Johnston > wrote: > > > > On Fri, Jan 21, 2022 at 4:55 AM Amit Kapila > wrote: > >> > >> Apart from this, I have changed a few comments and ran pgindent. Do

Re: Document atthasmissing default optimization avoids verification table scan

On Fri, Jan 21, 2022 at 5:14 PM James Coleman wrote: > > > Really? That's horrid, because that's directly useful advice. > > Remedied, but rewritten a bit to better fit with the new style/goal of > that tip). > > Version 3 is attached. > > Coming back to this after a respite I think the tip need

Re: Proposal: allow database-specific role memberships

On Fri, Jan 21, 2022 at 3:12 PM Kenaniah Cerny wrote: > The latest rebased version of the patch is attached. > As I was just reminded, we tend to avoid specifying specific PostgreSQL versions in our documentation. We just say what the current version does. Here, the note sentences at lines 62 a

Re: Document atthasmissing default optimization avoids verification table scan

On Fri, Jan 21, 2022 at 2:50 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan > wrote: > >> I know what it's replacing refers to release 11, but let's stop doing > >> that. How about some

Re: Document atthasmissing default optimization avoids verification table scan

On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan wrote: > On 1/21/22 13:55, James Coleman wrote: > > + Before PostgreSQL 11, adding a new > column to a > + table required rewriting that table, making it a very slow operation. > + More recent versions can sometimes optimize away this rew

Re: Document atthasmissing default optimization avoids verification table scan

On Fri, Jan 21, 2022 at 11:55 AM James Coleman wrote: > On Thu, Jan 20, 2022 at 3:43 PM James Coleman wrote: > > > > As noted earlier I expect to be posting an updated patch soon. > > Here's the updated series. In 0001 I've moved the documentation tweak > into the ALTER TABLE notes section. In 0

Re: Skipping logical replication transactions on subscriber side

On Fri, Jan 21, 2022 at 4:55 AM Amit Kapila wrote: > Apart from this, I have changed a few comments and ran pgindent. Do > let me know what you think of the changes? > The paragraph describing ALTER SUBSCRIPTION SKIP seems unnecessarily repetitive. Consider: """ Skips applying all changes of th

Re: Document atthasmissing default optimization avoids verification table scan

On Wed, Jan 19, 2022 at 6:14 PM James Coleman wrote: > I'm open to the idea of wordsmithing here, of course, but I strongly > disagree that this is irrelevant data. Ok, but wording aside, only changing a tip in the DDL - Add Table section doesn't seem like a complete fix. The notes in alter ta

Re: Document atthasmissing default optimization avoids verification table scan

On Wed, Jan 19, 2022 at 5:08 PM Bossart, Nathan wrote: > On 9/24/21, 7:30 AM, "James Coleman" wrote: > > When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant > > default value without rewriting the table the doc changes did not note > > how the new feature interplayed with AD

Re: Refactoring of compression options in pg_basebackup

On Mon, Jan 17, 2022 at 8:41 AM Alvaro Herrera wrote: > On 2022-Jan-17, Robert Haas wrote: > > > Of the two > > alternatives that you propose, I prefer --compress=["server-"]METHOD > > and --compression-level=NUMBER to having both > > --client-compression-level and --server-compression-level. To

Re: Refactoring of compression options in pg_basebackup

On Mon, Jan 17, 2022 at 8:17 AM Robert Haas wrote: > On Mon, Jan 17, 2022 at 9:27 AM Magnus Hagander > wrote: > > I mean that I think it would be confusing to have > > --client-compression=x, --server-compression=y, and > > compression-level=z as the options. Why, in that scenario, does the > >

Re: Undocumented error

On Friday, January 14, 2022, Tomas Vondra wrote: > , > > On 1/14/22 00:02, Petar Dambovaliev wrote: > >> >> the error code is `-1` and the error text is `invalid ordering of >> speculative insertion changes` >> > > Which Postgres version is this, exactly? Was the WAL generated by that > same vers

Re: Foreign key joins revisited

On Saturday, December 25, 2021, Joel Jacobson wrote: > > I've revisited the idea to somehow use foreign keys to do joins, > > -1 > This is somewhat addressed by the USING join form, but USING has other > drawbacks, why I tend to avoid it except for one-off queries. > I find this sufficient.

Re: Is my home $HOME or is it getpwent()->pw_dir ?

On Sat, Dec 18, 2021 at 2:07 PM Chapman Flack wrote: > On 12/18/21 15:57, Chapman Flack wrote: > > I see that I can set > > a HISTFILE variable (or set PSQL_HISTORY in the environment), > > and can set PSQLRC in the environment (but not as a variable), > > and nothing can set the .pgpass location

Re: Allow DELETE to use ORDER BY and LIMIT/OFFSET

On Thursday, December 16, 2021, Yugo NAGATA wrote: > > Also, here seem to be some use cases. For example, > - when you want to delete the specified number of rows from a table > that doesn't have a primary key and contains tuple duplicated. Not our problem…use the tools correctly; there is al

Re: Privilege required for IF EXISTS event if the object already exists

On Thu, Dec 16, 2021 at 3:38 AM Shay Rojansky wrote: > >> Now, before creating tables, the ORM generates CREATE SCHEMA IF NOT > EXISTS, to ensure that the schema exists before CREATE TABLE; that's > reasonable general-purpose behavior. > > > > If the user hasn’t specified they want the schema cre

Re: Privilege required for IF EXISTS event if the object already exists

On Wednesday, December 15, 2021, Shay Rojansky wrote: > > . Now, before creating tables, the ORM generates CREATE SCHEMA IF NOT > EXISTS, to ensure that the schema exists before CREATE TABLE; that's > reasonable general-purpose behavior. > If the user hasn’t specified they want the schema created

Re: Privilege required for IF EXISTS event if the object already exists

On Wed, Dec 15, 2021 at 5:35 AM Shay Rojansky wrote: > Hi all, > > I've received numerous complaints about CREATE SCHEMA IF NOT EXISTS > failing when the user lacks CREATE privileges on the database - even if the > schema already exists. A typical scenario would be a multi-tenant > schema-per-ten

Re: Fix typos - "an" instead of "a"

On Wed, Dec 8, 2021 at 5:32 PM Greg Nancarrow wrote: > On Thu, Dec 9, 2021 at 11:25 AM David G. Johnston > wrote: > > > >> - # safe: cross compilers may not add the suffix if given an `-o' > >> + # safe: cross compilers may not add the suffix if given a

Re: Fix typos - "an" instead of "a"

On Wed, Dec 8, 2021 at 5:12 PM Michael Paquier wrote: > On Thu, Dec 09, 2021 at 07:30:48AM +1100, Peter Smith wrote: > > - # safe: cross compilers may not add the suffix if given an `-o' > + # safe: cross compilers may not add the suffix if given a `-o' > # argument, so we may need to kno

Re: Cross DB query

On Wednesday, December 8, 2021, Marcos Pegoraro wrote: > A question I always have, and I didn´t find anybody answering it. If it´s > possible > select * from MyDB.MySchema.MyTable; > No, if you specify MyDB is must match the database you’ve chosen to log into. > Everything I found was how to c

Re: Question on not-in and array-eq

On Wed, Dec 8, 2021 at 8:15 AM Zhenghua Lyu wrote: > I run the SQL without array expr in other DBs(orcale, sqlite, ...), they > all behave > the same as Postgres. > > It seems a bit confusing for me that 'not in' and 'in' the same subquery > both return 0 > rows, but the table contains data. > B

Re: Sequence's value can be rollback after a crashed recovery.

On Sunday, November 21, 2021, Andy Fan wrote: > > Should we guarantee the sequence's nextval should never be rolled back > even in a crashed recovery case? > I can produce the rollback in the following case: > This seems to be the same observation that was made a little over a year ago. https://

Re: update with no changes

On Fri, Nov 19, 2021 at 10:20 AM Andres Freund wrote: > You can't just skip doing updates without causing problems. > > Given you can do exactly this by using a trigger this statement is either false or I'm missing some piece of knowledge it relies upon. David J.

Re: update with no changes

On Fri, Nov 19, 2021 at 10:57 AM Marcos Pegoraro wrote: > So, Postgres guys will have to review all code being done on apps ? >> > > I suppose if the application side cannot be trusted to code to a specification without having the server side add validation and/or compensation code to catch the b

Re: update with no changes

On Fri, Nov 19, 2021 at 10:03 AM Marcos Pegoraro wrote: > Because it takes resources to determine that nothing changed. If you want >> to opt-in into that there is even an extension trigger that makes doing so >> fairly simple. But it's off by default because the typical case is that >> people

Re: update with no changes

On Fri, Nov 19, 2021 at 9:38 AM Marcos Pegoraro wrote: > If nothing was changed, why create a new record, append data to wal, set > old record as deleted, etc, etc ? > Because it takes resources to determine that nothing changed. If you want to opt-in into that there is even an extension trigge

Add psql command to list constraints

On Monday, November 15, 2021, Tatsuro Yamada wrote: > > > I don't know if this is a good example, but if you look at StackOverflow, > it seems that people who want to see a list of constraints appear > regularly. https://stackoverflow.com/questions/62987794/how-to-list-all > -constraints-of-a-ta

Re: Add psql command to list constraints

On Monday, November 15, 2021, David G. Johnston wrote: > > If the only motivation for this is "feature completion" - since we have so > many other \d commands already implemented - I say we should pass. > If anything, doing this for triggers would be a much better featu

Re: Add psql command to list constraints

On Mon, Nov 15, 2021 at 5:23 PM Tatsuro Yamada < tatsuro.yamada...@nttcom.co.jp> wrote: > > > I'm not confident that if I would use this, so let's wait to see if > someone > > else wants to give a +1. > > Okay, but you agree that there are DBAs and users who want to see the > list of constraints,

Re: Question about psql meta-command with schema option doesn't use visibilityrule

On Sunday, November 7, 2021, Tatsuro Yamada wrote: > > I have a question that is a specification of permission check > (visibilityrule) for psql meta-command with schema option. > > From the above results, I expected "\dX s_a.*" doesn't show any info > as same as "\dX". but info is displayed. I'm

Re: Question about psql meta-command with schema option doesn't use visibilityrule

On Sunday, November 7, 2021, Tatsuro Yamada wrote: > > According to the source code [1], there is no check if a schema > option is added. As a result, a role that is not granted can see > other roles' object names. > We might say it's okay because it's a name, not contents (data), > but It seems

Re: to be a multirange or not be, that's the question

On Saturday, November 6, 2021, Jaime Casanova wrote: > Ok, subject was a bit philosophical but this message I just found is > quite confusing. > > """ > regression=# select cast(null as anyrange) &> cast(null as anymultirange); > ERROR: argument declared anymultirange is not a multirange type bu

Re: [PATCH] rename column if exists

On Fri, Nov 5, 2021 at 8:37 AM Robert Haas wrote: > > Making renaming work in the same kind of context is harder. You're > definitely going to have to upgrade the application and the schema in > lock step, unless the application is smart enough to work with the > column having either name. You'r

Re: [PATCH] rename column if exists

On Fri, Nov 5, 2021 at 8:08 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Friday, November 5, 2021, Tom Lane wrote: > >> I'd be more willing to overlook that if a clear use-case had been > >> given, but AFAICS no concrete case has been off

Re: [PATCH] rename column if exists

On Friday, November 5, 2021, Tom Lane wrote: > > I'd be more willing to overlook that if a clear use-case had been > given, but AFAICS no concrete case has been offered. > > The use case is the exact same one for all of these - indempotence, especially in the face of being able to run migration sc

Re: [PATCH] rename column if exists

On Friday, November 5, 2021, Daniel Gustafsson wrote: > > I know that, I'm just not convinced that it's a feature (in the case at > hand) > I don’t see how this one should be expected to meet a higher bar than drop table or other existing commands. I get why in the nearby discussion create role

Re: [PATCH] rename column if exists

On Thursday, November 4, 2021, Daniel Gustafsson wrote: > > On 22 Mar 2021, at 20:40, David Oksman wrote: > > > > Added the ability to specify IF EXISTS when renaming a column of an > object (table, view, etc.). > > For example: ALTER TABLE distributors RENAME COLUMN IF EXISTS address TO > city;

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On Tue, Nov 2, 2021 at 3:14 PM Vik Fearing wrote: > On 11/2/21 4:06 PM, Robert Haas wrote: > > There's bound to be somebody who wants to grant some of > > these permissions and not others, or who wants to grant the ability to > > run those commands on some tables but not others. > Is there anythi

Re: Vulnerability identified with Postgres 13.4 for Windows

On Friday, October 29, 2021, Joel Mariadasan (jomariad) wrote: > Detected by Automated Scanning tool: > > *libxml 2.9.10* > > > > Can you confirm if this is the same version of libxml used in Postgres? > > We want to confirm if the detection is a false positive or a vulnerability. > > > IIUC (t

Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.

On Sun, Oct 24, 2021 at 7:49 AM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Sun, Oct 24, 2021 at 3:15 AM Jeff Davis wrote: > > > > Add new predefined role pg_maintenance, which can issue VACUUM, > > ANALYZE, CHECKPOINT. > > > Are there any other database activities tha

Re: pg_dump versus ancient server versions

On Fri, Oct 22, 2021 at 3:42 PM Tom Lane wrote: > Anyway, I think the default answer is "revert 92316a458 and keep the > compatibility goalposts where they are". But I wanted to open up a > discussion to see if anyone likes the other approach better. > > [1] > https://www.postgresql.org/message-

Re: [PATCH] Fix memory corruption in pg_shdepend.c

On Thu, Oct 21, 2021 at 8:52 AM Tom Lane wrote: > We're fortunate > that cloning a nonempty template database is rare already. > > That, and a major use case for doing so is to quickly stage up testing data in a new database (i.e., not a production use case). Though I could see tenant-based prod

Re: Some questions about schema privileges

On Wed, Oct 20, 2021 at 8:59 AM Anna Akenteva wrote: > Hi all, > > I have been wondering about some things related to schema privileges: > > 1) Why do visibility rules apply to the \d command, but not to system > tables? What is the purpose of hiding stuff from \d output while users > can get the

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thursday, October 14, 2021, Tom Lane wrote: > Gilles Darold writes: > > Le 14/10/2021 à 17:38, Jaime Casanova a écrit : > >> On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: > > > Why not, I will add it if there is a consencus about logging hidden > > column use, this is not a b

Re: Corruption with IMMUTABLE functions in index expression.

On Monday, October 11, 2021, Prabhat Sahu wrote: > > While using IMMUTABLE functions in index expression, we are getting below > corruption on HEAD. > That function is not actually immutable (the system doesn’t check whether your claim of immutability and the function definition match, its up to

Re: Proposal: allow database-specific role memberships

On Monday, October 11, 2021, Stephen Frost wrote: > > I don't think "just don't grant access to those other databases" > is actually a proper answer- there is certainly a use-case for "I want > user X to have read access to all tables in *this* database, and also > allow them to connect to some o

Re: Proposal: allow database-specific role memberships

On Sun, Oct 10, 2021 at 2:29 PM Kenaniah Cerny wrote: > In building off of prior art regarding the 'pg_read_all_data' and > 'pg_write_all_data' roles, I would like to propose an extension to roles > that would allow for database-specific role memberships (for the purpose of > granting database-sp

Re: pg_dump does not dump tables created in information_schema schema

On Thursday, October 7, 2021, vignesh C wrote: > > Should tables be allowed to create in "information_schema" schema, if > yes should the tables/publications be dumped while dumping database > contents? > > I presume you have to be superuser to do this. If so, this would seem to fit under the “w

Re: Improved PostgreSQL Mathematics Support.

On Sunday, September 19, 2021, A Z wrote: > > Is there someone on this email list which could please have a look > at the specifications that I have posted, and reply and get back to > me? > Given the number of posts you’ve made I would have to conclude that the answer to that question is no. T

Re: Access last_sqlstate from libpq

On Friday, September 17, 2021, Daniel Frey wrote: > > > Are you sure or are you guessing? > Guessing regarding the implementations of these interfaces. David J.

Re: Access last_sqlstate from libpq

On Friday, September 17, 2021, Daniel Frey wrote: > > > However, this is not possible in a couple of other cases where I don't > have a PGresult*, only the PGconn* is available: > > * PQconnectdb (and variants) > > * PQputCopyData > * PQputCopyEnd > * PQgetCopyData > > * lo_* (large object functio

Re: Confusing messages about index row size

On Sunday, September 12, 2021, Jaime Casanova wrote: > > > So, what is it? the index row size could be upto 8191 or cannot be > greater than 2704? > The wording doesn’t change between the two: The size cannot be greater the 8191 regardless of the index type being used. This check is first, proba

Re: [BUG?] SET TIME ZONE doesn't work with abbreviations

On Tuesday, September 7, 2021, Aleksander Alekseev wrote: > Hi hackers, > > I noticed that `SET TIME ZONE` / `SET timezone TO` don't work with > abbreviations: > > Is it a bug or this behavior is intentional (something to do with SQL > standard, perhaps)? > > Well, given that the limitation is do

Re: Correct handling of blank/commented lines in PSQL interactive-mode history

On Mon, Sep 6, 2021 at 7:13 AM Greg Nancarrow wrote: > I've attached a patch that corrects the behaviour. > For the type of lines mentioned, the patch makes the history behave > more like Bash history. > I have my doubts that you've really fixed anything here since Bash is a line-oriented shell

Re: Improving some plpgsql error messages

On Fri, Aug 20, 2021 at 8:50 AM Tom Lane wrote: > Thoughts? Should I back-patch this into v14 where 2f48ede08 > came in, or just do it in HEAD? > I'd say back-patch in the interest of preventing probably quite a few emails from novices at plpgsql coding dealing with all the interplay between qu

Re: [PATCH] Proof of concept for GUC improvements

On Thu, Aug 19, 2021 at 3:44 PM David Christensen < david.christen...@crunchydata.com> wrote: > Functionality-wise, any thoughts on the overall approach or the specific > patch? > If this information was exposed only by an addition to pg_settings, and thus not changeable via a GUC or affecting SH

Re: Allow composite foreign keys to reference a superset of unique constraint columns?

On Mon, Aug 16, 2021 at 4:37 PM Paul Martinez wrote: > > It seems like a somewhat useful feature. If people think it would be > useful to > implement, I might take a stab at it when I have time. > > This doesn't seem useful enough for us to be the only implementation to go above and beyond the SQ

Re: Default to TIMESTAMP WITH TIME ZONE?

On Friday, August 13, 2021, Tom Lane wrote: > > The one thing I could potentially see us doing is more strongly > encouraging the use of the names "timestamp" and "timestamptz", > up to and including changing what format_type() et al. put out. +1. Having the canonical form be timestamptz would

Re: Default to TIMESTAMP WITH TIME ZONE?

On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs wrote: > > The only hope is to eventually change the default, so probably > the best thing is to apply pressure via the SQL Std process. > > Then there is no hope because this makes the situation worse. If anything I'd suggest the SQL standard should p

Re: Default to TIMESTAMP WITH TIME ZONE?

On Fri, Aug 13, 2021 at 12:33 AM Gavin Flower wrote: > > I always use the tz version, except when I forget. I find it nearly impossible for me to forget how this works. But that is probably because I just pretend that the standard, multi-word, data types don't even exist. It's not that "times

Re: Insert Documentation - Returning Clause and Order

On Mon, Dec 14, 2020 at 7:09 AM Ashutosh Bapat wrote: > But we write what's guaranteed. Anything not written in > the documents is not guaranteed. > In the case of LIMIT we go to great lengths to write what isn't guaranteed. I suggest that this is similar enough in nature to warrant the same em

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

On Wed, Aug 11, 2021 at 5:54 AM Robert Haas wrote: > Yeah. I tend to feel like this is the kind of thing where it's not > likely to be 100% obvious to users how it all works no matter what we > put in the documentation, and that some of the behavior of a system > has to be learned just by trying

Re: use-regular-expressions-to-simplify-less_greater-and-not_equals.patch

On Tue, Aug 10, 2021 at 8:36 PM Tom Lane wrote: > "=?UTF-8?B?5a2Z6K+X5rWpKOaAneaJjSk=?=" > writes: > > we can use regular expressions (<>|!=) to cover "<>" and "!=". > There is no > > need to have two definitions less_greater and not_equals, because it > will confuse developer. > > So, we c

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

On Tue, Aug 10, 2021 at 12:04 PM Robert Haas wrote: > On Tue, Mar 9, 2021 at 10:09 AM David G. Johnston > wrote: > > Frankly, I am hoping for a bit more constructive feedback and even > collaboration from a committer, specifically Tom, on this one given the > outstandi

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

On Mon, Aug 9, 2021 at 1:38 PM Michael Meskes wrote: > > I don't want to upset anybody for any reason. I regret that my words > > have upset you, but I think that they were misinterpreted in a way > > that I couldn't possibly have predicted. The particular aspect of > > I strongly object to that.

Re: Commitfest overflow

On Thu, Aug 5, 2021 at 7:36 AM Robert Haas wrote: > Patches that are not being updated regularly have no > business being part of a CommitFest. > As the main issue seems to be "Needs Review" getting punted, the patch author rightly expects feedback before supplying new patches. If they are wait

Re: Commitfest overflow

On Tue, Aug 3, 2021 at 8:53 AM Simon Riggs wrote: > There are 273 patches in the queue for the Sept Commitfest already, so > it seems clear the queue is not being cleared down each CF as it was > before. We've been trying hard, but it's overflowing. > > Of those, about 50 items have been waiting

Re: Refactor ECPGconnect and allow IPv6 connection

On Mon, Jun 21, 2021 at 3:46 AM kuroda.hay...@fujitsu.com < kuroda.hay...@fujitsu.com> wrote: > I will try to remake patches based on the idea. > Based upon this comment, and the ongoing discussion about commitfest volume and complexity, I've moved this to "Waiting on Author". David J.

<    3   4   5   6   7   8   9   10   11   12   >