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); //
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 reasons
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
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
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,
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
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
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
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
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
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
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 ...
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
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.
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,
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
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
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
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
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
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-jsonpath-base-20
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.
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
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
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 node is be
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
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,
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
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
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,
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
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
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, -1, Invalid
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 inserted
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
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
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
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
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):
+ /*
+*
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
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
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
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
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
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
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
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
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.
> *
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' entry ahead
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
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
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
>
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
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
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
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
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.
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
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
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
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
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
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 has a table
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
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
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
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/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 only
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,
On 02/16/22 14:58, Andres Freund wrote:
>> "The minimum required version is Python 3.2 or
>> later."
>
> I stared for a bit, and I just don't see the redundancy?
"minimum ... or later" maybe?
Regards,
-Chap
On 02/14/22 11:43, Robert Haas wrote:
> On Mon, Feb 14, 2022 at 10:38 AM Tom Lane wrote:
>> Robert Haas writes:
>>> I don't particularly like Chapman's solution,
> ... and (3) is an attempt at compromise that is nobody's first choice.
Ok, I guess that's )sniffle( a pretty fair way of putting
On 02/13/22 15:48, Tom Lane wrote:
> much fix any worries there. Or we could provide APIs that let an
> extension look up a "struct config_generic *" once and then fetch
> directly using that pointer. (But I'd prefer not to, since it'd
> constrain the internals more than I think is wise.)
There
On 02/13/22 15:16, Tom Lane wrote:
> That seems like about 10X more complexity than is warranted,
> not only in terms of the infrastructure required, but also in
> the intellectual complexity around "just when could that value
> change?"
>
> Why not just provide equivalents to GetConfigOption()
Hi,
On 02/13/22 02:29, Julien Rouhaud wrote:
> Maybe we could have an actually usable GUC API to retrieve values in their
> native format rather than C string for instance, that we could make sure also
> works for cases like max_backend?
I proposed a sketch of such an API for discussion back in
On 02/07/22 15:14, Chapman Flack wrote:
> It has since occurred to me that another benefit of having a
> transform_validator per PL would be immediate error reporting
> if someone, for whatever reason, tries out CREATE TRANSFORM
> for a PL that doesn't grok transforms.
The same could
Hi!
On 02/07/22 00:59, Böszörményi Zoltán wrote:
> UPDATE ... WHERE OFFSET n IN cursor;
If added to UPDATE, should this be added to DELETE also?
Regards,
-Chap
On 10/05/21 14:00, Chapman Flack wrote:
> On 10/05/21 13:47, Tom Lane wrote:
>>> An alternative I've sometimes used elsewhere is to typedef the function
>>> type itself, and use the * when declaring a pointer to it:
>>> typedef void Furbinator(char *furbee);
&
On 02/07/22 10:59, Peter Eisentraut wrote:
> On 05.02.22 00:55, Chapman Flack wrote:
>> I'm thinking plhandler.sgml is the only place that really needs to be
>> ...
>> worth mentioning there, though, that it isn't possible to develop
>> transforms for an arbitrar
Hi,
On 01/20/22 14:33, Ilaria Battiston wrote:
> Unsurprisingly, we'll need to have an Ideas page again, so I've gone ahead
> and created one (copying last year's):
>
> https://wiki.postgresql.org/wiki/GSoC_2022
I've added a project idea about the ongoing PL/Java refactoring.
Regards,
-Chap
Hi,
It looks to me as if the transforms feature for PLs was added in
cac7658, and support was added to plperl and plpython at that time,
with documentation added for CREATE FUNCTION, CREATE/DROP TRANSFORM,
and the catalogs, but nothing was added at that time to plhandler.sgml
to clarify that a PL
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
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
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
... 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
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
1 - 100 of 561 matches
Mail list logo
