On 09/09/24 13:00, Robert Haas wrote:
> I don't agree with this reponse at all. It seems entirely reasonable
> for third-party code to want to have a way to construct and interpret
> numeric datums. Keeping the details private would MAYBE make sense if
> the internal details were changing release t
On 07/27/24 00:32, Tom Lane wrote:
> Interval typmods include a fractional-seconds-precision field as well
> as a bitmask indicating the allowed interval fields (per the SQL
> standard's weird syntax such as INTERVAL DAY TO SECOND). Looking at
> the source code for intervaltypmodout() might be hel
On 07/15/24 10:46, Chapman Flack wrote:
> Ah, I may have mistaken which functions the patch meant to apply to.
> ...
> Any choice to use similar argument names in the regexp_* functions would
> be a matter of consistency with the analogous ISO functions, not anything
> mandated.
O
On 07/15/24 08:02, jian he wrote:
> also address Chapman Flack point:
> correct me if i am wrong, but i don't think the ISO standard mandates
> function argument names.
> So we can choose the best function argument name for our purpose?
Ah, I may have mistaken which functions t
On 06/20/24 10:54, David E. Wheeler wrote:
> Still not sure about `24:00:00` as a time, though. I presume the jsonpath
> standard disallows it.
In 9075-2 9.46 "SQL/JSON path language: syntax and semantics", the behavior
of the .time() and .time_tz() and similar item methods defers to the
behavior
On 06/18/24 08:30, Peter Eisentraut wrote:
> Are you saying we shouldn't allow .boolean() to be called on a JSON number?
>
> I would concur that that's what the spec says.
Or, if we want to extend the spec and allow .boolean() on a JSON number,
should it just check that the number is nonzero or z
On 06/17/24 19:17, David E. Wheeler wrote:
> [1]:
> https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059
Huh, I just saw something peculiar, skimming through the code:
https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_
On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that’s the key: There’s not a difference between the behavior of
> `like_regex` and `starts with` vs other predicate expressions.
The current implementation seems to have made each of our
s responsible for swallowing its own errors, which
is
Hi,
On 06/17/24 02:43, Amit Langote wrote:
> context_item expression can be a value of
> any type that can be cast to jsonb. This includes types
> such as char, text, bpchar,
> character varying, and bytea (with
> ENCODING UTF8), as well as any domains over these types.
Reading this message in c
Hi,
On 06/17/24 02:20, Amit Langote wrote:
>>>Apparently, the functions expect JSONB so that a cast is implied
>>>when providing TEXT. However, the errors during that cast are
>>>not subject to the ON ERROR clause.
>>>
>>>17beta1=# SELECT JSON_QUERY('invalid', '$' NULL ON ERROR);
>
On 06/15/24 10:47, David E. Wheeler wrote:
> these are predicate check expressions, supported and documented
> as an extension to the standard since Postgres 12[1].
> ...
> [1]:
> https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS
I see. Yes, that docume
On 06/14/24 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we
egin with, both of those path queries should have been rejected at
the parsing stage, just like the one David Johnson pointed out:
On 06/13/24 22:14, David G. Johnston wrote:
> On Thursday, June 13, 2024, Chapman Flack wrote:
>> On 06/13/24 21:46, David G. Johnston wrote:
>>>>>
On 06/14/24 10:39, David E. Wheeler wrote:
> Cited that bit in the commit message in the attached patch (also available as
> a GitHub PR[1]).
>
> [1]: https://github.com/theory/postgres/pull/5
I would s/extepsions/exceptions/ in the added documentation. :)
Offhand (as GitHub PRs aren't really T
On 06/13/24 22:16, David E. Wheeler wrote:
> But even inside filters I don’t understand why &&, ||, at least,
> currently only work if their operands are predicate expressions.
> Seems weird; and your notes above suggest that rule applies only to !,
> which makes slightly more sense.
It's baked ri
On 06/13/24 21:46, David G. Johnston wrote:
>>> david=# select jsonb_path_query('1', '$ >= 1');
>>
>> Good point. I can't either. No way I can see to parse that as
>> a .
>
> Whether we note it as non-standard or not is an open question then, but it
> does work and opens up a documentation questio
On 06/13/24 18:45, David E. Wheeler wrote:
> On Jun 13, 2024, at 3:53 PM, Andrew Dunstan wrote:
>
>> Hmm. You might be right. Many of these items have this code, but the
>> string() branch does not:
>> if (unwrap && JsonbType(jb) == jbvArray)
>>return executeItemUnwrapTargetArray(cxt, jsp, j
On 06/13/24 21:24, David G. Johnston wrote:
> I'm content that the operators in the 'filter operators' table need to be
> within filter but then I cannot reconcile why this example worked:
>
> david=# select jsonb_path_query('1', '$ >= 1');
Good point. I can't either. No way I can see to parse th
On 06/13/24 16:43, David E. Wheeler wrote:
> Paging Mr. Eisentraut!
I'm not Mr. Eisentraut, but I have at last talked my way into some
access to the standard, so ...
Note 487 emphasizes that JSON path predicates "are not expressions;
instead they form a separate language that can only be invoked
On 05/20/24 11:39, Tomas Vondra wrote:
> On 5/20/24 16:37, Sushrut Shivaswamy wrote:
>> I've tried various types and none of them read the correct value.
>> ```
>> ...
>> double current_time = DatumGetFloat8(current_timestamp); // prints 0
>>
>> int64 time = DatumGetUint64(current_timestamp); // pr
On 05/15/24 15:31, Robert Haas wrote:
> On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote:
>> What would be wrong with [occurrence], for consistency's sake?
>
> It was proposed and rejected upthread, but that's not to say that I
> necessarily endorse the reaso
On 05/15/24 15:07, Robert Haas wrote:
> is. I believe that if I were reading the documentation, count would be
> clearer to me than N, N would probably still be clear enough, and
> replace_at wouldn't be clear at all. I'd expect replace_at to be a
> character position or something, not an occurrenc
On 05/15/24 13:45, Tom Lane wrote:
> if we tell people to write
>
>PG_MODULE_MAGIC;
>#undef TEXTDOMAIN
>#define TEXTDOMAIN PG_TEXTDOMAIN("hstore")
>
> then that's 100% backwards compatible and they don't need any
> version-testing ifdef's.
OT for this thread, but related: supposing o
On 05/15/24 11:50, Tom Lane wrote:
> Hmm, cute idea, but it'd only help for extensions that are
> NLS-enabled. Which I bet is a tiny fraction of the population.
> So far as I can find, we don't even document how to set up
> TEXTDOMAIN for an extension --- you have to cargo-cult the
But I'd bet, w
On 05/13/24 09:35, aa wrote:
> If you call the action of "sifting" ordering, then yes. If you don't call
> it ordering, then no.
One thing seems intriguing about this idea: normally, an expected
property of any ORDER BY is that no result row can be passed down
the pipe until all input rows have b
Hi hackers,
More or less by chance, I stumbled on a Security Technical Implementation
Guide (STIG, promulgated by the US Dept. of Defense, Defense Information
Systems Agency) for PostgreSQL (specific to PG 9.x, so a bit dated).
There is a rule in the STIG that pertains to PLs, and seems to get
ba
Hi Rahul,
On 03/18/24 15:52, Rahul Uniyal wrote:
> Since the column format is text and not binary it converts the value
> to BigDecimal and give back the value as 40 .
> ...
> Now since the format is Binary ... it returns DOUBLE from there
> result in 40.0
>
> Now i am not sure for the same tabl
list.
Regards,
Chapman Flack
Adding this comment via the CF app so it isn't lost, while an
improperly-interpreted-DKIM-headers issue is still preventing me from mailing
directly to -hackers.
It was my view that the patch was getting close by the end of the last
commitfest, but still contained a bit of a logic wart made nec
On 2023-10-04 16:38, Jeff Davis wrote:
On Wed, 2023-10-04 at 14:02 -0400, Chapman Flack 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
Is there a use case for that? UTF-8 is
On 2023-10-04 12:19, Jim Jones wrote:
On 04.10.23 11:39, vignesh C wrote:
1) Why the default option was chosen without comments shouldn't it be
the other way round?
I'm not sure it is the way to go. The main idea is to check if two
documents have the same content, and comments might be differen
On 2023-10-04 13:47, Robert Haas wrote:
On Wed, Oct 4, 2023 at 1:27 PM Nico Williams
wrote:
A UTEXT type would be helpful for specifying that the text must be
Unicode (in which transform?) even if the character data encoding for
the database is not UTF-8.
That's actually pretty thorny ... bec
On 2023-09-21 20:38, Andy Fan wrote:
insert into tb select '{"a": "foo", "b": 1}';
...
select cast(a->'a' as numeric) from tb;
ERRCODE_INVALID_PARAMETER_VALUE cannot cast jsonb string to type
numeric
...
select cast(a->'b' as int2) from tb;
NUMERIC_VALUE_OUT_OF_RANGE smallint out of ra
Hi,
This came up in [0] and opinions besides my own would be welcome.
There is a function cannotCastJsonbValue in jsonb.c, and it throws
errors
of this form:
ERRCODE_INVALID_PARAMETER_VALUE "cannot cast jsonb %1$s to type %2$s"
where %1 is one of the possible JsonbValue types (null, string,
On 2023-09-17 21:58, David G. Johnston wrote:
ambiguity possible when doing that though:
create type "interval second" as (x int, y int);
select to_regtype('interval second'); --> interval
Not ambiguity really: that composite type you just made was named
with a single , which is one token. (Al
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
the presence of a syntax error is wrong.
Well, the situation is a little weirder than that, becaus
Hi,
At one time 12 years ago, fn_collation was stored in FmgrInfo,
with a comment saying it was really "parse-time-determined
information about the arguments, rather than about the function
itself" but saying "it's convenient" to store it in FmgrInfo
rather than in FunctionCallInfoData.
But in d
On 2023-09-04 10:35, Andy Fan wrote:
v13 attached. Changes includes:
1. fix the bug Jian provides.
2. reduce more code duplication without DirectFunctionCall.
3. add the overlooked jsonb_path_query and jsonb_path_query_first as
candidates
Apologies for the delay. I like the way this is
On 2023-09-11 12:28, jacktby jacktby wrote:
2023年9月11日 23:51，Aleksander Alekseev 写道：
often better) add a corresponding extension to /contrib/. You can find
a complete example here [1] for instance, see v4-0001 patch and the
function pg_get_relation_publishing_info(). Make sure it has a proper
vo
On 2023-09-01 09:25, John Naylor wrote:
On Fri, Sep 1, 2023 at 7:48 PM Jelte Fennema
wrote:
The C standard says:
> When a value is stored in an object of structure or union type,
> including in a member object, the bytes of the object representation that
> correspond to any padding bytes take u
On 2023-08-31 20:50, Vik Fearing wrote:
— An SQL/JSON item is defined recursively as any of the following:
...
• An SQL/JSON array, defined as an ordered list of zero or more
SQL/JSON items, called the SQL/JSON elements of the SQL/JSON
array.
...
— An SQL/JSON sequence is an o
On 2023-08-30 12:28, Alvaro Herrera wrote:
Yeah, I think the experience of the SQL committee with XML was pretty
bad, as you carefully documented. I hope they don't make such a mess
with JSON.
I guess the SQL committee was taken by surprise after basing something
on Infoset and XPath 1.0 for 2
On 2023-08-30 11:18, Chapman Flack wrote:
If I look in [1], am I looking in the right place for the most
current jsonpath draft?
My bad, I see that it is not. Um if I look in [1'], am I then looking
at the same spec you are?
[1'] https://www.ietf.org/archive/id/draft-ietf-jsonpa
Hi,
On 2023-08-29 03:05, Jeevan Chalke wrote:
This commit implements jsonpath .bigint(), .integer(), and .number()
---
This commit implements jsonpath .date(), .time(), .time_tz(),
.timestamp(), .timestamp_tz() methods.
---
This commit implements jsonpath .boolean() and .string() methods.
Writ
On 2023-08-30 00:47, Andy Fan wrote:
see what it is. Suppose the original query is:
numeric(jsonb_object_field(v_jsonb, text)) -> numeric.
...
However the declared type of jsonb_object_field_type is:
jsonb_object_field_type(internal, jsonb, text) -> internal.
So the situation is: b). We retu
Hi,
Although this is a ten-year-old message, it was the one I found quickly
when looking to see what the current state of play on this might be.
On 2013-09-20 14:22, Robert Haas wrote:
Hmm. So under that design, a database could support up to a total of
two character sets, the one that you get
On 2023-08-22 08:16, Chapman Flack wrote:
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel
On 2023-08-26 16:00, Pavel Stehule wrote:
Saxon can be an interesting library, but nobody knows if integration
with
Postgres is possible. Their C implementation is Java compiled/executed
by GraalV.
Indeed, such an integration would probably not be in core.
Of the two possible-ways-forward des
On 2023-08-26 13:02, Alvaro Herrera wrote:
Sadly, all the projects seem to have been pretty much abandoned in the
meantime. Zorba has been dead for 9 years, xqilla for 6. Even XQC,
the
API they claim to implement, is dead.
Sounds like bad news for the "XQC as integration point" proposal,
a
On 2023-08-25 10:49, Vik Fearing wrote:
I do not think this should be addressed in this patch because
there are quite a lot of functions that need to handle this.
Indeed, as described in [0], we still largely provide the SQL/XML:2003
notion of a single XML datatype, not the distinguishable XML(
On 2023-08-24 11:23, Jonathan S. Katz wrote:
SELECT $1::int + $2::int \bind 1 2 \g
One cast also works, letting type inference figure out the other.
So if I say
SELECT $1::int + $2 \gdesc
it tells me the result will be int. That made me wonder if there is
a \gdesc variant to issue the "state
On 2023-08-24 10:07, Maxim Orlov wrote:
1) Why do I need to specify the number of elements in the list in the
function name?
This is reminding me of something someone (Tom?) worked on sort of
recently.
Ah, yes:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1cff1b9
I wasn't
On 2023-08-22 01:54, Andy Fan wrote:
After we label it, we will get error like this:
select (a->'a')::int4 from m;
ERROR: cannot display a value of type internal
Without looking in depth right now, I would double-check
what relabel node is being applied at the result. The idea,
of course, was
On 2023-08-20 21:31, Andy Fan wrote:
Highlighting the user case of makeRelableType is interesting! But using
the Oid directly looks more promising for this question IMO, it looks
like:
"you said we can put anything in this arg, so I put an OID const
here",
seems nothing is wrong.
Perhaps on
Hi,
Thread [1] concerns (generalizing slightly) the efficient casting
to an SQL type of the result of a jsonb extracting operation
(array indexing, object keying, path evaluation) that has ended
with a scalar JsonbValue.
So far, it can efficiently rewrite casts to boolean or numeric
types.
I no
On 2023-08-18 15:08, Chapman Flack wrote:
But I don't know that adding relabel nodes wouldn't still be
the civilized thing to do.
Interestingly, when I relabel both places, like this:
Oid targetOid = fexpr->funcresulttype;
Const *target = makeConst(
OIDOID, -
On 2023-08-18 14:50, Chapman Flack wrote:
Now, my guess is EXPLAIN is complaining when it sees the Const
of type internal, and doesn't know how to show that value.
Perhaps makeRelabelType is the answer there, too: what if the
Const has Oid type, so EXPLAIN can show it, and what's inser
On 2023-08-18 03:41, Andy Fan wrote:
I just have
a quick hack on this, and crash happens at the simplest case.
If I build from this patch, this test:
SELECT (test_json -> 0)::int4, test_json -> 0 FROM test_jsonb WHERE
json_type = 'scalarint';
fails like this:
Program received signal SIGSEG
On 2023-08-17 21:14, Andy Fan wrote:
The idea of an 'internal' return type with no 'internal' parameter
was quickly and rightly shot down.
Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:
Well, the reason "internal return ty
On 2023-08-17 05:07, Andy Fan wrote:
Thanks for the review, v9 attached!
From the earliest iterations of this patch, I seem to recall
a couple of designs being considered:
In one, the type-specific cast function would only be internally
usable, would take a type oid as an extra parameter (sup
On 2023-08-14 03:06, Andy Fan wrote:
We'd still have functions like jsonb_field_as_numeric() under the
hood, but there's not an expectation that users call them explicitly.
To avoid the lots of functions like jsonb_field_as_int2/int4, I defined
Datum jsonb_object_field_type(.., Oid target_oid)
On 2023-08-14 09:11, Erik Rijkers wrote:
, '$' returning date[]
I certainly like that syntax better.
It's not that the "here's a null to tell you the type I want"
is terribly unclear, but it seems not to be an idiom I have
seen a lot of in PostgreSQL before now. Are there other places
it's c
Hi,
Looking at the most recent patch, so far I have a minor
spelling point, and a question (which I have not personally
explored).
The minor spelling point, the word 'field' has been spelled
'filed' throughout this comment (just as in the email subject):
+ /*
+* Si
On 2023-08-03 23:55, Andy Fan wrote:
> The double quotes look weird to me. but it looks like a common
> situation.
>
> select numeric('1'::int); -- failed.
> select "numeric"('1'::int); -- ok.
It arises when you have an object (type, function, cast, whatever) whose
name in the catalog is the sa
On 2023-08-03 03:53, Andy Fan wrote:
I didn't realize timetime types are binary compatible with SQL,
so maybe we can have some similar optimization as well.
(It is a pity that timestamp(tz) are not binary, or else we may
just need one operator).
Not to veer from the thread, but something about
On 2023-08-01 07:58, Julien Rouhaud wrote:
On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote:
Hi, I’m trying to develop a new grammar for pg
It's unclear to me whether you want to entirely replace the flex/bison
parser
with something else or just add some new bison rule.
Or express a
On 2023-07-14 18:22, David G. Johnston wrote:
For PostgreSQL this is even moreso (i.e, huge means count > 1) since
the
order of rows in the returning clause is not promised to be related to
the
order of the rows as seen in the supplied insert command. A manual
insert
returning should ask for n
On 2023-07-14 17:31, Chapman Flack wrote:
So when getGeneratedKeys was later added, a way of getting a ResultSet
after an executeUpdate, did they consciously intend it to come under
the jurisdiction of existing apidoc that concerned the fetch size of
a ResultSet you wanted from executeQuery
On 2023-07-14 17:02, Dave Cramer wrote:
The fly in the ointment here is when they setFetchSize and we decide to
use a Portal under the covers.
A person might language-lawyer about whether setFetchSize even applies
to the kind of thing done with executeUpdate.
Hmm ... the apidoc for setFetchSiz
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
v4 looks good to me.
I don't think this requires any documentation c
On 03/27/21 08:57, Andrew Dunstan wrote:
> We can bikeshed the name of the flag at some stage. --procedures-only
> might also make sense
Any takers for --routines-only ?
"Routine" is the genuine, ISO SQL umbrella term for a function or
procedure, and we have used it that way in our docs and gloss
On 03/11/22 22:18, Paul Jungwirth wrote:
> Arg, fixed.
>
>> In range_agg_transfn, you've changed the message in the "must be called
>> with a range or multirange"; that seems like another good candidate to
>> be an elog.
>
> Agreed. Updated here.
This looks good to me and passes installcheck-wor
On 03/10/22 19:38, Nathan Bossart wrote:
> On Thu, Mar 10, 2022 at 07:13:14PM -0500, Chapman Flack wrote:
>> +postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
>
> Ah, good catch. I made this change in v7. I considered doing something
v7 looks good to me.
On 03/09/22 19:06, Nathan Bossart wrote:
> Done. I went ahead and added "label => 'label'" for consistency.
Looks like this change to an example in func.sgml is not quite right:
-postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
+postgres=# SELECT * FROM pg_walfile_name_offset(p
On 03/02/22 15:12, Mark Wong wrote:
> I've attached v2, which reduces the output:
>
> * Removing the notices for the text body, and the "compile" message.
> * Replaced the notice for "compile" message with a comment as a
> placeholder for where a compiling code or checking a cache may go.
> * R
On 03/05/22 15:53, Paul Jungwirth wrote:
> On 3/1/22 13:33, Chapman Flack wrote:
>> I think the 4 lines should suffice, but it looks like this patch was
>> generated from a rebase of the old one (with three lines) that ended up
>> putting the new 'range_agg' en
On 02/26/22 03:27, Joel Jacobson wrote:
> On Fri, Feb 25, 2022, at 22:12, Chapman Flack wrote:
>> I would be happy to review this patch, but a look through the email leaves me
>> thinking it may still be waiting on a C implementation of pg_get_acl(). Is
>> that
>> right
On 03/09/22 17:21, Nathan Bossart wrote:
> Great. Is there any additional feedback on this patch? Should we add an
> example of using pg_basebackup in the "Standalone Hot Backups" section, or
> should we leave all documentation additions like this for Chap's new
> thread?
I'm composing something
On 03/09/22 12:19, Stephen Frost wrote:
> Let's avoid hijacking this thread, which is about this
> patch, for an independent debate about what our documentation should or
> shouldn't include.
Agreed. New thread here:
https://www.postgresql.org/message-id/6228FFE4.3050309%40anastigmatix.net
Regar
On 03/09/22 12:19, Stephen Frost wrote:
> Let's avoid hijacking [thread about other patch] [1]
> for an independent debate about what our documentation should or
> shouldn't include.
Agreed. New thread here.
Stephen wrote:
> Documenting everything that pg_basebackup does to make sure that the
> b
On 03/09/22 11:22, Magnus Hagander wrote:
>> It's more than just too confusing, it's actively bad because people will
>> actually use it and then end up with backups that don't work.
>
> +1.
>
> Or even worse, backups that sometimes work, but not reliably and not
> every time.
> ...
> Pretending
On 03/08/22 17:12, Nathan Bossart wrote:
> I spent some time trying to come up with a workable script to replace the
> existing one. I think the main problem is that you need to write out both
> the backup label file and the tablespace map file, but I didn't find an
> easy way to write the differe
On 03/03/22 16:40, Tom Lane wrote:
> The point is to make it clear that the macro isn't intended to affect
> code outside the function. Since C lacks block-scoped macros,
> there's no other way to do that.
>
> I concede that a lot of our code is pretty sloppy about this, but
> that doesn't make i
On 03/01/22 20:03, Nathan Bossart wrote:
> Here is a new version of the patch with the following changes:
I did not notice this earlier (sorry), but there seems to remain in
backup.sgml a programlisting example that shows a psql invocation
for pg_backup_start, then a tar command, then another psql
On 03/02/22 12:46, Brar Piening wrote:
> With regard to varlistentry I'd suggest to decide whether to add ids or
> not on a case by case base. I already offered to add ids to long lists
> upon request but I wouldn't want to blindly add ~4k ids that nobody
Perhaps there are a bunch of variablelists
On 03/02/22 02:46, Michael Paquier wrote:
> system function marked as proretset while it builds and returns only
> one record. And this is a popular one: pg_stop_backup(), labelled
> v2.
I had just recently noticed that while reviewing [0], but shrugged,
as I didn't know what the history was.
Is
On 02/28/22 23:31, Paul Jungwirth wrote:
> On 2/26/22 17:13, Chapman Flack wrote:
>> (I think generating
>> the patch with 4 lines of context would be enough to keep that from being
>> a recurring issue.)
>
> Thank you for the review and the tip re 4 lines of context
On 03/01/22 14:50, Brar Piening wrote:
> TBH I don't like the visual representation of the unicode link symbol
> (U+1F517) in my browser. It's a bold black fat thing that doesn't
> inherit colors. I've tried to soften it by decreasing the size but that
> doesn't really solve it for me. Font support
On 03/01/22 14:14, Stephen Frost wrote:
>> There can't really be many teams out there thinking "we'll just ignore
>> these scripts forever, and nothing bad will happen." They all know they'll
>> have to do stuff sometimes. But it matters how we allow them to schedule it.
>
> We only make these cha
On 03/01/22 13:22, David Steele wrote:
> I think people are going to complain no matter what. If scripts are being
> maintained changing the name is not a big deal (though moving from exclusive
> to non-exclusive may be). If they aren't being maintained then they'll just
> blow up a few versions do
On 03/01/22 12:32, Nathan Bossart wrote:
> On Tue, Mar 01, 2022 at 11:09:13AM -0500, Chapman Flack wrote:
>> That way, at least, there would be a period of time where procedures
>> that currently work (by passing exclusive => false) would continue to work,
>> and could be
On 03/01/22 09:44, David Steele wrote:
> Personally, I am in favor of removing it. We change/rename
> functions/tables/views when we need to, and this happens in almost every
> release.
For clarification, is that a suggestion to remove the 'exclusive' parameter
in some later release, after using t
On 02/28/22 10:19, Tom Lane wrote:
>> That will standardize the
>> way to fetch real typed values in libpq. That leads to the next
>> question. Do we need to introduce different PQget*value() for standard
>> C/SQL data types.
>
> ... I do not want to go here. Where would you stop? How would you
On 02/28/22 14:41, Brar Piening wrote:
> Attached is an extended version of the patch that changes the XSL and
> CSS stylesheets to add links to the ids that are visible when hovering.
That works nicely over here.
I think that in other recent examples I've seen, there might be
(something like a)
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
This applies (with some fuzz) and passes installcheck-world, but a re
On 02/26/22 11:48, Chapman Flack wrote:
> This patch applies cleanly for me and passes installcheck-world.
> I have not yet studied all of the changes in detail.
I've now looked through the rest, and the only further thing I noticed
was that xlog.c's do_pg_start_backup still h
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
This patch applies cleanly for me and passes installcheck-world.
I ha
I would be happy to review this patch, but a look through the email leaves me
thinking it may still be waiting on a C implementation of pg_get_acl(). Is that
right? And perhaps a view rename to pg_privileges, following Peter's comment?
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
This patch is straightforward, does what it says, and passes the test
On 02/24/22 19:52, Kyotaro Horiguchi wrote:
> FWIW in that perspecive, there's no requirement from me that it should
> be human-readable. I'm fine with automatically-generated ids.
One thing I would be −many on, though, would be automatically-generated ids
that are not, somehow, stable. I've been
1 - 100 of 594 matches
Mail list logo
