On Tue, Dec 13, 2022 at 9:45 AM Ronan Dunklau
wrote:
> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> > Accordingly, I find nothing at all attractive in this proposal.
> > I think the main thing it'd accomplish is to drive users back to
> > the bad old days of ordering-by-subquery,
On Thu, Dec 8, 2022 at 2:53 PM Paul Ramsey
wrote:
>
> random_normal(stddev float8 DEFAULT 1.0, mean float8 DEFAULT 0.0)
>
Any particular justification for placing stddev before mean? A brief
survey seems to indicate other libraries, as well as (at least for me)
learned convention, has the mean
On Wed, Dec 7, 2022 at 10:00 PM Vik Fearing wrote:
> On 12/7/22 04:22, David G. Johnston wrote:
> > On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing
> wrote:
> >
> >> On 12/6/22 05:57, David G. Johnston wrote:
> >>> On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
On Wed, Dec 7, 2022 at 10:34 AM Andres Freund wrote:
> > +{ oid => '8053',
> > + descr => 'get error message if string is not valid input for data
> type',
> > + proname => 'pg_input_invalid_message', provolatile => 's',
> > + prorettype => 'text', proargtypes => 'text regtype int4',
> > +
On Wed, Dec 7, 2022 at 9:59 AM Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Are you suggesting we should not go down the path that v8-0003 does in
> the
> > monitoring section cleanup thread? I find the usability of Chapter 54
> > System Views to be
On Tue, Dec 6, 2022 at 7:57 PM David G. Johnston
wrote:
> On Tue, Dec 6, 2022 at 6:36 PM Peter Smith wrote:
>
>> I'd like to "fix" this but IIUC there is no consensus yet about what
>> order is best for patch 0001, right?
>>
>>
> I'm planning o
On Wed, Dec 7, 2022 at 9:06 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > Why not do away with two separate functions and define a composite type
> > (boolean, text) for is_valid to return?
>
> I don't see any advantage to that. It would be harder to use
On Wed, Dec 7, 2022 at 8:23 AM Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-12-07 We 09:20, Tom Lane wrote:
> >> Returning to the naming quagmire -- it occurred to me just now that
> >> it might be helpful to call this style of error reporting "soft"
> >> errors rather than "safe"
On Wed, Dec 7, 2022 at 8:04 AM Andrew Dunstan wrote:
>
> On 2022-12-07 We 09:20, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Perhaps we should add a type in the regress library that will never have
> >> a safe input function, so we can test that the mechanism works as
> >> expected in that
On Wed, Dec 7, 2022 at 7:20 AM Tom Lane wrote:
>
> Returning to the naming quagmire -- it occurred to me just now that
> it might be helpful to call this style of error reporting "soft"
> errors rather than "safe" errors, which'd provide a nice contrast
> with "hard" errors thrown by
On Wed, Dec 7, 2022 at 1:58 AM Pantelis Theodosiou
wrote:
> On Tue, Dec 6, 2022 at 4:57 AM David G. Johnston
> wrote:
> ...
> >
> >
> > I'm referring to the query:
> >
> > select any_value(v order by v) from (values (2),(1),(3)) as vals (v);
> > //
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing wrote:
> On 12/6/22 05:57, David G. Johnston wrote:
> > On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
> wrote:
> >
> >> I can imagine an optimization that would remove an ORDER BY clause
> >> because it
On Tue, Dec 6, 2022 at 6:36 PM Peter Smith wrote:
> I'd like to "fix" this but IIUC there is no consensus yet about what
> order is best for patch 0001, right?
>
>
I'm planning on performing a more thorough review of 0003 and 0004 tomorrow.
As for 0001 - go with Peter E.'s suggested ordering.
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing wrote:
> On 12/6/22 05:22, David G. Johnston wrote:
> > On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing
> wrote:
> >
> >> On 12/5/22 18:56, David G. Johnston wrote:
> >>> Also, maybe we should have any_value do some
On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing wrote:
> On 12/5/22 18:56, David G. Johnston wrote:
> > Also, maybe we should have any_value do something like compute a 50/50
> > chance that any new value seen replaces the existing chosen value,
> instead
> > of simply retur
On Mon, Dec 5, 2022 at 7:57 AM Vik Fearing wrote:
> The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
> returns an implementation-dependent (i.e. non-deterministic) value from
> the rows in its group.
>
> PFA an implementation of this aggregate.
>
>
Can we please add
On Sun, Dec 4, 2022 at 9:37 PM Pavel Stehule
wrote:
>
> po 5. 12. 2022 v 5:28 odesílatel Tom Lane napsal:
>
>> Peifeng Qiu writes:
>> >> the need for this code seems not that great. But as to the code
>> itself I'm unable to properly judge.
>>
>> I mention this because trying to
On Sun, Dec 4, 2022 at 9:00 PM Peifeng Qiu wrote:
> > the need for this code seems not that great. But as to the code itself
> I'm unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT
On Fri, Dec 2, 2022 at 12:52 AM Peifeng Qiu wrote:
> Hi hackers.
>
> When a star(*) expands into multiple fields, our current
> implementation is to generate multiple copies of the expression
> and do FieldSelects. This is very inefficient because the same
> expression get evaluated multiple
On Thu, Dec 1, 2022 at 2:37 PM David Rowley wrote:
>
> The question is, what do you want to make work? If you're not worried
> about supporting DISTINCT when there is an ORDER BY clause and the
> frame options are effectively ROWS BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING, then it's
On Thu, Dec 1, 2022 at 2:21 PM David Rowley wrote:
> On Fri, 2 Dec 2022 at 09:02, Tom Lane wrote:
> >
> > David Rowley writes:
> > > I don't really agree that it will work fine in all cases though. If
> > > the numeric has more than 1000 digits left of the decimal point then
> > > the method
On Thu, Dec 1, 2022 at 7:39 AM Tom Lane wrote:
> Dean Rasheed writes:
>
> > The fact that passing a negative scale to round() isn't documented
> > does seem like an oversight though...
>
> Agreed, will do something about that.
>
>
Thanks. I'm a bit surprised you left "Rounds v to s decimal
On Thu, Dec 1, 2022 at 2:20 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 29.11.22 08:29, Peter Smith wrote:
> > PSA v8* patches.
> >
> > Here, patches 0001 and 0002 are unchanged, but 0003 has many changes
> > per David's suggestion [1] to change all these views to
> >
On Wed, Nov 30, 2022 at 6:45 PM Tom Lane wrote:
> David Rowley writes:
>
>
> I'm unsure what the repercussions of the fact that REAL and FLOAT8 are
> > not represented as decimals.
>
> The main thing is that I think the output will still have to be
> NUMERIC, or you're going to get complaints
On Wed, Nov 30, 2022 at 3:35 PM Tom Lane wrote:
>
> BTW, is "create a schema with the same name" sufficient detail?
> You have to either make it owned by that user, or explicitly
> grant CREATE permission on it. I'm not sure if that detail
> belongs here, but it feels like maybe it does.
>
>
On Wed, Nov 30, 2022 at 8:02 AM Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:10:35AM -0700, David G. Johnston wrote:
> > On Wed, Nov 30, 2022 at 6:52 AM Bruce Momjian wrote:
> > I'd maybe accept having it back-patched to v15 on that basis but not any
> > further
On Wed, Nov 30, 2022 at 6:52 AM Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:33:44AM +0100, Peter Eisentraut wrote:
> > On 30.11.22 02:51, Bruce Momjian wrote:
> > > Patch applied back to PG 11. Thanks to Simon for getting this
> important
> > > information in our docs, and for the
On Tue, Nov 29, 2022 at 12:32 AM wrote:
>
> Is there any other argument to be made against ADP?
>
These aren't privileges, they are memberships. The pg_default_acl catalog
is also per-data while these settings should be present in a catalog which,
like pg_authid, is catalog-wide. This latter
On Mon, Nov 28, 2022 at 2:55 PM Robert Haas wrote:
> On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston
> wrote:
> > That's fine, but are you saying this patch is incapable (or simply
> undesirable) of having the parts about handling defaults separated out from
> the par
On Mon, Nov 28, 2022 at 1:28 PM Robert Haas wrote:
> On Mon, Nov 28, 2022 at 3:02 PM Mark Dilger
> wrote:
>
> You can argue that a grant with INHERIT FALSE, SET FALSE, ADMIN TRUE
> still grants membership, and I think formally that's true, but I also
> think it's just picking something to
On Mon, Nov 28, 2022 at 12:42 PM wrote:
> David G. Johnston:
> > A quick tally of the thread so far:
> >
> > No Defaults needed: David J., Mark?, Tom?
> > Defaults needed - attached to role directly: Robert
> > Defaults needed - defined within Default Privileges
On Mon, Nov 28, 2022 at 11:57 AM wrote:
> Robert Haas:
> > I don't know if changing the syntax from A to B is really getting us
> > anywhere. I generally agree that the ALTER DEFAULT PRIVILEGES syntax
> > looks nicer than the CREATE/ALTER ROLE syntax, but I'm not sure that's
> > a sufficient
On Wed, Nov 23, 2022 at 1:36 AM Peter Smith wrote:
> On Thu, Nov 17, 2022 at 8:46 AM David G. Johnston
> wrote:
>
> > Also, make it so each view ends up being its own separate page.
> >
>
> I did not do this. AFAIK those views of chapter 54 get rendered to
&g
On Fri, Nov 25, 2022 at 5:09 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 23.11.22 09:36, Peter Smith wrote:
>
> v6-0005-Cleanup-view-name-hyperlinks-for-Tables-28.1-and-.patch
> v6-0006-Remove-all-stats-views-from-the-ToC-of-28.2.patch
>
> I wasn't sure yet whether these
On Wed, Nov 23, 2022 at 2:18 PM Robert Haas wrote:
> On Wed, Nov 23, 2022 at 3:59 PM David G. Johnston
> wrote:
> > I haven't yet formed a complete thought here but is there any reason we
> cannot convert the permission-like attributes to predefined roles?
> >
> >
On Wed, Nov 23, 2022 at 2:01 PM Robert Haas wrote:
> In the latter case there are two, one with
>
> grantor=bootstrap_supeuser/admin_option=true/set_option=false/inherit_option=false
> and a second with
> grantor=alice/admin_option=false/set_option=true/inherit_option=true.
>
This, IMO, is
On Wed, Nov 23, 2022 at 1:04 PM Robert Haas wrote:
>
> I'm not very certain about any of that stuff; I don't have a clear
> mental model of how it should work, or even what exact problem we're
> trying to solve. To me, the patches that I posted make sense as far as
> they go, but I'm not under
On Wed, Nov 23, 2022 at 11:47 AM Tom Lane wrote:
> Bruce Momjian writes:
> > Does this come up enough to document it? I assume the error message the
> > user receives is clear.
>
> Looks like you get
>
> if (nParams < 0 || nParams > PQ_QUERY_PARAM_MAX_LIMIT)
> {
>
On Mon, Nov 21, 2022 at 1:12 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2022-11-21 12:52:01 -0500, Robert Haas wrote:
> >> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
> >>> Why in the world is get_raw_page() marked as parallel safe?
> >>> It clearly isn't, given this restriction.
>
On Sun, Nov 20, 2022 at 6:24 PM Isaac Morland
wrote:
> What I'm finding is that the UPDATE is taking over an hour for 5000
> records, and tons of WAL is being generated, several files per minute.
> Selecting the non-PDF columns from the entire table takes a few
> milliseconds, and the only thing
On Sat, Nov 19, 2022 at 12:59 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sat, Nov 19, 2022 at 12:49 PM Tom Lane wrote:
>
>> Greg Stark writes:
>> > On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
>> >> Under what circumstances would
On Sat, Nov 19, 2022 at 12:49 PM Tom Lane wrote:
> Greg Stark writes:
> > On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
> >> Under what circumstances would it be appropriate for a script to take
> >> it on itself to decide that? It has no way of knowing what the next -f
> >> option is or what
On Sat, Nov 19, 2022 at 12:10 PM Tom Lane wrote:
> Fabien COELHO writes:
> > - when the current script is included from something,
> > you quit the current script and proceed after the \i of next -f, BAD
>
> > Question: is there any way to really abort a psql script from an
> included
> >
On Fri, Nov 18, 2022 at 4:11 AM Alvaro Herrera
wrote:
> On 2022-Nov-02, David G. Johnston wrote:
>
> > Version 2 attached, some significant re-working. Starting to think that
> > initdb isn't the place for some of this content - in particular the stuff
> > I'm deciding t
On Tue, Nov 15, 2022 at 6:39 PM Peter Smith wrote:
>
> I was also wondering (but have not yet done) if the content *outside*
> the tables should be reordered to match the table 28.1/28.2 order.
>
> Thoughts?
>
>
I would love to do away with the ToC listing of view names in 28.2
altogether.
On Mon, Nov 14, 2022 at 11:43 AM Robert Haas wrote:
> On Mon, Nov 14, 2022 at 12:47 PM Andres Freund wrote:
> > I'd go the other way. It's pretty unimportant whether it overflowed, it's
> > important how many subtxns there are. The cases where overflowing causes
> real
> > problems are when
On Mon, Nov 14, 2022 at 9:41 AM Robert Haas wrote:
> On Mon, Nov 14, 2022 at 11:35 AM Amit Singh
> wrote:
> > Making the information available in pg_stat_activity makes it a lot
> easier to identify the pid which has caused the subtran overflow. Debugging
> through the app code can be an
On Mon, Nov 14, 2022 at 9:04 AM Robert Haas wrote:
> On Mon, Nov 14, 2022 at 10:57 AM Justin Pryzby
> wrote:
> > > First, we're just talking about an extra couple of columns in
> > > pg_stat_activity here, which does not seem like a heavy price to pay.
> >
> > The most recent patch adds a
On Thu, Nov 10, 2022 at 10:58 AM Corey Huinker
wrote:
>
>> +if you are reading this prepatorily, please redesign your
>> query to use temporary tables or arrays
>>
>
> I agree with the documentation of this parameter.
> I agree with dissuading anyone from attempting to change it
> The
Inspired by a recent posting on Slack...
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index d5b2b627dd..5d68eef093 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -97,6 +97,13 @@
32
can be increased by recompiling
PostgreSQL
+
+
+
On Mon, Nov 7, 2022 at 5:19 PM Peter Smith wrote:
> On Mon, Nov 7, 2022 at 5:50 AM Tom Lane wrote:
> >
> > Peter Smith writes:
> > > Sorry, I forgot the attachments in the previous post. PSA.
> >
> > I spent a bit of time looking at this. I agree that a lot of the
> > current ordering choices
On Tue, Nov 8, 2022 at 7:37 PM Andres Freund wrote:
> On 2022-11-08 19:25:27 -0700, David G. Johnston wrote:
> > Actually two, because I also suggest that not only is the duration
> recorded,
> > but a counter be incremented each time a given state becomes the
> curre
On Tue, Nov 8, 2022 at 6:56 PM Andres Freund wrote:
>
> Separately from that, I'm a bit worried about starting to add accumulative
> counters to pg_stat_activity. It's already gotten hard to use interactively
> due to the number of columns - and why stop with the columns you suggest?
> Why
> not
On Mon, Nov 7, 2022 at 9:02 PM Pavel Stehule
wrote:
>
>
> út 8. 11. 2022 v 3:47 odesílatel Corey Huinker
> napsal:
>
>> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane wrote:
>>
>>> Corey Huinker writes:
>>> > I thought about basically reserving the \$[0-9]+ space as bind
>>> variables,
>>> > but it
On Tue, Nov 1, 2022 at 6:59 PM David G. Johnston
wrote:
>
> P.S. I'm now looking at the very first paragraph to initdb more closely,
> not liking "single server instance" all that much and wondering how to fit
> in "cluster user" there - possibly by s
On Tue, Nov 1, 2022 at 5:20 PM Justin Pryzby wrote:
> On Tue, Nov 01, 2022 at 03:47:15PM -0700, David G. Johnston wrote:
>
>
> I think this is wrong:
>
> | https://www.postgresql.org/docs/devel/app-initdb.html
> | -U username
> | --username=username
> |
&g
Hey,
Recent threads have pointed out some long-standing doc language in initdb
that could be made more precise, especially in light of the relatively
recent addition of a glossary. Toward this end I'm attaching a patch that
defines three terms: "bootstrap superuser", "database superuser" and
hing.
+user name.
David J.
On Mon, Oct 31, 2022 at 6:41 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 09.07.22 17:52, David G. Johnston wrote:
> > No. It is always the user parameter. It just so happens that parameter
&g
On Wed, Oct 26, 2022 at 2:13 AM jack...@gmail.com wrote:
> typedef struct A_Expr
>
>
>
> {
>
>
>
> pg_node_attr(custom_read_write)
>
>
>
> NodeTag type;
>
>
>
> A_Expr_Kind kind; /* see above */
>
>
>
> List *name; /* possibly-qualified name of
On Mon, Oct 24, 2022 at 3:02 PM Anton A. Melnikov
wrote:
> Hello!
>
> Please, could somebody explain what the "compound" queries were created
> for?
> Maybe i'm calling them wrong. It's about queries like:
> SELECT 1 + 2 \; SELECT 2.0 AS "float" \; SELECT 1;
>
> Such queries can neither be
On Sat, Oct 8, 2022 at 8:47 AM Robert Haas wrote:
> On Sat, Oct 8, 2022 at 11:14 AM Tom Lane wrote:
> > Joe Conway writes:
> > > Thanks -- looks good to me. If there are no other comments or concerns,
> > > I will commit/push by the end of the weekend.
> >
> > Robert seems to think that this
On Wednesday, September 21, 2022, Ashwin Agrawal
wrote:
> Currently, pg_basebackup has
> --create-slot option to create slot if not already exists or
> --slot to use existing slot
>
> Which means it needs knowledge on if the slot with the given name already
> exists or not before invoking the
Hi,
While looking at Robert's work to improve our handling of roles I found it
helpful to be able to see not only the directly recorded membership
information, which now includes grantor, but also to see what was reachable
via SET ROLE. The attached patch puts that information at our users'
On Fri, Aug 12, 2022 at 12:48 PM Bruce Momjian wrote:
> On Mon, Jul 18, 2022 at 08:04:12PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2022-07-18 19:47:39 -0700, David G. Johnston wrote:
> > > On Thu, Jul 14, 2022 at 4:31 PM Andres Freund
> wrote:
> &g
On Sunday, July 31, 2022, Gianluca Calcagni wrote:
>
> The real drawback is that such approach is forgoing the natural principle
> of *"separation of concerns"*! I have been looking into using trigger
> frameworks to solve this problem, but there is no trigger framework that is
> able to meet my
On Sun, Jul 31, 2022 at 11:18 AM Stephen Frost wrote:
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
> wrote:
>
> + }
> +
> + /*
> +* Disallow attempts to grant ADMIN OPTION back to a user who
> granted it
> +
On Thu, Jul 28, 2022 at 12:09 PM Robert Haas wrote:
> On Tue, Jul 26, 2022 at 12:46 PM Robert Haas
> wrote:
> > I believe that these patches are mostly complete, but I think that
> > dumpRoleMembership() probably needs some more work. I don't know what
> > exactly, but there's nothing to cause
On Wed, Jul 27, 2022 at 8:22 PM Tom Lane wrote:
> I wrote:
> > If EDB isn't adequately filling in the documentation for the behavior
> > of their packaging, that's on them.
>
> Having now looked more closely at the pg_upgrade documentation,
> I don't think this is exactly EDB's fault; it's text
On Wednesday, July 27, 2022, Julien Rouhaud wrote:
> On Wed, Jul 27, 2022 at 07:02:51PM -0700, David G. Johnston wrote:
> >
> > In the end the problem is ours and cannot be simply assigned to a
> > third-party. So let's resolve it here (on this list, whatever th
On Wed, Jul 27, 2022 at 6:42 PM Julien Rouhaud wrote:
> Hi,
>
> On Wed, Jul 27, 2022 at 11:36:11PM +0200, Thomas Kellerer wrote:
> > David G. Johnston schrieb am 27.07.2022 um 21:21:
> > > And then there is the issue of file ownership.
> > >
> >
On Fri, Jul 22, 2022 at 1:20 PM Jacob Champion
wrote:
> On Wed, Jun 1, 2022 at 11:09 PM KAWAMOTO Masaya
> wrote:
> > That sounds a nice idea. But I don't think that postgres shows in the
> > EXPLAIN output why the plan is selected. Would it be appropriate to
> > show that GEQO is used in
Hey,
Just interacted with a frustrated user on Slack trying to upgrade from v13
to v14 on Windows. Our official download page for the Windows installer
claims the core documentation as its official reference - can someone
responsible for this area please suggest and test some changes to make
On Tue, Jul 26, 2022 at 2:32 PM Tom Lane wrote:
>
> 2. I don't like the "palloc_ptrtype" name at all. I see that you
> borrowed that name from talloc, but I doubt that's a precedent that
> very many people are familiar with.
> To me it sounds like it might
> allocate something that's the
On Tue, Jul 26, 2022 at 1:54 PM Zhihong Yu wrote:
> Hi,
> I was looking at ExplainOneQuery() where ExplainOneQuery_hook is called.
>
> Currently the call to the hook is in if block and normal processing is in
> else block.
>
> What if the hook doesn't want to duplicate the whole code printing
>
On Mon, Jan 24, 2022 at 9:54 AM Justin Pryzby wrote:
> I'm renaming this thread for better visibility, since buffers is a small,
> optional part of the patches I sent.
>
> I made a CF entry here.
> https://commitfest.postgresql.org/36/3409/
>
> On Wed, Dec 01, 2021 at 06:58:20PM -0600, Justin
On Tue, Jul 26, 2022 at 10:37 AM Robert Haas wrote:
> On Mon, Jul 25, 2022 at 9:47 PM Kyotaro Horiguchi
> wrote:
> > One arguable point would be whether we will need to put restriction
> > the target relations that Bob can vacuum/analyze.
>
> But for a command with a target, you really ought
On Thu, Jul 14, 2022 at 12:44 PM Bruce Momjian wrote:
> On Sat, Jul 9, 2022 at 12:59:23PM -0400, Bruce Momjian wrote:
> > On Sun, Jun 26, 2022 at 09:14:56AM -0700, David G. Johnston wrote:
> > > So leave the "release" behavior implied from the rollback behavior?
This works:
vagrant@vagrant:/usr/local/pgsql/bin$ echo 'value1' | ./psql -d postgres -c
'\copy csvimport from stdin;'
COPY 1
However:
For \copy ... from stdin, data rows are read from the same source that
issued the command
and
When either -c or -f is specified, psql does not read commands
Hey,
This came up today on twitter as a claimed POLA violation:
postgres=# select random(), random() order by random();
random| random
-+-
0.08176638503720679 | 0.08176638503720679
(1 row)
Which was explained long ago by Tom as:
On Thu, Jul 21, 2022 at 9:28 AM Tom Lane wrote:
> Robert Haas writes:
> > Currently, it's possible to remove the rolissuper bit from the
> > bootstrap superuser, but this leaves that user - and the system in
> > general - in an odd state. The bootstrap user continues to own all of
> > the
On Mon, Jul 18, 2022 at 8:16 PM Bruce Momjian wrote:
> On Mon, Jul 18, 2022 at 07:39:55PM -0700, David G. Johnston wrote:
> > On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
> >
> >
> > +0.90
> >
> > Consider changing:
> >
> >
On Thu, Jul 14, 2022 at 4:31 PM Andres Freund wrote:
> Hi,
>
> I had missed David's original email on this topic...
>
> On 2022-07-14 18:58:09 -0400, Bruce Momjian wrote:
> > On Wed, Apr 20, 2022 at 04:40:44PM -0700, David G. Johnston wrote:
> > > The new cumulative
On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
>
> On Tue, 19 Jul 2022 at 03:58, Bruce Momjian wrote:
> > On Fri, Jul 15, 2022 at 09:29:20PM +0800, Japin Li wrote:
> >>
> >> On Fri, 15 Jul 2022 at 08:49, Bruce Momjian wrote:
> >> > On Tue, Jul 5, 2022 at 08:02:33PM -0400, Tom Lane wrote:
>
On Mon, Jul 18, 2022 at 3:18 PM Tom Lane wrote:
>
> Independently of the dimensionality question --- I'd imagined that
> array_sample would select a random subset of the array elements
> but keep their order intact. If you want the behavior shown
> above, you can do
On Sat, Jul 16, 2022 at 8:18 PM Tom Lane wrote:
> Martin Kalcher writes:
>
> > - I added a second function sample(), because it is a lot faster to take
> >some elements from an array than to shuffle the whole array and
> >slice it. This function can be removed if it is not wanted.
>
> I
On Sat, Jul 16, 2022 at 7:25 PM Martin Kalcher <
martin.kalc...@aboutsource.net> wrote:
>
> - I added a second function sample(), because it is a lot faster to take
>some elements from an array than to shuffle the whole array and
>slice it. This function can be removed if it is not
On Sat, Jul 2, 2022 at 12:42 PM Dian M Fay wrote:
> On Thu Jun 9, 2022 at 11:57 AM EDT, David G. Johnston wrote:
> > Reposting this to its own thread.
> >
> >
> https://www.postgresql.org/message-id/flat/CAKFQuwby1aMsJDMeibaBaohgoaZhivAo4WcqHC1%3D9-GDZ3TSng%40mail.gmail.c
On Fri, Jul 15, 2022 at 12:36 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> I would ask that we at least rename it to:
>
> Disk Usage Functions
>
>
Nevermind...I identified the scope of that header incorrectly and the
rename wouldn't be appropri
On Thu, Jul 7, 2022 at 2:33 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Looking again at the SELECT Reference page while helping a novice user I
> > was once again annoyed but how the most common query syntax form for the
> > FROM clause is buried wit
On Thu, Jul 14, 2022 at 12:18 PM Bruce Momjian wrote:
> On Mon, Jul 11, 2022 at 05:22:41PM +0300, Aleksander Alekseev wrote:
> > Hi Bruce,
> >
> > > I was not happy with putting this in the Transaction Isolation section.
> > > I rewrote it and put it in the INSERT secion, right before ON
On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote:
>
> That appears to be copied from the INSERT page.
> What does that mean, if not that data types will be resolved as needed ?
>
Yep, and the system needs to resolve the type at a point where there is no
contextual information and so it
On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote:
> On Fri, Jul 15, 2022 at 12:17:51PM -0700, David G. Johnston wrote:
> > On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera
> wrote:
> > > On 2022-Jul-15, Justin Pryzby wrote:
> > >
> > > > It seems a
On Thu, Jul 14, 2022 at 3:57 PM Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Apr 25, 2022 at 08:33:47AM -0700, David G. Johnston wrote:
> >> Both the location and name of the linked to section make no sense to me:
> >> https://www.postgresql.org/docs/c
On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera
wrote:
> On 2022-Jul-15, Justin Pryzby wrote:
>
> > It seems a bit odd that it's impossible to use merge with prepared
> statements
> > without specifically casting the source types (which I did now to
> continue my
> > experiment).
>
> I have no
On Fri, Jul 15, 2022 at 6:27 AM Japin Li wrote:
>
> >
> > +servers. If setting max_wal_senders to
> > +0 consider also reducing the amount of WAL
> produced
> > +by changing wal_level to
> minimal.
> >
> > I don't think this is great advice. It will encourage people to
On Thu, Jul 14, 2022 at 2:41 PM Bruce Momjian wrote:
> On Fri, Jul 8, 2022 at 10:55:55PM -0400, Bruce Momjian wrote:
> > > The/that inconsistency ... choose one. Or actually, the "an ... the"
> > > combination you used elsewhere doesn't grate on the ear either.
> > >
> > > + For each
On Sat, Jul 9, 2022, 08:16 Bruce Momjian wrote:
> On Sat, Jul 9, 2022 at 08:06:21AM -0700, David G. Johnston wrote:
> > Maybe invoke the wording from the libpq docs and say:
> >
> > The default database name is the same as the user connection parameter.
> >
> >
On Friday, July 8, 2022, Bruce Momjian wrote:
> On Fri, Jul 8, 2022 at 10:17:11PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jul 5, 2022 at 08:20:25PM -0400, Tom Lane wrote:
> > >> I agree this phrasing needs some work, but "resolved" doesn't seem
> > >> helpful, since
On Wed, Jul 6, 2022 at 10:24 AM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Thu, 9 Jun 2022 at 18:12, David G. Johnston
> wrote:
> >
> > Per suggestion over on -docs:
> >
> >
> https://www.postgresql.org/message-id/bl0pr06mb4978
On Tue, Jul 5, 2022 at 5:20 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > In passing, the authentication error examples use the phrase
> > "database user name" in a couple of locations. The word
> > database in b
301 - 400 of 1079 matches
Mail list logo
