Hi,
On 02/21/22 11:11, Simon Riggs wrote:
> This patch seeks to change the situation for the better in PG15, i.e.
> soon, so the changes proposed are deliberately light. It also seeks to
> provide a framework that writers of background worker processes can
> follow, since we can't just fix core, w
On 02/07/22 15:14, Chapman Flack wrote:
> I'll work on some doc patches.
It seems a bit of an impedance mismatch that there is a get_func_trftypes
producing a C Oid[] (with its length returned separately), while
get_transform_fromsql and get_transform_tosql both expect a List.
There is
On 02/21/22 16:09, Chapman Flack wrote:
> On 02/07/22 15:14, Chapman Flack wrote:
>> I'll work on some doc patches.
>
> It seems a bit of an impedance mismatch that there is a get_func_trftypes
> producing a C Oid[] (with its length returned separately), while
>
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
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
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 applies cleanly for me and passes installcheck-world.
I ha
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 applies (with some fuzz) and passes installcheck-world, but a re
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)
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 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 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 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 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 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 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/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 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/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/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/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/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/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 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 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 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/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 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/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/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/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 11/30/20 22:38, Laurenz Albe wrote:
> I have been annoyed about this myself, and I have heard other prople
> complain about it, so I propose to clear the query buffer if the
> editor exits without modifying the file.
Or how about keeping the query buffer content unchanged, but not
executing it
On 12/01/20 11:21, Laurenz Albe wrote:
> On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote:
>>> complain about it, so I propose to clear the query buffer if the
>>> editor exits without modifying the file.
>>
>> Or how about keeping the query buffer content u
>> po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule
>> napsal:
>>> I checked this and it is "prefix backslash-u hex" used by Java,
>>> JavaScript or RTF -
>>> https://billposer.org/Software/ListOfRepresentations.html
If I look on that page, it appears that RTF is using a similar-looking
escape b
On 12/01/20 17:19, Patrick Handja wrote:
> Just figured out. I think I can use RANGE_EMPTY and it will be like:
>
>> typcache =range_get_typcache(fcinfo, RangeTypeGetOid(RANGE_EMPTY));
Are you sure you are not simply looking for
range_get_typcache(fcinfo, INT4RANGEOID) ?
Top-posting is not used
On 12/02/20 05:37, Pavel Stehule wrote:
> 2. there can be optional parameter "prefix" with default "\". But with "\u"
> it can be compatible with Java or Python.
Java's unicode escape form is one of those early ones that lack
a six-digit form, and where any character outside of the basic multiling
On 12/02/20 09:55, Chapman Flack wrote:
> In Perl, there is a useful extension to regexp substitution where
> you specify the replacement not as a string or even a string with &
> and \1 \2 ... magic, but as essentially a lambda that is passed the
> match and returns a computed r
On 12/02/20 16:51, David Steele wrote:
> Depending on how you have Github organized migrating to travis-ci.com may be
> bit tricky because it requires full access to all private repositories in
> your account and orgs administrated by your account.
PL/Java just began using travis-ci.com this summe
On 12/11/20 12:21, Tom Lane wrote:
> solution I adopted was just to invent a new CoercionContext value
> COERCION_PLPGSQL, representing "use pl/pgsql's rules". (Basically
> what that means nowadays is to apply CoerceViaIO if assignment cast
> lookup doesn't find a cast pathway.)
That seems like a
On 12/17/20 14:28, Tom Lane wrote:
> Pavel Stehule writes:
>> n int;
>> v varchar;
>> js jsonb default '{"n": 100, "v" : "Hello"};
>> BEGIN
>> n := js['n'];
>> v := js['v'];
>
> If you're imagining that js['n'] and js['v'] would emit different
> datatypes, forget it. That would require
On 12/17/20 15:50, Tom Lane wrote:
> Chapman Flack writes:
>> On 12/17/20 14:28, Tom Lane wrote:
>>> If you're imagining that js['n'] and js['v'] would emit different
>>> datatypes, forget it. That would require knowing at parse time
>>&
On 12/17/20 16:47, Tom Lane wrote:
> As far as "treat as" is concerned, we already have a spelling for
> that, it's called a cast.
I find them different; XQuery was the first language I had encountered
that provides both (a cast in XQuery is spelled 'cast as', just as you'd
expect), and the idea o
On 12/17/20 16:56, Chapman Flack wrote:
>> that, it's called a cast.
>
> I find them different; XQuery was the first language I had encountered
> that provides both (a cast in XQuery is spelled 'cast as', just as you'd
> expect), and the idea of an ex
On 01/04/21 10:25, Joel Jacobson wrote:
> I just learned from a pg friend, it's possible to set your own made up
> setting_name using set_config(),
> if the setting_name contains at least one dot ".".
It works that way so you can set a config variable needed by an extension,
if necessary before t
On 01/05/21 16:14, Joel Jacobson wrote:
> or maybe even WITH like this:
>
> WITH
> year % 19 AS g ,
> year / 100 AS c,
> (c - c/4 - (8*c + 13)/25 + 19*g + 15) % 30 AS h,
> h - (h/28)*(1 - (h/28)*(29/(h + 1))*((21 - g)/11)) AS i,
> year + year/4 + i + 2 - c + c/4) % 7 AS j,
> i - j AS p
On 02/19/21 10:26, Tom Lane wrote:
>> "foo\nbar".match(/([\w\W]+)/)[1];
>> "foo
>> bar"
>
> Oooh, that's very interesting. I guess the advantage of that over using
> the 's' flag is that you can have different behaviors at different places
> in the same regex.
Perl, Python, and Java (at least)
On 03/02/21 13:01, Mark Dilger wrote:
> The problem is not just with lower() and upper(), but with equality testing
> (mentioned upthread), since code may rely on two different "positions"
> (your word) both being equal, and both sorting the same.
Could those concerns be addressed perhaps, not by
On 03/02/21 14:20, Joel Jacobson wrote:
> This would effectively mean there would be absolutely no semantic changes at
> all.
>
> I will work on a new patch to try out this idea.
I may have been assuming a degree of orthogonality in SQL that isn't
really there ... only in a few situations (like
On 03/04/21 10:40, Tom Lane wrote:
> Also, did you see
>
> https://www.postgresql.org/message-id/fc160ee0-c843-b024-29bb-97b5da61971f%40darold.net
>
> Seems like there may be some overlap in these proposals.
Not only that, the functions in that other proposal are very similar
to the standard's o
On 03/08/21 12:30, Tom Lane wrote:
> I'm inclined to think we should learn from that and provide equivalent
> variants regexp_position[s] right off the bat.
I think the s-free version is exactly the regexp_instr included in
the other concurrent proposal [1], which closely corresponds to the
ISO po
On 03/08/21 13:29, Chapman Flack wrote:
> I think the s-free version is exactly the regexp_instr included in
> the other concurrent proposal [1]
sorry.
[1]
https://www.postgresql.org/message-id/fc160ee0-c843-b024-29bb-97b5da61971f%40darold.net
On Sat, Mar 06, 2021 at 08:03:17PM +0100, Joel Jacobson wrote:
>regclass | obj_desc | grantor | grantee |
privilege_type | is_grantable
>
--+-+-+-++--
1. Is there a reason not to make 'gran
On 03/09/21 11:11, Joel Jacobson wrote:
> On Tue, Mar 9, 2021, at 07:34, Joel Jacobson wrote:
>> On Tue, Mar 9, 2021, at 04:01, Chapman Flack wrote:
>>> 1. Is there a reason not to make 'grantor' and 'grantee' of type regrole?
>
> Having digested your
On 11/17/20 15:18, Jack Christensen wrote:
>> CREATE OR REPLACE FUNCTION very_long_name(par1 int)
>> RETURNS int AS $$
>> #routine_label lnm
>> BEGIN
>> RAISE NOTICE '%', lnm.par1;
Could that be somehow shoehorned into the existing ALIAS syntax, maybe as
DECLARE
lnm ALIAS FOR ALL very_long_na
On 11/18/20 19:46, David G. Johnston wrote:
> I doubt there is any substantial resistance to including such a function
> but it would have to be written in C.
Would anything have to be written at all, save the CREATE AGGREGATE
suggested in the original message, using the existing array_cat as the
I saw in the docs for CREATE AGGREGATE, under argmode, "Aggregate functions
do not support OUT arguments".
And because I tend to poke things I'm told not to poke, I thought "but
wait, the CREATE AGGREGATE doesn't have much to say about the return type
anyway, that's just the FINALFUNC's return typ
I noticed in CI builds of PL/Java with PG 13 that -Wimplicit-fallthrough=3
in pg_config's CFLAGS was causing some switch case fallthrough warnings
after an elog(ERROR. [1]
I added my own pg_unreachable() after the elog(ERROR, ...) calls [2]
and that did away with the warnings.
But it looks odd, a
On 01/17/21 08:48, Magnus Hagander wrote:
> I've finally gotten around to putting up a
> cgit instance on our git server, to allow for browsing of the git
> repositories. You can find this at:
>
> https://git.postgresql.org/cgit/
Interesting!
Having never actively compared gitweb and cgit, what
On 02/10/21 10:15, Jonathan S. Katz wrote:
> On 2/8/21 6:11 PM, Noah Misch wrote:
>> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:
>>> Some of these issues only affect version 13, but may also apply to other
>>> supported versions.
>>
>> Did you want s/may/many/?
>
> Nope. The
On 12/02/21 16:22, Tom Lane wrote:
> ... types belonging to the STRING category, which are predicated
> on the assumption that such types are reasonably general-purpose
> string types.
This prods me to submit a question I've been incubating for a while.
Is there any way to find out, from the cata
On 12/03/21 14:12, Tom Lane wrote:
> This reminds me of something I've been intending to bring up, which
> is that the "char" type is not very encoding-safe. charout() for
> example just regurgitates the single byte as-is.
I wonder if maybe what to do about that lies downstream of some other
thou
Hi,
When SPI produces a tuple table result, its DestReceiver makes a new
"SPI TupTable" memory context, as a child of the SPI Proc context,
and the received tuples get copied into it. It goes away at SPI_finish,
as a consequence of its parent SPI Proc context going away.
If a person wanted to ref
On 12/04/21 11:34, Tom Lane wrote:
> Chapman Flack writes:
>> "I am one byte of SQL_ASCII regardless of server setting".
>
> But it's not quite that. If we treated it as SQL_ASCII, we'd refuse
> to convert it to some other encoding unless the value pa
On 12/03/21 20:22, Tom Lane wrote:
> Seems kinda dangerous to me ...
>
>> AtEOSubXact_SPI can free tuptables retail, but only in the rollback case.
>
> ... precisely because of that. If you wanted to take control of
> the TupTable, you'd really need to unhook it from the SPI context's
> tuptable
On 12/05/21 12:01, Tom Lane wrote:
> regression=# select '\'::bytea;
> ERROR: invalid input syntax for type bytea
>
> which would be incompatible with "char"'s existing behavior. But as
> long as we don't do that, I'd be okay with having high-bit-set char
> values map to backslash-followed-by-th
On 12/05/21 14:51, Tom Lane wrote:
> Uh, what?
>
> regression=# select '\n'::bytea;
> ERROR: invalid input syntax for type bytea
Wow, I was completely out to lunch there somehow. Sorry. None of those
other escaped forms are known to byteain, other than '\\' and
according to table 8.7. I can
On 12/07/21 13:32, Colin Gilbert wrote:
> I've been becoming more and more interested in learning formal methods
> and wanted to find a good project to which I could contribute. Would
> the development team appreciate someone adding ACSL annotations to the
> codebase?
My ears perked up ... I have
On 12/08/21 12:13, Colin Gilbert wrote:
> Hi! Thanks for the quick reply. Are you doing any of this work in a
> public repository? If so, could we have a link? There is a similar
> idea in Java Modelling Language. It also uses its own annotations to
> describe additional requirements. Are you cons
On 12/09/21 12:53, Colin Gilbert wrote:
> ... plugins written in
> something like Rust or Ada/SPARK? I write this, hoping not to tread on
Some work toward supporting "deep" PostgreSQL extensions in Rust
was presented at PGCon 2019 [0].
Regards,
-Chap
[0] https://www.pgcon.org/2019/schedule/even
Hi,
There are some things about the life cycle of the common TupleDesc
that I'm not 100% sure about.
1. In general, if you get one from relcache or typcache, it is
reference-counted, right?
2. The only exception I know of is if you ask the typcache for
a blessed one (RECORD+typmod), and it
On 12/14/21 18:03, Tom Lane wrote:
> Tupdescs for RECORD types are a different story: ... Refcounting
> isn't terribly necessary in that case; and at least for the shared
> tupdesc case, we don't do it, to avoid questions of modifying a
> piece of shared state.
Ok, that's kind of what I was getti
On 12/14/21 20:02, Tom Lane wrote:
> The API contract for lookup_rowtype_tupdesc specifies that you must "call
> ReleaseTupleDesc or DecrTupleDescRefCount when done using the tupdesc".
> It's safe to assume that the tupdesc will stick around as long as you
> haven't done that.
I think what threw m
On 12/15/21 11:10, David G. Johnston wrote:
>> IF NOT EXISTS(SELECT 1 FROM pg_namespace WHERE nspname = 'foo') THEN
Orthogonally to any other comments,
IF pg_catalog.to_regnamespace('foo') IS NULL THEN
might be tidier, if you don't need to support PG < 9.5.
Regards,
-Chap
On 12/15/21 17:50, Tom Lane wrote:
> Here's a draft patch for this. There are several places that are
> directly using DecrTupleDescRefCount after lookup_rowtype_tupdesc
> or equivalent, which'd now be forbidden. I think they are all safe
> given the assumption that the typcache's tupdescs for n
Hi,
I sometimes do some testing as nobody, on a distro where
getpwent(nobody)->pw_dir is a directory that nobody can't write.
So I end up setting $HOME to a directory that, um, is writable.
When I start psql, strace shows $HOME being honored when looking
for .terminfo and .inputrc, and getpwent()
On 12/18/21 15:57, Chapman Flack wrote:
> I see that I can set
> a HISTFILE variable (or set PSQL_HISTORY in the environment),
> and can set PSQLRC in the environment (but not as a variable),
> and nothing can set the .pgpass location
well, not in the psql docs, but in the environm
On 12/18/21 16:16, David G. Johnston wrote:
> psql docs saith:
>
> "This utility, like most other PostgreSQL utilities, also uses the
> environment variables supported by libpq (see Section 34.15)."
I'm sure that's adequate as far as that goes. I just happened to miss it
when composing the longer
On 12/20/21 09:15, Peter Eisentraut wrote:
> On 18.12.21 21:57, Chapman Flack wrote:
>> When I start psql, strace shows $HOME being honored when looking
>> for .terminfo and .inputrc, and getpwent()->pw_dir being used
>> to look for .pgpass, .psqlrc, and .psql_history, w
... ok, I see that the answer is yes, according to the commit comment
for eccfef8:
Currently, ICU-provided collations can only be explicitly named
collations. The global database locales are still always libc-provided.
I got there the long way, by first wondering how to tell whether a
datcol
On 12/02/21 16:22, Tom Lane wrote:
> taking the special types out of the string category, so 0002
> attached invents a separate TYPCATEGORY_INTERNAL category to
> put them in.
On the same general topic, was there a deliberate choice to put
inet and cidr in TYPCATEGORY_NETWORK but macaddr and macad
On 01/03/22 13:55, Tom Lane wrote:
> I do see an argument against reclassifying macaddr[8] into
> TYPCATEGORY_NETWORK now: we generally expect that if a
> category has a preferred type, any member type of the category
> can be cast to that preferred type.
I was wondering about the details of how t
On 01/03/22 17:23, Ed Behn wrote:
> However, I get a compiler error when I try to access procStruct->proargmodes.
> I know that this is because this field is in the CATALOG_VARLEN block which
> makes it invisible to the compiler.
>
> What is the proper way to get this field?
You can use SysCacheG
t; regexp_count(), regexp_instr(), regexp_substr() and regexp_replace() as
>>> reported by Chapman Flack in [2]. All these function are implemented in
>>> [v2-0001-xquery-regexp-functions.patch]
I quickly looked over this patch preparing to object if it actually
purported to implement
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 table which should not be accessible to the role using the
> table which has the trigger.
Trigger
On 04/02/21 16:46, Joel Jacobson wrote:
> __ ___
> /)/ /
> ( / ___)
> (/ o) ( o) )
>_ (_ )) /
>/_/)_/
> / //| |\
> v | | v
> __/
Slonik's backslashes are falling off. Eww.
Regards,
-Chap
On 04/03/21 01:20, Joel Jacobson wrote:
> I've deployed the fix to production:
>
> $ psql -U brad -h pit.org motd
>
> NOTICE:
> __ ___
> /)/ \/ \
> ( / ___\)
> \(/ o) ( o) )
>\_ (_ ) \ ) /
> \ /\_/\)_/
> \/ //| |\\
>
On 04/03/21 14:24, Joel Jacobson wrote:
> Thanks for noticing.
> I've updated the ascii art now using the version from swisspug.org,
> does it look correct now to you?
>
> $ psql -U brad -h pit.org motd
>
> NOTICE:
> __ ___
> /)/ \/ \
> ( / ___\)
> \(/ o)
On 04/09/21 08:11, Daniel Westermann (DWE) wrote:
> At least the description should mention procedures.
> Even the parameter name seems not to be correct anymore. Thoughts?
It's possible the parameter name also appears in documentation for
out-of-tree PLs, as each PL's validator function determine
On 07/01/13 20:10, Josh Kupershmidt wrote:
> I am eager to see the relative paths issue fixed, but maybe we need to
> bite the bullet and sort out the escaping of command-line options in
> the rest of pg_ctl first, so that a DataDir like "/tmp/here's a \"
> quote" can consistently be used by pg_ctl
On 08/14/20 14:50, Tom Lane wrote:
> SAVEPOINT s1;
> SET LOCAL search_path = pg_catalog, pg_temp;
> ... protected code here ...
> RELEASE SAVEPOINT s1;
>
> but this does not work because SET LOCAL persists to the end of the
> outer transaction. Maybe we could invent a vari
On 08/14/20 15:38, Tom Lane wrote:
> (3) If the SQL syntax is really just "WITH variable value [, ...]"
> then I'm afraid we're going to have a lot of parse-ambiguity problems
> with wedging full SET syntax into that. The ability for the righthand
There is precedent in the SET command for having
On 10/27/21 18:18, Arjan van de Ven wrote:
> +/*
> + * Special case each of the possible base values (8, 10, 16) to
> avoid an
> + * expensive divide operation
> + * (the compiler will use a multiply, shift or boolean ops for this)
> + */
Was 'boolean' the
Hi,
According to a reported PL/Java issue [0], SubTransactionId in
Postgres PRO EE 13 has become a typedef uint64 rather than uint32.
What are the plans for this type upstream? I notice it is still uint32
here, even for 14. Are there plans for it to become uint64 at some point?
Or to become somet
On 10/28/21 10:37, Bruce Momjian wrote:
> I know of no plans to implement 64-bit transaction ids in community
> Postgres because of the longer tuple header and file format changes.
> It is discussed occasionally though.
Is there anything you can use a SubTransactionId for outside of C code?
PL/J
Hi,
I notice, belatedly, that 141fd1b tweaked the order of some members of
struct catctup, moving c_list and my_cache from earlier locations to the
end of the struct. [0]
That resulted in this sequence at the end of the struct:
...
HeapTupleData tuple;/* tuple management header */
Hi,
This example in the docs declares a function returning an anonymous
2-component record:
CREATE FUNCTION dup(in int, out f1 int, out f2 text)
AS $$ SELECT $1, CAST($1 AS text) || ' is text' $$
LANGUAGE SQL;
The same declaration can be changed to have just one OUT parameter:
CREATE FU
On 11/22/21 11:15, Tom Lane wrote:
> Yup, that's intentional, and documented.
I think I found where it's documented; nothing under argmode/column_type
/column_name, but just enough under rettype to entail the current behavior.
> It seems more useful to allow you to declare a scalar-returning func
On 11/22/21 11:59, Pavel Stehule wrote:
> And if we allow RETURNS RECORD, then there will be new inconsistency
> between OUT variables and RETURNS TABLE
I don't really see it as a new inconsistency, so much as the same old
inconsistency but with an escape hatch if you really mean the other thing.
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 independently-signed months/days/seconds components.
An interval
1 - 100 of 622 matches
Mail list logo
