On Wed, 2 Dec 2020 at 19:33, David G. Johnston
wrote:
> On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote:
>
>> I think the ideal solution is to create a section for all the rename
>> cases and do all the redirects to that page. The page would list the
>> old and new name for each item, and wo
On Wed, 30 Dec 2020 at 15:00, Tom Lane wrote:
> In the third place,
> I believe the vast majority of users don't invoke initdb "by hand"
> anymore. The typical scenario is to go through a packager-provided
> script, which almost certainly won't offer access to these additional
> options.
I ca
I have long maintained permissions in my databases by having a script which
assigns all the permissions. I have tended to start with invocations
something like this:
REVOKE ALL ON ALL TABLES IN SCHEMA ... FROM ...;
... where the appropriate schemas and roles are listed. This is intended to
ensure
On Fri, 1 Jan 2021 at 11:44, Tom Lane wrote:
> Isaac Morland writes:
> > Is it safe and valid to reset to default permissions by doing
> > UPDATE pg_namespace/pg_class/pg_type/pg_proc
> > SET nspacl/relacl/typacl/proacl = NULL WHERE ... to accomplish this?
>
> Not t
On Sun, 3 Jan 2021 at 05:57, Simon Riggs
wrote:
> Exactly what's wrong with "REVOKE ALL ON ALL TABLES IN SCHEMA test" at
> the top of your script? You say there is a problem, but don't describe
> the precise problem. Can you give a fully worked example so we can
> understand how to resolve?
>
T
On Mon, 4 Jan 2021 at 10:12, Andrew Dunstan wrote:
>
> On 1/1/21 11:44 AM, Tom Lane wrote:
> > Isaac Morland writes:
> >> Is it safe and valid to reset to default permissions by doing
> >> UPDATE pg_namespace/pg_class/pg_type/pg_proc
> >> SET nspacl/r
I was trying to use triggers, and ran into something I hadn't realized
until now: triggers run, not as the owner of the table, but as the user who
is doing the insert/update/delete.
It seems to me that for a lot of the suggested uses of triggers this is not
the desired behaviour. For example, in t
On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
> The SQL standard defines a function called TRIM_ARRAY that surprisingly
> has syntax that looks like a function! So I implemented it using a thin
> wrapper around our array slice syntax. It is literally just ($1)[1:$2].
>
> An interesting case
On Fri, 12 Feb 2021 at 12:58, Tom Lane wrote:
> Isaac Morland writes:
> > I was trying to use triggers, and ran into something I hadn't realized
> > until now: triggers run, not as the owner of the table, but as the user
> who
> > is doing the insert/update/delet
On Tue, 2 Mar 2021 at 00:06, Joel Jacobson wrote:
> I find it strange two ranges of zero-length with different bounds are
> considered equal:
>
> SELECT '[7,7)'::int4range = '[8,8)'::int4range;
> ?column?
> --
> t
> (1 row)
>
> This seems like a bug to me. What am I missing here?
>
> Unle
On Tue, 2 Mar 2021 at 00:52, Joel Jacobson wrote:
> Ranges are treated as sets. As such equality is defined by membership.
>
> That being said, I agree that there may be situations in which it would be
> convenient to have empty ranges at specific locations. Doing this would
> introduce numerous
On Tue, 2 Mar 2021 at 08:58, Joel Jacobson wrote:
> If we stipulate that the result array will be in order, then you still
> don’t have the exact location of empty matches but you do at least have
> where they are relative to non-empty matches.
>
>
> This part I didn't fully understand. Can you p
On Thu, 4 Mar 2021 at 01:25, Joel Jacobson wrote:
Suggestion #1: Use [] as the canonical form for discrete types.
> This would allow creating ranges for all values for discrete types.
>
I won't reiterate here, but there are fundamental reasons why [) is
definitely the right default and canonical
On Sun, 1 Nov 2020 at 15:47, Tom Lane wrote:
> Anyway, this saves about 3KB in fmgrtab.o, without any downside
> that I can see. If someone accidentally called an aggregate as
> a normal function, they'd now get a different error message,
> namely "internal function "aggregate_dummy" is not in
On Mon, 2 Nov 2020 at 09:21, Tom Lane wrote:
> Isaac Morland writes:
>
> > Speaking as somebody who sometimes does really dumb things, I don’t like
> > this change in error message. The current message clearly identifies the
> > problem; the new message makes it loo
On Thu, 5 Nov 2020 at 08:34, Euler Taveira
wrote:
Is the database name important for this message? You should inform which
> database you want to connect for all client tools except pg_dumpall.
> Hence, you
> already know which database has the connection problem. IMO the pg_dumpall
> message sho
On Thu, 12 Nov 2020 at 22:31, Craig Ringer
wrote:
> I maintain that simply vanishing terms from the docs without any sort of
> explanation is a user-hostile action that we should fix and stop doing If
> we had something in the docs and we remove it, it's not unduly burdensome
> to have some inde
On Thu, 12 Nov 2020 at 22:40, Bruce Momjian wrote:
Because at a certain point the number of _old_ names in the docs
> obscures exactly how to operate the current software. We have tried
> keeping stuff around, and we are very bad at removing stuff.
>
This is a good point, but does not attempt t
On Tue, 19 Jan 2021 at 11:38, David Fetter wrote:
> You bring up an excellent point, which is that our builtin functions
> could use a lot more documentation directly to hand than they now
> have. For example, there's a lot of needless ambiguity created by
> function comments which leave it up i
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 tr->team_ro
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 have
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 yo
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 later
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
exp
On a newly set up system there are 7 types with a unary minus operator
defined, but only 6 of them have an abs function:
postgres=# \df abs
List of functions
Schema | Name | Result data type | Argument data types | Type
+--+--+-
On Tue, 30 Mar 2021 at 14:30, Joel Jacobson wrote:
If the expression ends with a column_name,
> you get the value for the column.
>
> If the expression ends with a constraint_name,
> you get the referenced table as a record.
>
Can’t you just leave off the “ends with a column_name” part? If you w
On Tue, 30 Mar 2021 at 15:33, Joel Jacobson wrote:
> Also, should the join be a left join, which would therefore return a NULL
> when there is no matching record? Or could we have a variation such as ->?
> to give a left join (NULL when no matching record) with -> using an inner
> join (record is
I've built Postgres inside a Ubuntu Vagrant VM. When I try to "make check",
I get a complaint about the permissions on the data directory:
[]
pg_regress: initdb failed
Examine /vagrant/src/test/regress/log/initdb.log for the reason.
Command was: "initdb" -D "/vagrant/src/test/regress/./tmp_che
On Tue, 30 Mar 2021 at 18:39, Tom Lane wrote:
> Isaac Morland writes:
> > I've built Postgres inside a Ubuntu Vagrant VM. When I try to "make
> check",
> > I get a complaint about the permissions on the data directory:
>
[]
> Further up in ini
I've attached a patch for this. Turns out there was a comment in the source
explaining that there is no interval_abs because it's not clear what to
return; but I think it's clear that if i is an interval the larger of i and
-i should be considered to be the absolute value, the same as would be done
On Wed, 31 Mar 2021 at 15:32, Joel Jacobson wrote:
> On Wed, Mar 31, 2021, at 19:16, Julien Rouhaud wrote:
>
> On Wed, Mar 31, 2021 at 5:19 PM Joel Jacobson wrote:
> >
> > If using the -> notation, you would only need to manually
> > inspect the tables involved in the remaining JOINs;
> > since
On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> RLS policies quals/checks are optimized inline, and so I generally avoid
> writing a separate procedure so the optimizer can do it's thing.
>
> However, if you need a security definer to avoid recursive RLS if you're
> doing a more complex query say
On Fri, 2 Apr 2021 at 09:30, Stephen Frost wrote:
> Greetings,
>
> * Isaac Morland (isaac.morl...@gmail.com) wrote:
> > On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> > > RLS policies quals/checks are optimized inline, and so I generally
> avoid
> > >
On Fri, 2 Apr 2021 at 09:44, Chapman Flack wrote:
> On 04/02/21 09:09, Isaac Morland wrote:
> > If we're going to do this we should do the same for triggers as well.
> >
> > ... it's easy to imagine a situation in which a trigger needs to
> > write to another
On Fri, 2 Apr 2021 at 21:08, Zhihong Yu wrote:
> Hi,
> I got a local build with second patch where:
>
> yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
> interval '0.7 years';
> ?column?
> --
> 1 mon
>
> I think the outcome is a bit unintuitive (I would
On Fri, 28 Aug 2020 at 08:43, Stephen Frost wrote:
> This would simply REVOKE that role from the user. Privileges
> independently GRANT'd directly to the user wouldn't be affected. Nor
> would other role membership.
>
> > What privileges would the user be left with? Would it be possible to end
On Fri, 28 Aug 2020 at 08:54, Stephen Frost wrote:
>
> Yes, it's the latter. I'm not really sure about the documentation
> change you're contemplating- have a specific suggestion?
>
Sorry, I was discussing this as if it was an abstract idea, not a concrete
patch. I've just taken a look at the p
On Mon, 11 Oct 2021 at 11:01, Stephen Frost wrote:
> Having an ability to GRANT predefined roles within a particular database
> is certainly something that I'd considered when adding the pg_read/write
> data roles. I'm not super thrilled with the idea of adding a column to
> pg_auth_members jus
On Mon, 11 Oct 2021 at 19:35, Mark Dilger
wrote:
> But since we allow tables and schemas with dotted names in them, I'm
> uncertain what \d foo.bar.baz is really asking.
>
FWIW, it’s absolutely clear to me that "." is a special character which has
to be quoted in order to be in an identifier.
On Thu, 14 Oct 2021 at 07:17, Gilles Darold wrote:
> The user defined columns are always visible in the PostgreSQL. If user
> wants to hide some column(s) from a SELECT * returned values then the
> hidden columns feature is useful. Hidden column can always be used and
> returned by explicitly re
On Thu, 14 Oct 2021 at 09:11, Robert Haas wrote:
>
> According to https://www.postgresql.org/docs/current/sql-createview.html
> it always works like that: "Access to tables referenced in the view is
> determined by permissions of the view owner. In some cases, this can
> be used to provide secure
On Thu, 14 Oct 2021 at 13:43, Stephen Frost wrote:
> I feel this might relate to the discussion of triggers, which I claim
> > should execute in the context of the table owner (or maybe the trigger
> > owner, if that were a separate concept). There are lots of triggers one
> > might want to write
On Sun, 17 Oct 2021 at 17:42, Gilles Darold wrote:
> Yes, my first though was to allow all columns to be unexpandable like a
> table without column, but the the problem is that when you execute
> "SELECT * FROM nada" it returns no rows which is not the case of a table
> with hidden column. I cou
On Tue, 19 Oct 2021 at 16:12, David Christensen <
david.christen...@crunchydata.com> wrote:
> Greetings -hackers,
>
> Enclosed is a patch that implements CREATE ROLE IF NOT EXISTS (along with
> the same support for USER/GROUP). This is a fairly straightforward
> approach in that we do no validati
On Tue, 2 Nov 2021 at 18:14, Vik Fearing wrote:
> On 11/2/21 4:06 PM, Robert Haas wrote:
> > There's bound to be somebody who wants to grant some of
> > these permissions and not others, or who wants to grant the ability to
> > run those commands on some tables but not others.
> Is there anything
On Tue, 2 Nov 2021 at 19:00, Vik Fearing wrote:
> On 11/2/21 11:14 PM, Vik Fearing wrote:
>
> > This would be nice, but there is nothing to hang our hat on:
> >
> > GRANT CHECKPOINT TO username;
>
> Thinking about this more, why don't we just add CHECKPOINT and
> NOCHECKPOINT attributes to ro
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(inter
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, the
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 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 affe
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 of
On 28 March 2018 at 15:43, Joshua D. Drake wrote:
> On 03/28/2018 12:35 PM, David G. Johnston wrote:
>
> I like to call it "Character Separated Values" now for just that reason.
>
>
> Isn't the actual wording Character Delimited Values? I may be picking at
> hairs here but every single time I use
Thanks for taking the time to look at this. I think I was unclear in a
couple of places so I think my proposal may have appeared worse than it is.
Details below:
On 18 March 2018 at 20:25, Tom Lane wrote:
> Isaac Morland writes:
> > The original idea was to allow access to REFRESH MAT
rote:
> On Wed, Mar 28, 2018 at 6:38 PM, Isaac Morland
> wrote:
>
>>
>> One question I would have is: what proposals exist or have existed for
>> additional privilege bits? How much pressure is there to use some of the
>> remaining bits? I actually looked into
On 31 March 2018 at 04:33, Fabien COELHO wrote:
>
> Bonjour Daniel,
>
> For csv, Fabien and Peter expressed the opinion that we shouldn't
>> create another fieldsep-like variable specifically for it, but instead
>> reuse fieldsep. That's what my latest patch does.
>>
>> Now it turns out that shar
If we're going to open this up, can we add an option to say "this key is
allowed to log in to this account", SSH style?
I like the idea of using keys rather than .pgpass, but I like the
~/.ssh/authorized_keys model and don't like the "set up an entire
certificate infrastructure" approach.
On Thu,
On Thu, 19 Sep 2019 at 12:26, Isaac Morland wrote:
> If we're going to open this up, can we add an option to say "this key is
> allowed to log in to this account", SSH style?
>
> I like the idea of using keys rather than .pgpass, but I like the
> ~/.ssh/authorized
On Wed, 25 Sep 2019 at 13:55, Žiga Kranjec wrote:
>
> Ah. I missed that bit in the documentation!
>
> Perhaps a publication should remember, whether it actually created a
> replication slot and only try to remove it, if it did. Although that
> probably wouldn't help much in your case.
>
What abo
On Tue, 1 Oct 2019 at 03:55, Smith, Peter
wrote:
> Typical Example:
> Before:
> Datum values[Natts_pg_attribute];
> boolnulls[Natts_pg_attribute];
> ...
> memset(values, 0, sizeof(values));
> memset(nulls, false, sizeof(nulls));
> Aft
On Wed, 2 Oct 2019 at 11:34, Joe Nelson wrote:
> Isaac Morland wrote:
> > I hope you'll forgive a noob question. Why does the "After"
> > initialization for the boolean array have {0} rather than {false}?
>
> I think using a value other than {0} potentially g
On Mon, 7 Oct 2019 at 03:15, Anders Åstrand wrote:
> Hello
>
> Attached is a patch for adding uri as an encoding option for
> encode/decode. It uses what's called "percent-encoding" in rfc3986
> (https://tools.ietf.org/html/rfc3986#section-2.1).
>
> The background for this patch is that I could e
On Sat, 19 Oct 2019 at 10:53, Andrew Dunstan
wrote:
>
> > In general, I'm not opposed to accepting and ignoring the MATERIALIZED
> > syntax (assuming we'd only accept AS MATERIALIZED, but not the negative
> > variant).
> >
> > FWIW I'm not sure the "we don't want to upgrade application code at th
On Sat, 19 Oct 2019 at 13:36, Stephen Frost wrote:
> Greetings,
>
> * Isaac Morland (isaac.morl...@gmail.com) wrote:
> > That embeds a temporary hack in the application code indefinitely.
>
> ... one could argue the same about having to say AS MATERIALIZED.
>
I think
On Sun, 20 Oct 2019 at 08:32, Andrew Dunstan
wrote:
>
> Understood. I think the real question here is what it should do instead
> when the value is NULL. Your behaviour above is one suggestion, which I
> personally find intuitive. Another has been to remove the associated
> key. Another is to ret
On Mon, 21 Oct 2019 at 11:46, Chapman Flack wrote:
>
> I would favor {} in a heartbeat if it were standard, because that
> sucker is an idiom.
>
> Failing that, though, I think I still favor the macro, because
> question (1) seems less fuzzy than question (2), and on "clear",
> the macro wins.
>
On Fri, 2 Aug 2019 at 16:49, Tom Lane wrote:
> Peter Geoghegan writes:
> > I've taken your patch, and changed the wording a bit. I think that
> > it's worth being a bit more explicit. The attached revision produces
> > output that looks like this:
>
> > Patches should use a more-or-less consecut
Here's a radical suggestion: replace postgresql.auto.conf with a directory
containing multiple files. Each file is named after a configuration
parameter, and its content is the value of the parameter.
So to remove a special configuration parameter, delete its file. To set it,
write the file, repla
I'm looking at https://www.postgresql.org/docs/current/sql-analyze.html,
where it says “Without a table_and_columns list, ANALYZE processes every
table and materialized view in the current database that the current user
has permission to analyze.”.
I don’t believe there is a separate “analyze” per
On Wed, 7 Aug 2019 at 17:31, David G. Johnston
wrote:
> On Wed, Aug 7, 2019 at 2:14 PM Isaac Morland
> wrote:
>
>> I'm looking at https://www.postgresql.org/docs/current/sql-analyze.html,
>> where it says “Without a table_and_columns list, ANALYZE processes every
>
On Mon, 28 Oct 2019 at 07:39, Eugen Konkov wrote:
If we should follow this form, then IS DISTINCT should be written as:
> x =! y
> This looks unusual, because JavaScript also follow != form. so I hope
> it will be easy to detect/implement != form, which I used to read as:
> negate the result of
On Tue, 29 Oct 2019 at 07:05, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-10-29 11:47, Vik Fearing wrote:
> > When joining tables with USING, the listed columns are merged and no
> > longer belong to either the left or the right side. That means they can
> > no longer be
On Thu, 31 Oct 2019 at 14:50, Stephen Frost wrote:
> Greetings,
>
> * Peter Geoghegan (p...@bowt.ie) wrote:
>
[]
>
> Absolutely- our lack of such is a common point of issue when folks are
> considering using or migrating to PostgreSQL.
>
Not sure how similar my situation really is, but I fi
On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera
wrote:
Per https://no-colors.org (thanks for the link) it seems pretty clear
>
https://no-color.org
On Fri, 17 Jan 2020 at 17:52, Bruce Momjian wrote:
> I assume there is enough agreement that decades start on 20X0 that we
> don't need to document that Postgres does that.
>
I think the inconsistency between years, decades, centuries, and millenia
is worthy of documentation. In fact, it alread
I just want to be on record that I don't think there is a problem here that
needs to be solved. The choice to put Postgres-related binaries in /usr/bin
or wherever is a distribution/packaging decision. As has been pointed out,
if I download, build, and install Postgres, the binaries by default go
i
timetzrange is also missing. In my database I have:
CREATE TYPE timerange AS RANGE (SUBTYPE = time);
COMMENT ON TYPE timerange IS 'range of times without time zone';
GRANT USAGE ON TYPE timerange TO PUBLIC;
CREATE TYPE timetzrange AS RANGE (SUBTYPE = timetz);
COMMENT ON TYPE timetzrange IS 'range
On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
> I'm also trying to figure out why it makes sense to support an 8k
> password and if we've really tried seeing what happens if pg_authid gets
> a toast table that's actually used for passwords...
>
pg_authid.rolpassword stores a hash, so the p
On Sun, 21 Oct 2018 at 14:18, Paul A Jungwirth
wrote:
> Also, just how strictly do we have to follow the standard? Requiring
> sentinels like '01 JAN 3000` just seems so silly. Could Postgres
> permit nullable start/end PERIOD columns, and give them the same
> meaning as ranges (unbounded)? Even
In many cases, it is handy to be able to specify an option in an alias, but
still be able to override on the actual command line.
I can't say whether that is useful with this specific option, but it seems
the same debate could be had about almost any option. I'm pretty sure the
existing behaviour
On Tue, 6 Nov 2018 at 14:07, Jonah H. Harris wrote:
> Two options presented:
>
> - Hard patch removes FATAL/PANIC from client_message_level_options in
> guc.c, which also seems to make sense in regard to it's double-usage
> with trace_recovery_messages.
>
> - Soft patch keeps FATAL/PANIC in clien
> I think having a bin/pg_logparse tool that can parse postgres' config
> file and attempt to parse the log contents in whatever format they are
> would be much much more useful. Obviously not every log_line_prefix can
> be parsed unambiguously, but a lot of formats can, and a lot more
> formats ca
I am trying to develop a small proof-of-concept patch for a proposal I
have, but recently I found that initdb started segfaulting after I did a
git pull. I used git bisect and it identified the following commit as the
first one with the problem:
1733460f0205fc6d6bbe4c14911049a918c6e073 is the firs
365)
sh: line 1: 45094 Abort trap: 6 "/usr/local/pgsql/bin/postgres"
--single -F -O -j -c search_path=pg_catalog -c exit_on_error=true template1
> /dev/null
child process exited with exit code 134
initdb: removing data directory "./test/pgdata"
I hope this i
On 18 March 2018 at 05:57, Alvaro Herrera wrote:
> Isaac Morland wrote:
> > OK, I must have done something wrong with the bisect the first time. Now
> > I'm getting the following as the problem commit:
> >
> > fd1a421fe66173fb9b85d3fe150afde8e812cbe4 is the first
This is a proposal for a Postgres feature enhancement. I've attached a
preliminary patch. However, the patch is extremely preliminary: there is no
documentation or testing change, and I think I actually want to make the
change itself in a different way from what this 2-line patch does.
Right now I
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 enti
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 a
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
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 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 e
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 oth
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"
>
> So
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'. In
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 t
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 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 ro
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 datab
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 mo
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 a
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
1 - 100 of 259 matches
Mail list logo
