On Mon, 13 May 2024 at 04:40, aa wrote:
> Hello Everyone!
>
> Is there any chance to get some kind of a result set sifting mechanism in
> Postgres?
>
> What I am looking for is a way to get for example: "nulls last" in a
> result set, without having to call "order by" or having to use UNION ALL,
On Fri, 26 Apr 2024 at 14:04, Robert Haas wrote:
systems have this problem. I wonder if anyone knows of another system
> that works like PostgreSQL in this regard (without sharing code).
>
In Haskell period (".") is used both to form a qualified name (module.name),
very similar to our
On Thu, 25 Apr 2024 at 17:05, Tom Lane wrote:
> > I think it's confusing and counterintuitive that putting parentheses
> > around a subexpression completely changes the meaning. I don't know of
> > any other programming language that behaves that way,
>
> I take it that you also don't believe
On Thu, 28 Mar 2024 at 20:38, Erik Wienhold wrote:
> Of course the problem with using DROP and CREATE is that indexes and
> privileges (anything else?) must also be restored. I haven't bothered
> with that yet.
>
Not just those — also anything that depends on the matview, such as views
and
On Wed, 27 Mar 2024 at 13:05, Greg Sabino Mullane
wrote:
> The purpose of the setting is to prevent accidental
>> modifications via ALTER SYSTEM in environments where
>
>
> The emphasis on 'accidental' seems a bit heavy here, and odd. Surely, just
> "to prevent modifications via ALTER SYSTEM in
On Thu, 21 Mar 2024 at 10:30, Tom Lane wrote:
> The SQL spec's answer to that conundrum appears to be "NULL is
> a valid value of every domain, and if you don't like it, tough".
>
To be fair, NULL is a valid value of every type. Even VOID has NULL.
In this context, it’s a bit weird to be able
On Tue, 5 Mar 2024 at 07:55, Laurenz Albe wrote:
> Inspired by feedback to [1], I thought about how to reduce log spam.
>
> My experience from the field is that a lot of log spam looks like
>
> database/table/... "xy" does not exist
> duplicate key value violates unique constraint "xy"
>
>
On Mon, 29 Jan 2024 at 10:42, Mark Dilger
wrote:
> I don't think anybody is proposing re-working the existing codebase. I
> understand this to be only about allowing new code to use the newer style.
> Personally, I like, as much as possible, to use initializations to const
> variables and avoid
On Mon, 29 Jan 2024 at 10:31, Mark Dilger
wrote:
>
>
> > On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio
> wrote:
> >
> > So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> > +1 to indicate support against/for the change.
>
> -1 for me.
>
> -Infinity for refactoring the
On Sat, 30 Dec 2023 at 09:23, Pavel Luzanov
wrote:
> I think that writing the value "infinity" in places where there is no
> value is
> not a good thing. This hides the real value of the column. In addition,
> there is no reason to set "infinity" when the password is always valid with
> default
On Thu, 21 Dec 2023 at 09:26, Amit Kapila wrote:
> A conflicting column where NULL indicates no conflict, and other
> > values indicate the reason for the conflict, doesn't seem too bad.
> >
>
> This is fine too.
>
I prefer this option. There is precedent for doing it this way, for example
in
On Mon, 4 Dec 2023 at 02:54, Laurenz Albe wrote:
> REINDEX is philosophically a maintenance command and a Postgres
> > extension not in the SQL standard, so it does not really qualify as a
> > DDL because it does not do in object definitions, so we could just
> > delete this comment. Or could
On Mon, 6 Nov 2023 at 15:54, Tom Lane wrote:
> Isaac Morland writes:
> > I still think the right default is that CREATE FUNCTION stores the
> > search_path in effect when it runs with the function, and that is the
> > search_path used to run the function (and don't &qu
On Thu, 2 Nov 2023 at 14:22, Jeff Davis wrote:
> On Tue, 2023-10-31 at 13:16 -0400, Isaac Morland wrote:
>
> > Perhaps the search_path for running a maintenance command should be
> > the search_path set for the table owner (ALTER ROLE … SET search_path
> > …)?
>
>
On Mon, 6 Nov 2023 at 11:58, Laurenz Albe wrote:
> Become a superuser again and commit:
> >
> > RESET ROLE;
> >
> > COMMIT;
> > NOTICE: current_user = postgres
> >
> >
> > So a deferred constraint trigger does not run with the same security
> context
> > as an immediate trigger. This is
On Fri, 27 Oct 2023 at 19:04, Jeff Davis wrote:
The approach of locking down search_path during maintenance commands
> would solve the problem, but it means that we are enforcing search_path
> in some contexts and not others. That's not great, but it's similar to
> what we are doing when we
On Mon, 23 Oct 2023 at 13:40, Tom Lane wrote:
> I wrote:
> > Given the exception the spec makes for CAST, I wonder if we shouldn't
> > just say "NULL is a valid value of every domain type, as well as every
> > base type. If you don't like it, too bad; write a separate NOT NULL
> > constraint
On Tue, 17 Oct 2023 at 11:15, Robert Haas wrote:
> Are code points assigned from a gapless sequence? That is, is the
> implementation of codepoint_is_assigned(char) just 'codepoint <
> SOME_VALUE' and SOME_VALUE increases over time?
>
Not even close. Code points are organized in blocks, e.g.
On Fri, 6 Oct 2023 at 15:07, Jeff Davis wrote:
> On Fri, 2023-10-06 at 13:33 -0400, Robert Haas wrote:
> > What I think people really want is a whole column in
> > some encoding that isn't the normal one for that database.
>
> Do people really want that? I'd be curious to know why.
>
> A lot of
On Thu, 5 Oct 2023 at 07:32, Robert Haas wrote:
> But I do think that sometimes users are reluctant to perform encoding
> conversions on the data that they have. Sometimes they're not
> completely certain what encoding their data is in, and sometimes
> they're worried that the encoding
On Wed, 4 Oct 2023 at 17:37, Jeff Davis wrote:
> On Wed, 2023-10-04 at 14:14 -0400, Isaac Morland wrote:
> > Always store only UTF-8 in the database
>
> What problem does that solve? I don't see our encoding support as a big
> source of problems, given that database-wide UTF-8
On Wed, 4 Oct 2023 at 14:05, Chapman Flack wrote:
> On 2023-10-04 13:47, Robert Haas wrote:
>
> The SQL standard would have me able to:
>
> CREATE TABLE foo (
>a CHARACTER VARYING CHARACTER SET UTF8,
>b CHARACTER VARYING CHARACTER SET LATIN1
> )
>
> and so on, and write character
On Mon, 11 Sept 2023 at 11:11, Magnus Hagander wrote:
> I'm actually going to put a strong +1 to Gabriele's proposal. It's an
> > undeniable problem (I'm only seeing arguments regarding other ways the
> > system would be insecure), and there might be real use cases for users
> > outside
On Fri, 8 Sept 2023 at 10:03, Gabriele Bartolini <
gabriele.bartol...@enterprisedb.com> wrote:
> ALTER SYSTEM is already heavily restricted.
>
>
> Could you please help me better understand what you mean here?
>
>
>> I don't think we need random kluges added to the permissions system.
>
>
> If
On Mon, 21 Aug 2023 at 19:23, Michael Paquier wrote:
I am not sure that we need to change this historic term, TBH. Perhaps
> it would be shorter to just rip off the trust method from the tree
> with a deprecation period but that's not something I'm much in favor
> off either (I use it daily for
On Wed, 2 Aug 2023 at 01:07, Nathan Bossart
wrote:
> On Mon, Jul 31, 2023 at 10:28:31PM -0700, Jeff Davis wrote:
> > On Sat, 2023-07-29 at 12:44 -0400, Isaac Morland wrote:
> >> Essentially, "just" observe efficiently (somehow) that no change is
> >> needed,
On Sat, 29 Jul 2023 at 11:59, Jeff Davis wrote:
Unfortunately, adding a "SET search_path" clause to functions slows
> them down. The attached patches close the performance gap
> substantially.
>
> Changes:
>
> 0001: Transform the settings in proconfig into a List for faster
> processing. This is
On Tue, 25 Jul 2023 at 14:59, Robert Haas wrote:
> On Tue, Jul 25, 2023 at 1:33 PM Isaac Morland
> wrote:
> > My suggestion is for \d+ to show NOT NULL constraints only if there is
> something weird going on (wrong name, duplicate constraints, …). If there
> is n
On Tue, 25 Jul 2023 at 12:24, Alvaro Herrera
wrote:
> On 2023-Jul-25, Isaac Morland wrote:
>
> > I agree. I definitely do *not* want a bunch of NOT NULL constraint names
> > cluttering up displays. Can we legislate that all NOT NULL implementing
> > constraints are n
On Tue, 25 Jul 2023 at 11:39, Robert Haas wrote:
>
> I'm not really thrilled with the idea of every not-null constraint
> having a name, to be honest. Of all the kinds of constraints that we
> have in the system, NOT NULL constraints are probably the ones where
> naming them is least likely to
On Mon, 17 Jul 2023 at 11:26, Aleksander Alekseev
wrote:
> Hi,
>
> > I was working on a project with event triggers and was wondering if
> there was any context from the developers around why some things make this
> list and others do not. Example: REVOKE/ GRANT are in the event trigger
> matrix
On Tue, 11 Jul 2023 at 10:43, Greg Sabino Mullane
wrote:
> This has been a long-standing annoyance of mine. Who hasn't done something
> like this?:
>
> psql> SET random_page_cost = 2.5;
> (do some stuff, realize that rpc was too high)
>
> Let's put that inside of postgresql.conf:
>
>
>
On Thu, 6 Jul 2023 at 21:39, Jeff Davis wrote:
I apologize in advance if anything I’ve written below is either too obvious
or too crazy or misinformed to belong here. I hope I have something to say
that is on point, but feel unsure what makes sense to say.
* It might break for users who have a
On Thu, 15 Jun 2023 at 10:49, Tom Lane wrote:
In particular, we've never enforced that an immutable function can't
> call non-immutable functions. While that would seem like a good idea
> in the abstract, we've intentionally not tried to do it. (I'm pretty
> sure there is more than one round
The usual question is “why did DELETE not release disk space?”, and I
understand why that is and something about how to get the space back
(VACUUM).
I have a database which hosts multiple applications in various schemas and
I’m trying to make test/sample data files by starting with a restored
On Fri, 19 May 2023 at 22:59, jian he wrote:
>
> Sorry for changing the subject line.
>
> these two commits seems not mentioned.
>
On a similar topic, should every committed item from the commitfest be
mentioned, or only ones that are significant enough?
I’m wondering because I had a role
On Sun, 23 Apr 2023 at 12:28, Pavel Stehule wrote:
>
>
> Dne ne 23. 4. 2023 18:03 uživatel Isaac Morland
> napsal:
>
>> On Sun, 23 Apr 2023 at 10:52, Tom Lane wrote:
>>
>>> Isaac Morland writes:
>>>
>>
>>
>>> > I migh
On Sun, 23 Apr 2023 at 10:52, Tom Lane wrote:
> Isaac Morland writes:
>
> > I might go so
> > far as to change the psql display routines to not leave a blank line
> after
> > the content in the event it ends with a newline.
>
> psql has *no* business changi
On Sun, 23 Apr 2023 at 01:31, Pavel Stehule wrote:
> Hi
>
> maybe I found a bug in xmlserialize
>
> SELECT xmlserialize(DOCUMENT '42'
> AS varchar INDENT);
>
> (2023-04-23 07:27:53) postgres=# SELECT xmlserialize(DOCUMENT
> '42' AS varchar INDENT);
> ┌─┐
> │
On Sat, 22 Apr 2023 at 11:01, Gurjeet Singh wrote:
> This is a proposal for a new transaction characteristic. I haven't
> written any code, yet, and am interested in hearing if others may find
> this feature useful.
>
> Many a times we start a transaction that we never intend to commit;
> for
On Mon, 19 Dec 2022 at 17:57, Corey Huinker wrote:
>
> Attached is my work in progress to implement the changes to the CAST()
> function as proposed by Vik Fearing.
>
> CAST(expr AS typename NULL ON ERROR)
> will use error-safe functions to do the cast of expr, and will return
> NULL if the
On Sat, 25 Mar 2023 at 15:59, Tom Lane wrote:
> Joseph Koshakow writes:
> > In terms of adding/subtracting infinities, the IEEE standard is pay
> > walled and I don't have a copy. I tried finding information online but
> > I also wasn't able to find anything useful. I additionally checked to
On Thu, 2 Mar 2023 at 17:20, Tom Lane wrote:
> Isaac Morland writes:
> > [ 0001-Remove-source-code-display-from-df-v6.patch ]
>
> Pushed after some editorialization on the test case.
>
Thanks!
One thing I noticed while testing is that if you apply \df+ to an
> aggregate f
I thought I should be able to do this:
=> create view testv as values (1, 'a'), (2, 'b'), (3, 'c');
CREATE VIEW
=> create table testt of testv;
ERROR: type testv is not a composite type
But as you can see I can’t. pg_type seems to think the type is composite:
ijmorlan=> select typtype from
On Fri, 27 Jan 2023 at 09:49, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 25.01.23 22:25, Tom Lane wrote:
> > So this invents an initdb switch "-c NAME=VALUE" just like the
> > one that the server itself has long had.
>
> This seems useful.
>
> > The specified settings
> >
On Wed, 25 Jan 2023 at 12:02, Pavel Stehule wrote:
>
>
> st 25. 1. 2023 v 17:22 odesílatel songjinzhou <2903807...@qq.com> napsal:
>
>>
>> As follows, we can only repeat the for statement before we use such SQL:
>>
>> begin
>> for i in 10..20 loop
>> raise notice '%', i; -- Things to do
>> end
On Tue, 24 Jan 2023 at 11:40, Greg Stark wrote:
>
> At the end of the day Unicode kind of assumes a variable-width display
> where the rendering is handled by something that has access to the
> actual font metrics. So anything trying to line things up in columns
> in a way that works with any
On Sun, 22 Jan 2023 at 21:37, Justin Pryzby wrote:
> On Sun, Jan 22, 2023 at 08:23:25PM -0500, Isaac Morland wrote:
> > > Were you able to test with your own github account ?
> >
> > I haven’t had a chance to try this. I must confess to being a bit
> confused
>
On Sun, 22 Jan 2023 at 17:27, Justin Pryzby wrote:
> On Sun, Jan 22, 2023 at 04:28:21PM -0500, Isaac Morland wrote:
> > On Sun, 22 Jan 2023 at 15:04, Tom Lane wrote:
> But now I'm having a problem I don't understand: the CI are still
> failling,
> > but not in the psql
On Sun, 22 Jan 2023 at 16:56, Justin Pryzby wrote:
> On Sun, Jan 22, 2023 at 03:04:14PM -0500, Tom Lane wrote:
>
> That's excessive. The policy Alvaro mentions applies to globally-visible
> > object names (i.e., database, role, and tablespace names), and it's there
> > to try to ensure that
On Sun, 22 Jan 2023 at 15:04, Tom Lane wrote:
> Isaac Morland writes:
> > On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera
> > wrote:
> >> This one would fail the sanity check that all roles created by
> >> regression tests need to have names that st
On Sun, 22 Jan 2023 at 14:26, Alvaro Herrera
wrote:
> On 2023-Jan-22, Isaac Morland wrote:
>
> > I’ve re-written the tests to create a test-specific role and functions so
> > there is no longer a dependency on the superuser name.
>
> This one would fail the sanity chec
On Sun, 22 Jan 2023 at 00:45, Justin Pryzby wrote:
> On Sun, Jan 22, 2023 at 12:18:34AM -0500, Isaac Morland wrote:
>
> > It turns out that my tests wanted the owner to be “vagrant” rather than
> > “postgres”. This is apparently because I was running as that user (in a
&g
On Thu, 19 Jan 2023 at 13:02, Isaac Morland wrote:
> On Thu, 19 Jan 2023 at 11:30, Justin Pryzby wrote:
>
>> On Wed, Jan 18, 2023 at 10:27:46AM -0500, Isaac Morland wrote:
>> >
>> > I thought I had: https://commitfest.postgresql.org/42/4133/
>&g
On Thu, 19 Jan 2023 at 11:30, Justin Pryzby wrote:
> On Wed, Jan 18, 2023 at 10:27:46AM -0500, Isaac Morland wrote:
> >
> > I thought I had: https://commitfest.postgresql.org/42/4133/
>
> This is failing tests:
> http://cfbot.cputube.org/isaac-morland.html
>
>
On Wed, 18 Jan 2023 at 00:00, Pavel Stehule wrote:
>
> út 17. 1. 2023 v 20:29 odesílatel Isaac Morland
> napsal:
>
>>
>> I welcome comments and feedback. Now to try to find something manageable
>> to review.
>>
>
> looks well
>
> you miss update p
On Thu, 12 Jan 2023 at 12:06, Isaac Morland wrote:
Thanks everybody. So based on the latest discussion I will:
>
> 1) rename the column from “Source code” to “Internal name”; and
> 2) change the contents to NULL except when the language (identified by
> oid) is INTERNAL or
On Thu, 12 Jan 2023 at 10:04, Magnus Hagander wrote:
We could shorten it to "See \sf" or something like that. But if we change
>>> the column header to "internal name" or the like, then the column just
>>> obviously doesn't apply for non-internal languages, so leaving it null
>>> should be
On Thu, 12 Jan 2023 at 05:59, Gurjeet Singh wrote:
I'll consider using one of the other special characters. Do you have
> any suggestions?
>
What about backticks (`)? They are allowed as operator characters but do
not otherwise appear in the lexical syntax as far as I can tell:
On Wed, 11 Jan 2023 at 13:11, Pavel Stehule wrote:
please, don't send top post replies -
> https://en.wikipedia.org/wiki/Posting_style
>
Sorry about that; I do know to do it properly and usually get it right.
GMail doesn’t seem to have an option (that I can find) to leave no space at
the top
:
>
>
> st 11. 1. 2023 v 18:25 odesílatel Magnus Hagander
> napsal:
>
>>
>>
>> On Wed, Jan 11, 2023 at 6:19 PM Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> st 11. 1. 2023 v 17:50 odesílatel Isaac Morland
>>>
I find \df+ much less useful than it should be because it tends to be
cluttered up with source code. Now that we have \sf, would it be reasonable
to remove the source code from the \df+ display? This would make it easier
to see function permissions and comments. If somebody wants to see the full
On Sun, 8 Jan 2023 at 07:28, Dean Rasheed wrote:
So playing around with it (and inspired by the WITH ORDINALITY syntax
> for SRFs), I had the idea of allowing "WITH WHEN CLAUSE" at the end of
> the returning list, which adds an integer column to the list, whose
> value is set to the index of the
On Sat, 31 Dec 2022 at 16:47, Corey Huinker wrote:
>
>> I wonder if there is value in setting up a psql on/off var
>> SHELL_ERROR_OUTPUT construct that when set to "off/false"
>> suppresses standard error via appending "2> /dev/null" (or "2> nul" if
>> #ifdef WIN32). At the very least, it would
On Wed, 28 Dec 2022 at 08:07, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> Most backend code doesn't actually need the variable-length data types
> support (TOAST support) in postgres.h. So I figured we could try to put
> it into a separate header file. That makes postgres.h
On Tue, 27 Dec 2022 at 10:54, Jelte Fennema
wrote:
This change makes it much easier to have a certain database
> administrator peer or cert authentication, that allows connecting as
> any user. Without this change you would need to add a line to
> pg_ident.conf for every user that is in the
On Sun, 18 Dec 2022 at 23:30, Tom Lane wrote:
> Andrey Borodin writes:
> > I saw a thread in a social network[0] about GROUP BY ALL. The idea seems
> useful.
>
> Isn't that just a nonstandard spelling of SELECT DISTINCT?
>
In a pure relational system, yes; but since Postgres allows duplicate
On Wed, 14 Dec 2022 at 15:57, Jeff Davis wrote:
> On Wed, 2022-12-14 at 15:32 -0500, Isaac Morland wrote:
>
> > Is there a firm decision on the issue of changing the cluster index
> > of a table? Re-clustering a table on the same index is clearly
> > something that shoul
On Wed, 14 Dec 2022 at 14:47, Jeff Davis wrote:
Furthermore, MAINTAIN privileges on the partitioned table do not grant
> the ability to create new partitions. There's a comment in tablecmds.c
> alluding to a possible "UNDER" privilege:
>
> /*
>* We should have an UNDER permission flag for
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
> enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
> all aggregates would have 'a' but I am thinking that a lot of them could
> be switched to 'f'.
On Thu, 8 Dec 2022 at 00:07, Nathan Bossart
wrote:
> On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote:
> > For what it's worth, I wouldn't bother changing the format of the
> > permission bits to expand the pool of available bits.
>
> 7b37823 expanded AclMode
On Wed, 7 Dec 2022 at 23:25, Tom Lane wrote:
> Nathan Bossart writes:
> > I haven't formed an opinion on whether VACUUM FULL should get its own
> bit,
> > but FWIW І just finished writing the first draft of a patch set to add
> bits
> > for CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX. I
On Mon, 5 Dec 2022 at 22:52, Vik Fearing wrote:
> On 12/5/22 20:31, Corey Huinker wrote:
> >
> > Adding to the pile of wanted aggregates: in the past I've lobbied for
> > only_value() which is like first_value() but it raises an error on
> > encountering a second value.
>
> I have had use for
On Wed, 30 Nov 2022 at 17:35, 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.
It might
I'm encountering some surprising (to me) behaviour related to WAL, and I'm
wondering if anybody can point me at an article that might help me
understand what is happening, or give a brief explanation.
I'm trying to make a slimmed down version of my database for testing
purposes. As part of this,
On Tue, 20 Sept 2022 at 06:56, Alvaro Herrera
wrote:
The NULL checks would still be mostly done by the attnotnull checks
> internally, so there shouldn't be too much of a difference.
>
> .. though I'm now wondering if there's additional overhead from checking
> the constraint twice on each row:
On Mon, 19 Sept 2022 at 09:32, Robert Haas wrote:
> On Wed, Aug 17, 2022 at 2:12 PM Alvaro Herrera
> wrote:
> > If you say CREATE TABLE (a int NOT NULL), you'll get a CHECK constraint
> > printed by psql: (this is a bit more noisy that previously and it
> > changes a lot of regression tests
On Sat, 10 Sept 2022 at 19:18, Robert Haas wrote:
If I encountered this syntax in a vacuum, that's not what I would
> think. I would think that ADD ALL TABLES IN SCHEMA meant add all the
> tables in the schema to the publication one by one as individual
> objects, i.e. add the tables that are
On Thu, 1 Sept 2022 at 19:39, Tom Lane wrote:
This code was mine originally (336969e49), but I sure don't
> remember why I wrote it like that. I know we didn't have a
> robust version of canonicalize_path() then, and that may have
> been the main issue, but that offhand comment about mount
>
On Tue, 23 Aug 2022 at 05:29, Greg Stark wrote:
> Having this function would be great (I admit I never responded because
> I never figured out if your suggestion was right or not:). But should
> it also be added to the pg_stat_activity view? Perhaps even just in
> the SQL view using the
On Wed, 20 Jul 2022 at 16:08, Bruce Momjian wrote:
> On Tue, Jul 19, 2022 at 01:41:44PM -0400, Bruce Momjian wrote:
> > I am going to look at moving system views that make sense into the
> > chapters where their contents are mentioned. I don't think having a
> > central list of views is really
On Wed, 13 Jul 2022 at 09:15, Aleksander Alekseev
wrote:
I can confirm the bug exists in the `master` branch as well and
> doesn't depend on the platform.
>
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
On Thu, 30 Jun 2022 at 21:22, Michael Paquier wrote:
> On Thu, Jun 30, 2022 at 08:57:04AM -0400, Isaac Morland wrote:
> > I was going to point out that pg_database_owner is the same way, but it
> is
> > fundamentally different in that it has no special allowed acces
On Thu, 30 Jun 2022 at 08:48, Robert Haas wrote:
Almost all of these are verbs or verb phrases: having this role gives
> you the ability to read all data, or write all data, or read all
> settings, or whatever. But you can't say that having this role gives
> you the ability to checkpointer. It
On Tue, 28 Jun 2022 at 00:32, Julien Rouhaud wrote:
> As to forcing SQL-complaint queries, that ship sailed a long time ago:
> > Postgres allows but does not enforce the use of SQL-compliant queries,
> and
> > many of its important features are extensions anyway, so forcing SQL
> > compliant
On Tue, 28 Jun 2022 at 05:32, Julien Rouhaud wrote:
> I think that supporting at least a way to specify the logical order during
> the
> table creation should be easy to implement (there shouldn't be any
> question on whether it needs to invalidate any cache or what lock level to
> use), and
On Mon, 27 Jun 2022 at 11:12, Julien Rouhaud wrote:
> More generally, I'm -0.5 on the feature.
> I prefer to force using SQL-compliant queries, and also not take bad
> habits.
>
As to forcing SQL-complaint queries, that ship sailed a long time ago:
Postgres allows but does not enforce the use
On Mon, 20 Jun 2022 at 11:01, Tom Lane wrote:
> Alvaro Herrera writes:
>
> If I were coding it, I would allow only exactly 1 digit (%.Nt) to simplify
> the parsing side of things and bound the required buffer size. Without
> having written it, it's not clear to me whether further restricting
On Fri, 22 Apr 2022 at 13:44, Tom Lane wrote:
> There is zero security concern for non-SECURITY-DEFINER functions,
> since they do nothing callers couldn't do for themselves. For those,
> you typically do want to grant out permissions. As for SECURITY DEFINER
> functions, there is no reason
On Sat, 26 Mar 2022 at 12:24, Andres Freund wrote:
> NULL can never be part of the same "array object" or one past past the last
> element as the pointer it is subtracted from. Hence the undefined beaviour.
>
Even more fundamentally, NULL is not 0 in any ordinary mathematical sense,
even
On Mon, 27 Dec 2021 at 10:20, Joel Jacobson wrote:
> Foreign key constraint names have been given the same names as the
> referenced tables.
>
While I agree this could be a simple approach in many real cases for having
easy to understand FK constraint names, I wonder if for illustration and
On Mon, 27 Dec 2021 at 03:22, Joel Jacobson wrote:
> However, I see one problem with leaving out the key columns:
> First, there is only one FK in permission pointing to role, and we write a
> query leaving out the key columns.
> Then, another different FK in permission pointing to role is
On Sun, 26 Dec 2021 at 16:24, Joel Jacobson wrote:
> I think if we combine the ON KEY ... TO ... part of my idea, with your
> idea, we have a complete neat solution.
>
> Maybe we can make them a little more similar syntax wise though.
>
> Could you accept "ON KEY" instead of "FOREIGN KEY" for
On Sun, 26 Dec 2021 at 14:37, Joel Jacobson wrote:
> Let's look at each row your example and see if we can work it out.
> I've added the "FROM permission p" and also "AS [table alias]",
> otherwise the aliases you use won't exist.
>
> > FROM permission p
>
> This row is obviously OK. We now
On Sun, 26 Dec 2021 at 01:47, Joel Jacobson wrote:
> On Sat, Dec 25, 2021, at 21:55, Joel Jacobson wrote:
> > FROM permission p
> > LEFT JOIN role r WITH p->permission_role_id_fkey = r
> > LEFT JOIN team_role tr WITH tr->team_role_role_id_fkey = r
> > LEFT JOIN team t WITH
On Tue, 23 Nov 2021 at 09:44, Chapman Flack wrote:
> On 11/23/21 02:29, Ilya Anfimov wrote:
> > (*We
> > strangely don't have an absolute value operator on interval, but
> > I think you've got the point*).
>
> Although tangential to the topic, that might be because a PG interval
> is a triple
On Thu, 11 Nov 2021 at 16:08, Robert Haas wrote:
> On Thu, Nov 11, 2021 at 3:45 PM Isaac Morland
> wrote:
> > There is however one kind of change at least that I think can be made
> safely: adding a new character in between existing characters. That
> shouldn't affect an
On Thu, 11 Nov 2021 at 14:42, Robert Haas wrote:
> diacritical marks. I know I've seen collation changes on Macs that
> changed the order in which en_US.UTF8 strings sorted. But it wasn't
> that the rules about English sorting have actually changed. It was
> that somebody somewhere decided that
On Fri, 5 Nov 2021 at 05:21, Daniel Gustafsson wrote:
> > Same reasoning as for all the other if exists we have, idempotence.
> Being able to run the command on an object that is already in the desired
> state without provoking an error.
>
> If the object is known to be in the desired state,
On Thu, 4 Nov 2021 at 08:08, Daniel Gustafsson wrote:
> > On 26 Sep 2021, at 19:58, Isaac Morland wrote:
>
> > So I think I will prepare a revised patch that uses this formulation;
> and if I still have any suggestions that aren't directly related to adding
> abs(interval)
1 - 100 of 232 matches
Mail list logo
