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
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
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
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 -
> &g
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
>
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
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
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
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
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
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
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
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,
> includi
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
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 i
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, espe
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 "
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
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,
> -
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
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
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
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
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
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
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
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 the se
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
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
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
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
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
> you
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
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 emp
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
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
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
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 entire
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" in the sec
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
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
>
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
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
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
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
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
On Wed, Sep 6, 2023 at 1:55 PM Ashutosh Sharma
wrote:
> But what if roleB doesn't want to give roleA access to
> the certain objects it owns.
Not doable - roleA can always pretend they are roleB one way or another
since roleA made roleB.
David J.
On Tue, Sep 5, 2023 at 2:50 PM Vik Fearing wrote:
> On 9/5/23 19:15, Alvaro Herrera wrote:
> > On 2023-Sep-05, Alvaro Herrera wrote:
> >
> > Looking now at what to do for CHECK_CONSTRAINTS with domain constraints,
> > I admit I'm completely confused about what this view is supposed to
> > show.
On Tue, Sep 5, 2023, 11:17 jacktby jacktby wrote:
>
> > 2023年9月5日 22:29，jacktby jacktby 写道：
> >
> I’m trying to add a new data type for my pg. How to do that? Can you give
> me more details or an example
>
Use create type and let the system deal with it. Otherwise, no, I don't
have that
OIDs don't exist independently of the data they are associated with. Give
more context if you want a better answer. Or just go look at the source
code commits for when the last time something needing an OID got added to
the core catalog.
David J.
On Friday, August 25, 2023, Hongxu Ma wrote:
>
>
> When I tried to select a big amount of rows, psql complains a error "Cannot
> add cell to table content: total cell count of 905032704 exceeded."
>
> We should use long for ncolumns and nrows and give a more obvious error
> message here.
>
> Any
On Thu, Mar 2, 2023 at 3:34 PM Tom Lane wrote:
> It seems like we should either restore "trigger" as its own
> type classification, or remove it from the list of properties
> you can filter on, or adjust the docs to describe "t" as a
> special filter condition. I'm kind of inclined to the
On Tue, Aug 1, 2023 at 2:38 PM Jeff Davis wrote:
> On Tue, 2023-08-01 at 11:16 -0700, David G. Johnston wrote:
> > They can use ALTER FUNCTION and the existing "FROM CURRENT"
> > specification to get back to current behavior if desired.
>
> The current behavior is
On Tue, Aug 1, 2023 at 10:42 AM Robert Haas wrote:
> Now, if we don't go in the direction of resolving everything at parse
> time, then I think capturing search_path is probably the next best
> thing, or at least the next best thing that I've thought up so far.
I'd much rather strongly
On Wed, Jul 19, 2023 at 9:47 AM Tom Lane wrote:
> I wrote:
> > Alvaro Herrera writes:
> >> +1 for backpatching to 16, given that it's a psql-only change that
> >> pertains to a backend change that was done in the 16 timeframe.
>
> > Agreed. In the interests of moving things along, I'll take
You are still in the wrong place - this is a developers list, which is only
slightly less bad than sending it to a security list.
We have a "general" list if you really cannot find a better place to send
stuff. But in this case your complaint has to do with the pgAdmin program
so its support
On Wed, Jul 12, 2023 at 2:49 PM Tom Lane wrote:
> Dave Cramer writes:
> > Obviously I am biased by the JDBC API which would like to have
> > PreparedStatement.execute() return the number of rows inserted
> > without having to wait to read all of the rows returned
>
> Umm ... you do realize that
On Fri, Jul 14, 2023 at 3:12 PM Chapman Flack wrote:
> If someone really does want to do a huge INSERT and get the generated
> values back in increments, it might be clearer to write an explicit
> INSERT RETURNING and issue it with executeQuery, where everything will
> work as expected.
>
>
For
On Fri, Jul 14, 2023 at 12:51 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > I agree that the documented contract of the insert command tag says it
> > reports the size of the entire tuple store maintained by the server
> during
> > the transaction ins
On Fri, Jul 14, 2023 at 11:34 AM wrote:
> On 2023-07-12 21:30, David G. Johnston wrote:
> > Right, and executeUpdate is the wrong API method to use, in the
> > PostgreSQL
> > world, when executing insert/update/delete with the non-SQL-standard
> > returning clause. .
On Fri, Jul 14, 2023 at 10:39 AM wrote:
> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal,
On Fri, Jul 14, 2023 at 9:50 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> Fixing that test in some manner and recompiling psql seems like it should
> be the easiest way to produce a core-only test case.
>
>
Apparently not - since it (ExecQueryUsingCu
On Fri, Jul 14, 2023 at 9:30 AM Dave Cramer wrote:
> David,
>
> I will try to get a tcpdump file. Doing this in libpq seems challenging as
> I'm not aware of how to create a portal in psql.
>
Yeah, apparently psql does something special (like ignoring it...) with its
FETCH_COUNT variable (set
On Thu, Jul 13, 2023 at 6:07 PM Dave Cramer wrote:
> On Thu, 13 Jul 2023 at 10:24, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Thursday, July 13, 2023, Dave Cramer wrote:
>>
>>>
>>> Any comment on why the CommandComplete is incor
On Thu, Jul 13, 2023 at 2:00 PM Gurjeet Singh wrote:
> On Thu, Jul 13, 2023 at 1:37 PM David G. Johnston
> wrote:
> >
> > I'm against simply breaking the past without any recourse as what we
> did for pg_dump/pg_restore still bothers me.
>
> I'm sure this is tan
On Thu, Jul 13, 2023 at 12:54 PM Gurjeet Singh wrote:
>
> The approach seems good to me. My concern is with this change's
> potential to cause an extended database outage. Hence sending it out
> as part of v16, without any escape hatch for the DBA, is my objection.
>
>
If this is limited to
On Thu, Jul 13, 2023 at 8:01 AM Tom Lane wrote:
> > I plan to replace it to:
>
> >pg_catalog.concat_ws(', ',
> > CASE WHEN pam.admin_option THEN 'ADMIN' END,
> > CASE WHEN m.rolinherit THEN 'INHERIT' END,
> > 'SET'
> >) AS "Options",
>
> That does not seem right. Is it
On Thursday, July 13, 2023, Dave Cramer wrote:
>
> Any comment on why the CommandComplete is incorrect ?
> It returns INSERT 0 0 if a cursor is used
>
Looking at DECLARE it is surprising that what you describe is even
possible. Can you share a psql reproducer?
David J.
On Wed, Jul 12, 2023 at 5:57 PM Dave Cramer wrote:
> On Wed, 12 Jul 2023 at 20:00, wrote:
>
>> Dave Cramer writes:
>> > Obviously I am biased by the JDBC API which would like to have
>> > PreparedStatement.execute() return the number of rows inserted
>> > without having to wait to read all of
On Wed, Jul 12, 2023 at 2:59 PM Dave Cramer wrote:
> On Wed, 12 Jul 2023 at 17:49, Tom Lane wrote:
>
>> Dave Cramer writes:
>> > Obviously I am biased by the JDBC API which would like to have
>> > PreparedStatement.execute() return the number of rows inserted
>> > without having to wait to
On Wed, Jul 12, 2023 at 1:03 PM Dave Cramer wrote:
>
> INSERT INTO test_table (cnt) VALUES (1), (2) RETURNING id
>
> if a portal is used to get the results then the CommandStatus
>
IIUC the portal is not optional if you including the RETURNING clause.
There is no CommandStatus message in the
On Friday, July 7, 2023, Himanshu Upadhyaya
wrote:
> I can think of one scenario, as below
>
> 1) any department should have an employee
> 2)any employee should be assigned to a department
> so, the employee table has a FK to the department table, and another check
> constraint should be added
On Sat, Jun 24, 2023 at 8:11 AM Pavel Luzanov
wrote:
> Notes
> * The name of the new command. It's a good name, if not for the history.
> There are two commands showing the same information about roles: \du and
> \dr.
> The addition of \drg may be misinterpreted: if there is \drg, then there
>
201 - 300 of 1133 matches
Mail list logo
