On Thu, Jan 25, 2024 at 9:42 AM torikoshia
wrote:
> Hi,
>
> As described in 9e2d870119, COPY ON_EEOR is expected to have more
> "error_action".
> (Note that option name was changed by b725b7eec)
>
> I'd like to have a new option "log", which skips soft errors and logs
> information that should ha
On Fri, Jan 26, 2024 at 2:49 AM torikoshia
wrote:
> Hi,
>
> 9e2d870 enabled the COPY command to skip soft error, and I think we can
> add another option which specifies the maximum tolerable number of soft
> errors.
>
> I remember this was discussed in [1], and feel it would be useful when
> load
Hi,
The option choice of "ignore" in the COPY ON_ERROR clause seems overly
generic. There would seem to be two relevant ways to ignore bad column
input data - drop the entire row or just set the column value to null. I
can see us wanting to provide the set to null option and in any case having
t
On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote:
> On Fri, 26 Jan 2024 00:00:57 -0700
> "David G. Johnston" wrote:
>
> > I will need to make this tweak and probably a couple others to my own
> > suggestions in 12 hours or so.
> >
>
>
And here i
On Thursday, January 25, 2024, Yugo NAGATA wrote:
>
> Maybe, we can separate the sentese to two, for example:
>
> COPY stops operation at the first error. (The exception is if the error
> is due to data type incompatibility and a value other than stop is
> specified
> to the ON_ERROR option
On Thu, Jan 25, 2024 at 10:40 PM Yugo NAGATA wrote:
> On Fri, 26 Jan 2024 13:59:09 +0900
> Masahiko Sawada wrote:
>
> > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA
> wrote:
> > >
> > > Hi,
> > >
> > > I found that the documentation of COPY ON_ERROR said
> > > COPY stops operation at the first
.org/message-id/d294818d12280f6223ddf169ab5454927f5186b6.camel%40cybertec.at
From a4d6a599a0b5d6b8f280e3d8489e7f4a4a555383 Mon Sep 17 00:00:00 2001
From: "David G. Johnston"
Date: Thu, 25 Jan 2024 13:41:48 -0700
Subject: [PATCH] v1-improvements-to-ddl-priv Section
---
doc/src
Came across this while looking for patches to review. IMO this thread has
been hijacked to the point of being not useful for the subject. I suggest
this discussion regarding prefetch move to its own thread and this thread
and commitfest entry be ended/returned with feedback.
Also IMO, the commit
On Tue, Jan 23, 2024 at 7:35 AM Stefan Keller wrote:
> Am Di., 23. Jan. 2024 um 15:15 Uhr schrieb Laurenz Albe
> :
> > I understand the motivation, but I bet it's not what will make users
> > happy.
> >
> > If you need to disambiguate between SQL NULL and JSON null, my
> > preferred solution woul
On Sun, Jan 21, 2024 at 2:35 PM Pavel Luzanov
wrote:
> List of roles
> Role name | Attributes | Password? | Valid until | Connection
> limit
> ---+-+---++--
> admin | INHERIT
On Mon, Jan 22, 2024 at 6:26 PM Tom Lane wrote:
> I wrote:
> > I think expecting the pg_roles view to change for this is problematic.
> > You can't have that in the back branches, so with this patch psql
> > will show something different against a pre-17 server than later
> > versions. At best,
On Sun, Jan 21, 2024 at 2:35 PM Pavel Luzanov
wrote:
> Another approach based on early suggestions.
>
> The Attributes column includes only the enabled logical attributes.
> Regardless of whether the attribute is enabled by default or not.
>
>
> The attribute names correspond to the keywords of
On Mon, Jan 22, 2024 at 8:06 AM Christoph Berg wrote:
> Assuming a SELECT statement reading from a single table, it is quite an
> effort to transform that statement to an UPDATE statement on that table,
> perhaps to fix a typo that the user has spotted in the query result.
>
>
Building off the ot
On Saturday, January 20, 2024, James Coleman wrote:
>
>
> Well, egg on my face for definitely missing that in the docs.
>
> Unfortunately that doesn't explain why it works on PG11 and not on PG12.
>
It was a bug that got fixed. I’m sure a search of the mailing list
archives or Git will turn up t
On Fri, Jan 19, 2024 at 10:01 AM James Coleman wrote:
> Making this more confusing is the fact that if I want to do something
> like "SET bar = foo.bar + 1" the table qualification cannot be present
> on the setting column but is required on the reading column.
>
> There isn't anything in the doc
On Thu, Jan 18, 2024 at 11:31 AM Andrey Borodin
wrote:
>
> Now I'm completely lost in time... I've set local time to NY (UTC-5).
>
> postgres=# select TIMESTAMP WITH TIME ZONE '2022-02-22 14:22:22-05' -
> TIMESTAMP WITH TIME ZONE 'Tuesday, February 22, 2022 2:22:22.00 PM
> GMT-05:00';
> ?column?
On Sun, Jan 14, 2024 at 6:59 PM Nathan Bossart
wrote:
> On Sun, Jan 14, 2024 at 04:17:41PM +0530, vignesh C wrote:
> > The attached v3 version patch has the changes for the same.
>
> LGTM. I'll wait a little while longer for additional feedback, but if none
> materializes, I'll commit this soon.
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> However, initially, I have one more obstacle in your feedback. If I use
> count(*) over() - row_number() over(), it gives me an offset of one unit.
> To resolve this, I need to add 1.
>
>
> This way, simulating a reverse row_number() becomes e
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
>
>
> However, initially, I have one more obstacle in your feedback. If I use
> count(*) over() - row_number() over(), it gives me an offset of one unit.
> To resolve this, I need to add 1.
>
> This way, simulating a reverse row_number() becomes
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> Hi,
>
> Count() over() - row_number() over()
>
>But if my dataset is significantly large? Wouldn't calling two window
> functions instead of one be much slower?
>Is *count() over() - row_number() over()* faster than *row_number_desc()
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> Hello David, how are you?
>
> Firstly, I apologize if I wasn't clear in what I intended to propose. I
> used a very specific example here, and it wasn't very clear what I really
> wanted to bring up for discussion.
>
> I understand that it's p
On Tuesday, January 16, 2024, Maiquel Grassi wrote:
> Hi developers,
>
> I was working on loans and bank financing, specifically focusing on
> Amortization Systems. I had the need to reverse the counter for the total
> number of installments or for a specific set of installments. This
> "reversal
On Tuesday, January 16, 2024, Bablu Kumar Nayak <
bablukumarnayak1...@gmail.com> wrote:
> Dear PostgreSQL Team,
>
>
>
> I am writing to inform you that our PostgreSQL database service is
> currently down. We are experiencing an unexpected interruption, and we are
> seeking your expertise to help u
On Saturday, January 13, 2024, Nathan Bossart
wrote:
> On Sat, Jan 13, 2024 at 01:39:50PM +0300, Aleksander Alekseev wrote:
>
> > Should we remove --config-file from the error message to avoid any
> > confusion? Should we correct --help output? Should we update the
> > documentation?
>
> It might
On Monday, January 8, 2024, Geoff Winkless wrote
>
>
> Mildly interesting: you can pass column positions to GROUP BY and
> ORDER BY but if you try to pass a position to GROUPING() (I wondered
> if that would help the engine somehow) it fails:
>
The symbol 1 is ambigious - it can be the number or
On Sunday, January 7, 2024, jian he wrote:
> hi.
> Maybe this is a small printout err_position bug.
>
> create table atacc2 ( test int, a int, b int) ;
> success tests:
> alter table atacc2 add CONSTRAINT x PRIMARY KEY (id, b );
> alter table atacc2 add CONSTRAINT x PRIMARY KEY (id, b a);
> alter
On Sat, Jan 6, 2024 at 8:38 AM Geoff Winkless wrote:
> On Fri, 5 Jan 2024 at 18:34, Zhang Mingli wrote:
> >
> > On Jan 6, 2024 at 01:38 +0800, Geoff Winkless ,
> wrote:
> >
> >
> > Am I missing some reason why the first set isn't sorted as I'd hoped?
> >
> >
> > Woo, it’s a complex order by, I t
On Fri, Dec 15, 2023 at 8:20 AM Josef Šimánek
wrote:
> (parser is not available
> in public APIs of postgres_fe.h or libpq).
>
What about building "libpg" that does expose and exports some public APIs
for the parser? We can include a reference CLI implementation for basic
usage of the functiona
On Fri, Dec 15, 2023 at 8:05 AM Josef Šimánek
wrote:
> pá 15. 12. 2023 v 15:50 odesílatel Tom Lane napsal:
> >
> > Laurenz Albe writes:
> > > On Fri, 2023-12-15 at 13:21 +0100, Josef Šimánek wrote:
> > >> Inspired by Simon Riggs' keynote talk at PGCounf.eu 2023 sharing list
> > >> of ideas for
On Thursday, December 7, 2023, Joe Conway wrote:
> On 12/7/23 08:35, Daniel Verite wrote:
>
>> Joe Conway wrote:
>>
>> The attached should fix the CopyOut response to say one column. I.e. it
>>> ought to look something like:
>>>
>>
>> Spending more time with the doc I came to the opinion
On Thursday, December 7, 2023, Daniel Verite
wrote:
> Joe Conway wrote:
>
> > The attached should fix the CopyOut response to say one column. I.e. it
> > ought to look something like:
>
> Spending more time with the doc I came to the opinion that in this bit
> of the protocol, in CopyOutR
On Wed, Dec 6, 2023 at 6:14 PM Joe Conway wrote:
>
> > But the point that we should introduce a 2 still stands. The new code
> > would mean: use text output functions but that there is no inherent
> > tabular structure in the underlying contents. Instead the copy format
> > was JSON and the out
On Wed, Dec 6, 2023 at 5:57 PM Joe Conway wrote:
> On 12/6/23 19:39, David G. Johnston wrote:
> > On Wed, Dec 6, 2023 at 4:45 PM Joe Conway > <mailto:m...@joeconway.com>> wrote:
>
> > But I still cannot shake the belief that using a format code of 1 -
> >
On Wed, Dec 6, 2023 at 4:45 PM Joe Conway wrote:
>
> " The backend sends a CopyOutResponse message to the frontend, followed
> by zero or more CopyData messages (always one per row), followed by
> CopyDone"
>
> probably "always one per row" would be changed to note that json array
> forma
On Wed, Dec 6, 2023 at 4:28 PM David G. Johnston
wrote:
> On Wed, Dec 6, 2023 at 4:09 PM Joe Conway wrote:
>
>> On 12/6/23 14:47, Joe Conway wrote:
>> > On 12/6/23 13:59, Daniel Verite wrote:
>> >> Andrew Dunstan wrote:
>> >>
>>
On Wed, Dec 6, 2023 at 4:09 PM Joe Conway wrote:
> On 12/6/23 14:47, Joe Conway wrote:
> > On 12/6/23 13:59, Daniel Verite wrote:
> >> Andrew Dunstan wrote:
> >>
> >>> IMNSHO, we should produce either a single JSON
> >>> document (the ARRAY case) or a series of JSON documents, one per row
>
On Wed, Dec 6, 2023 at 3:38 PM Joe Conway wrote:
> So the questions are:
> 1. Do those two formats work for the initial implementation?
>
Yes. We provide a stream-oriented format and one atomic-import format.
2. Is the default correct or should it be switched
> e.g. rather than specifying
This mailing list is for discussing the development of patches to the
PostgreSQL code base. Please send your request for help to a more
appropriate list - specifically the -general list.
David J.
On Thursday, November 30, 2023, Nurul Karim Rafi
wrote:
> I have a stored procedure in Postgres.
On Mon, Nov 27, 2023 at 2:10 PM Rushabh Shah wrote:
>
> I want to dynamically generate a nested json file. I have written a
> function for it in PL/PGSQL that accepts 3 arrays. First one is an array of
> all json fields, second one is an array of all json fields with columns
> from tables present
On Sun, Nov 26, 2023 at 7:47 AM Anton A. Melnikov
wrote:
>
> postgres=# ALTER DATABASE template1 SET TimeZone = 'UTC';
>
> Could you clarify please. Is this normal, predictable behavior?
>
>
https://www.postgresql.org/docs/current/sql-createdatabase.html
Database-level configuration parameters
On Mon, Nov 20, 2023 at 1:37 PM Andres Freund wrote:
>
> Given that, I wonder if what we should do is to just add a new field to
> pg_control that says "error out if backup_label does not exist", that we
> set
> when creating a streaming base backup
>
>
I thought this was DOA since we don't want
On Thursday, November 16, 2023, Tom Lane wrote:
>
> That line of argument also leads to the conclusion that it'd be
> okay to expose info about the ordering of the CTE result to the
> upper planner. This patch doesn't do that, and I'm not sufficiently
> excited about the issue to go write some c
On Mon, Nov 13, 2023 at 12:36 PM Laurenz Albe
wrote:
> On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote:
> > On 2023-11-09 20:19 +0100, Tom Lane wrote:
> > > Laurenz Albe writes:
> > > > Thanks for the feedback. I'll set the patch to "ready for
> committer" then.
> > >
> > > So, just to c
On Friday, November 3, 2023, Mark Hills wrote:
>
> pg_restore: error: could not execute query: ERROR: type "hash" does not
> exist
> LINE 7: )::hash;
> [...]
> CONTEXT: SQL function "gen_hash" during inlining
>
> --
> -- Relevant SQL declarations
> --
>
Those were not all of th
On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> wrote:
>
>> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
>> > This is by design: triggers operate at a lower level tha
On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
wrote:
> On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> > This is by design: triggers operate at a lower level than
> > foreign keys, so an ill-conceived trigger can break an FK constraint.
> > That's documented somewhere, though maybe not visibl
On Fri, Oct 27, 2023 at 7:10 AM David Steele wrote:
> On 10/26/23 17:27, David G. Johnston wrote:
>
> > Can we not figure out some way to place the relevant files onto the
> > server somewhere so that a simple "cp" command would work? Have
> > pg_backup_sto
On Thu, Oct 26, 2023 at 4:13 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Ah, I was confused. I documented both in the attached patch.
>>
>> The function one
On Thu, Oct 26, 2023 at 4:08 PM Tom Lane wrote:
> Bruce Momjian writes:
> > Ah, I was confused. I documented both in the attached patch.
>
> The function one should have the same annotation as some others:
>
> can be increased by recompiling
> PostgreSQL
>
>
I'd like to see a comment on th
On Thu, Oct 26, 2023 at 4:03 PM Bruce Momjian wrote:
>
> Sure, done in the attached patch.
>
>
WFM. Thank You!
David J.
On Thu, Oct 26, 2023 at 3:51 PM Bruce Momjian wrote:
> On Wed, Nov 23, 2022 at 02:33:27PM -0600, Justin Pryzby wrote:
> > On Wed, Nov 23, 2022 at 12:35:59PM -0700, David G. Johnston wrote:
> > > On Wed, Nov 23, 2022 at 11:47 AM Tom Lane wrote:
> > >
> > > >
On Thu, Oct 26, 2023 at 3:36 PM Bruce Momjian wrote:
> No sneaking. ;-) It would be bad to document this unevenly because it
> sets expectations in other parts of the system if we don't mention it.
>
Agreed.
Last suggestion, remove the first jsonb_agg example that lacks an order by.
+WITH va
On Thu, Oct 26, 2023 at 2:56 PM Bruce Momjian wrote:
> On Wed, Oct 25, 2023 at 10:34:10PM -0700, David G. Johnston wrote:
> > I would reword the existing note to be something like:
> >
> > The SQL Standard defines specific aggregates and their properties,
> including
>
On Thu, Oct 26, 2023 at 2:02 PM David Steele wrote:
> Hackers,
>
> This was originally proposed in [1] but that thread went through a
> number of different proposals so it seems better to start anew.
>
> The basic idea here is to simplify and harden recovery by getting rid of
> backup_label and s
On Wed, Oct 25, 2023 at 7:13 PM David Rowley wrote:
> On Thu, 26 Oct 2023 at 13:10, David G. Johnston
> wrote:
> > Question: Do you know whether we for certain always sort ascending here
> to compute the unique values or whether if, say, there is an index on the
> column in de
On Wed, Oct 25, 2023 at 4:22 PM Bruce Momjian wrote:
> On Wed, Oct 25, 2023 at 04:14:11PM -0700, David G. Johnston wrote:
> > Yeah, we punt on the entire concept in the data type section:
> >
> > "Managing these errors and how they propagate through calculations is th
On Wed, Oct 25, 2023 at 8:36 AM Bruce Momjian wrote:
> On Tue, Oct 24, 2023 at 06:45:48PM -0700, David G. Johnston wrote:
> > I'd prefer to keep pointing out that the ones documented are those whose
> > outputs will vary due to ordering.
>
> Okay, I re-added it
On Tue, Oct 24, 2023 at 1:39 PM Bruce Momjian wrote:
> On Tue, Dec 13, 2022 at 07:38:15PM -0700, David G. Johnston wrote:
> > All,
> >
> > The recent discussion surrounding aggregates and ORDER BY moved me to
> look over
> > our existing documentation, especial
On Monday, October 23, 2023, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> >> I do believe that we should be against exposing, like in this case, any
> internal
> >> implementation detail that encodes somet
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I didn't understand this completely. You want default privileges
> displayed as
> > > "(default)", but are you for or against &quo
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote:
>
> > along with not translating (none) and (default) and thus making the data
> contents
> > of these views environment independent. But minimizing the variance
On Mon, Oct 23, 2023 at 7:57 AM Tom Lane wrote:
>
> IOW, the current definition is "NULL privileges print as an empty
> string no matter what", and I don't think that serves to reduce
> confusion about whether an ACL is NULL or not. We ought to be doing
> what we can to make clear that such an A
On Monday, October 23, 2023, Laurenz Albe wrote:
> On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> > On Monday, October 23, 2023, Laurenz Albe
> wrote:
> > >
> > > --- a/src/bin/psql/describe.c
> > > +++ b/src/bin/psql/describe.c
>
On Monday, October 23, 2023, Laurenz Albe wrote:
>
> --- a/src/bin/psql/describe.c
> +++ b/src/bin/psql/describe.c
> @@ -6718,7 +6680,13 @@ static void
>printACLColumn(PQExpBuffer buf, const char *colname)
>{
> appendPQExpBuffer(buf,
> - "pg_catalog.array
On Fri, Oct 20, 2023 at 7:29 PM Erik Wienhold wrote:
> On 2023-10-20 22:35 +0200, David G. Johnston wrote:
> > In short, I don't want default privileges to start to obey \pset null
> when
> > it never has before and is documented as displaying the empty string. I
> do
On Fri, Oct 20, 2023 at 12:57 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> >> As near as I can tell, doing both things (the \pset null fix and
> >> substituting "(none)" for empty pr
On Fri, Oct 20, 2023 at 12:34 PM Tom Lane wrote:
> Laurenz Albe writes:
> > I am not sure how to proceed. Perhaps it would indeed be better to have
> > two competing commitfest entries. Both could be "ready for committer",
> > and the committers can decide what they prefer.
>
> As near as I can
On Thursday, October 19, 2023, David Steele wrote:
> On 10/19/23 10:24, Robert Haas wrote:
>
>> On Wed, Oct 18, 2023 at 7:15 PM David Steele wrote:
>>
>>>
pg_llbackup -d $CONNTR --backup-label=PATH --tablespace-map=PATH
--copy-data-directory=SHELLCOMMAND
I think in most cases
On Wednesday, October 18, 2023, David Steele wrote:
> On 10/18/23 08:39, Robert Haas wrote:
>
>> On Tue, Oct 17, 2023 at 4:17 PM David Steele wrote:
>>
>>> Given that the above can't be back patched, I'm thinking we don't need
>>> backup_label at all going forward. We just write the values we ne
On Tue, Oct 17, 2023 at 12:30 PM David Steele wrote:
> On 10/17/23 14:28, Robert Haas wrote:
> > On Mon, Oct 16, 2023 at 5:21 PM David G. Johnston
> > wrote:
> >> But no, by default, and probably so far as pg_basebackup is concerned,
> a server crash during backup r
On Tue, Oct 17, 2023 at 10:50 AM Robert Haas wrote:
> Life would be a lot easier here if we could get rid of the low-level
> backup API and just have pg_basebackup DTWT, but that seems like a
> completely non-viable proposal.
>
Yeah, my contribution to this area [1] is focusing on the API becaus
On Fri, Oct 6, 2023 at 1:29 PM Laurenz Albe
wrote:
> On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote:
> > On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> > > Here is a patch that does away with the special handling of NULL values
> > > in psql backslash commands.
> >
> > Erm, I for
On Mon, Oct 16, 2023 at 6:19 PM Laurenz Albe
wrote:
> On Mon, 2023-10-16 at 23:51 +0200, Erik Wienhold wrote:
> > What's the process for the CommitFest now since we settled on your
> > patch? This is my first time being involved in this, so still learning.
> > I'see that you've withdrawn your in
On Mon, Oct 16, 2023 at 12:36 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe
> wrote:
>
>> I think it won't meet with favor if there are cases that require manual
>> intervention
>> for starting t
On Mon, Oct 16, 2023 at 12:09 PM Laurenz Albe
wrote:
> I think it won't meet with favor if there are cases that require manual
> intervention
> for starting the server. That was the main argument for getting rid of
> the exclusive
> backup API, which had a similar problem.
>
In the rare case of
On Mon, Oct 16, 2023 at 10:26 AM Laurenz Albe
wrote:
> On Mon, 2023-10-16 at 09:26 -0700, David G. Johnston wrote:
> > This email is a first pass at a user-visible design for how our backup
> and restore
> > process, as enabled by the Low Level API, can be modified to make
Hi!
This email is a first pass at a user-visible design for how our backup and
restore process, as enabled by the Low Level API, can be modified to make
it more mistake-proof. In short, it requires pg_start_backup to further
expand upon what it means for the system to be in the midst of a backup,
On Thu, Oct 12, 2023 at 2:58 PM Nikita Malakhov wrote:
> Why pg_upgrade cannot be used?
>
We document both a pg_dump/pg_restore migration and a pg_upgrade one (not
to mention that logical backup and restore would cause the oids to
change). It seems odd to have a feature that requires pg_upgrade
On Thu, Oct 12, 2023 at 1:31 PM Nikita Malakhov wrote:
> About using surrogate key - this feature is more for data generated by
> the DBMS itself, i.e. data processed by some extension and saved
> and re-processed automatically or by user's request, but without bothering
> user with these interna
On Thu, Oct 12, 2023 at 11:43 AM Robert Haas wrote:
> On Thu, Oct 12, 2023 at 2:38 PM David G. Johnston
> wrote:
> > It's more like a lot number or surveying tract than an postal address.
> Useful for a single party, the builder or the government, but not something
>
On Thu, Oct 12, 2023, 11:21 Robert Haas wrote:
>
> The pg_upgrade experience right now is a bit as if you woke up in the
> morning and found that city officials came by during the night and
> renumbered your house, thus changing your address. Then, they sent
> change of address forms to everyone
On Thu, Oct 12, 2023 at 7:36 AM Tom Lane wrote:
> Nikita Malakhov writes:
> > Please advise on the idea of preserving pg_proc oids during pg_upgrade,
> in
> > a way like relfilenodes, type id and so on. What are possible downsides
> of
> > such a solution?
>
> You have the burden of proof backwa
On Thu, Oct 12, 2023 at 9:57 AM Nikita Malakhov wrote:
> Say, we have data processed by some user function and we want to keep
> reference to this function
> in our data.
>
Then you need to keep the user-visible identifier of said function
(schema+name+input argument types - you'd probably want
On Mon, Oct 9, 2023 at 1:27 PM Robert Haas wrote:
> On Tue, Oct 3, 2023 at 10:05 AM David G. Johnston
> wrote:
> >> The real-world use case, at least for me, is when using an ORM. For
> large object-graphs ORMs have a tendency to INSERT first with NULLs then
> UPDATE
On Mon, Oct 9, 2023 at 12:13 PM Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> >> My point with the second paragraph is that we could, instead of
> documenting the
> >> caveat about null printing as empty
On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe
wrote:
> On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
>
> > The built-in default privileges are only in effect if the object has not
> been
> > the target of a GRANT or REVOKE and also has not had its default
>
On Sun, Oct 8, 2023 at 9:10 PM Noah Misch wrote:
>
> I didn't think of any phrasing that clearly explained things without the
> reader consulting the code. I considered these:
>
> "socket file descriptor out of range: %d" [what range?]
>
>
Quick drive-by...but it seems that < 0 is a distinctly
On Sun, Oct 8, 2023 at 6:55 PM Erik Wienhold wrote:
> On 2023-10-08 06:14 +0200, Laurenz Albe write:
> > On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > > If you are happy enough with my patch, shall we mark it as ready for
> > > > committer?
> > >
> > > I amended your patch to also
On Wednesday, October 4, 2023, Jon Erdman wrote:
>
> So I'd like to get a general idea how likely this would be to getting
> accepted if it did it, and did it right?
>
Run a cron job checking for them. Allow for overrides by adding a comment
to any unclogged tables you’ve identified as being ac
Extending my prior email which is now redundant.
On Tue, Oct 3, 2023 at 7:00 PM David G. Johnston
wrote:
> On Tue, Oct 3, 2023 at 4:15 PM Karl O. Pinc wrote:
>
>> On Tue, 3 Oct 2023 14:51:31 -0700
>> "David G. Johnston" wrote:
>>
>> Isn't the en
On Tue, Oct 3, 2023 at 4:15 PM Karl O. Pinc wrote:
> On Tue, 3 Oct 2023 14:51:31 -0700
> "David G. Johnston" wrote:
>
> Isn't the entire section about "deviating from the normal flow of the
> code"? That's what makes me want "Exception"
On Tue, Oct 3, 2023 at 10:56 AM Karl O. Pinc wrote:
> On Mon, 2 Oct 2023 15:18:32 -0500
> "Karl O. Pinc" wrote:
>
> Version 7
>
>
0001 - I would just call the section:
Capturing Command Results into Variables
I would add commentary in there that it is only possible for variables to
take on singl
On Monday, October 2, 2023, Andreas Joseph Krogh wrote:
> På fredag 07. juli 2023 kl. 13:50:44, skrev Dilip Kumar <
> dilipbal...@gmail.com>:
>
> On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi,
> >
> > Currently, there is no support for CHECK constraint DEFERRABLE in a
> c
On Mon, Oct 2, 2023 at 12:25 PM Tom Lane wrote:
> Himanshu Upadhyaya writes:
> > V3 patch attached.
>
> Sorry for not weighing in on this before, but ... is this a feature
> we want at all? We are very clear in the existing docs that CHECK
> conditions must be immutable [1], and that's not some
On Sun, Oct 1, 2023 at 8:57 AM Zhang Mingli wrote:
> And if it’s true, shall we skip the order by clause for Materialized
> View when executing create/refresh statement?
>
We tend to do precisely what the user writes into their query. If they
don't want an order by they can remove it. I don't
On Fri, Sep 29, 2023 at 10:45 AM James Coleman wrote:
> Hello,
>
> While working on my talk for PGConf.NYC next week I came across this
> bullet in the docs on heap only tuples:
>
> > Old versions of updated rows can be completely removed during normal
> > operation, including SELECTs, instead of
On Wednesday, September 27, 2023, jacktby jacktby wrote:
> postgres=# SET enable_seqscan = off;
> SET
> postgres=# explain select * from t;
>QUERY PLAN
> -
> Seq Scan on t (cost=100.0
On Sunday, September 17, 2023, Chapman Flack wrote:
>
> In this one, both identifiers are part of the type name, and the
> separator a little more flamboyant.
>
> select to_regtype('character /* hi!
> am I part of the type name? /* what, me too? */ ok! */ -- huh!
> varying');
> to_regtype
> -
On Sun, Sep 17, 2023 at 6:25 PM Chapman Flack wrote:
> On 2023-09-17 20:58, David G. Johnston wrote:
> > Put differently, there is no syntax involved when the value being
> > provided
> > is the text literal name of a type as it is stored in pg_type.typname,
> > so
&
On Sun, Sep 17, 2023 at 5:34 PM Erik Wienhold wrote:
> On 18/09/2023 00:57 CEST Vik Fearing wrote:
>
> > On 9/18/23 00:41, Erik Wienhold wrote:
> > > On 18/09/2023 00:13 CEST David E. Wheeler
> wrote:
> > >
> > >> david=# select to_regtype('inteval second');
> > >> ERROR: syntax error at or ne
201 - 300 of 1002 matches
Mail list logo
