PostgreSQL Extension Project.
95 views
Skip to first unread message
Arthur Dent
Oct 16, 2021, 10:08:04 PM10/16/21
to PGXN Users
I have been trying to find active interest in development for a GPL style PostgreSQL extension, complete and available, on Sourceforge and public internet, that will support the following:
High Precision Numeric and Elementary Functions Support
In PostgreSQL v14 or beyond.
HPPM: High Precision PostgreSQL Mathematics.
-The introduction of Integer Z, or Rational Mixed Decimal Q, numbers support in 64 bit PostgreSQL. Via HPZ, and HPQ, original types. In this specification, they are collectively referred to as HPX types. These two types can be spelled in capital letters, or lower case. They are:
HPZ, HPQ or hpz, hpq.
There are also range and multirange types corresponding to both of those:
hpzrange, HPZRANGE, hpzmultirange, HPZMULTIRANGE,
hpqrange, HPQRANGE, hpqmultirange, HPQMULTIRANGE.
-The extension could be based on a library like MPIR, written in C. MPIR is an appropriate basis to use, for all targeted OS platforms for the plugin. There is already some support for this kind of mathematics, in terms of its logic, and further optimisation, publicly available already in C that can be apprehended for this extension and its PostgreSQL OS platforms.
-Real numbers are the values of Integer, non-recurring Rational Numbers and recurring, and/or Irrational Numbers. Recurring numbers can be appropriately truncated, via a finite Natural precision value, always at least 1, to obtain an approximating value. The approximating value can really be seen as a finite Rational number, possibly with Integer or Decimal parts, or both together. These numbers may be positive or negative, or zero, scalar values, and always do exist on the one dimensional number line.
-A defaulting number of significant figures (precision), will be stored inside each HPX datum or type variable or column type. This gets specified at type declaration, or around an expression or value datum, before further use. Or the defaulting precision amount is allocated. Precision can be accessed and changed, at any point, via a secondary, different variable declaration, or (another) precision function call.
Precision is set at type declaration, or from the default value. Precision is always apprehended before external or before internal evaluation begins. Precision is used to control numbers, operations involving them, and value output, when numeric manipulation occurs.
If an HPX value is data on its own, without any variable or a coded expression, it can gain the total default precision amount. If it is inserted into a table column with a different precision, then that precision is applied. When an HPX calculating expression is assigned into an HPX variable, it will have checked for (any) assignment, =, into a variable with its separate precision, before proceeding through the PostgreSQL code, value(s) and expression to the right of that assignment and correctly copying that expression inside the assigned variable. If however, an HPX value, in a PostgreSQL code expression, is sent straight into a RETURN statement or a SELECT statement, without assignment or a precision function call, or is just specified in a comparison, then that datum will contain the highest precision value out of any of the others in its PostgreSQL expression, by checking the largest one found as it is evaluation considered, from left to right, within that total expression. If nothing is set or specified, a total, separate defaulting precision value of 20 is the beginning point for all HPX data. An HPX datum can also have its precision accessed or altered via these functions:
precision(HPZ input, BIGINT input) returns HPZ;
precision(HPQ input, BIGINT input) returns HPQ;
precision(HPZ input) returns BIGINT;
precision(HPQ input) returns BIGINT;
expression(HPZ input) returns TEXT;
expression(HPQ input) returns TEXT;
-HPX values can be displayed directly. They sit on top of a few other phenomena. Forward and inverse expressions accuracy, withstanding truncation, can be achieved by distinctly storing, operating with and normalising a mathematical expression behind the data (or just one value, from sole value assignment). An expression has one or more links, from value(s) to variable(s), via applying of precision consideration or adjustment at evaluation time, internally. This system will uphold any precision, certainly ones within a very large range limit, controlled by the already available type, the BIGINT. It can enumerate digits of a frequency within the range of
-9223372036854775808 to +9223372036854775807. This is at least between negative and positive nine quintilion digit places. More than enough for the speeds of now, or maybe, tomorrow.
Naturally evaluation will slow down, or not conclude in useful time frames, before those limits, nowadays. That phenomenon can be allowed, and left to the context of the programmer to deal with or avoid as they may. They may try to minimise the extent of one internal expression by using re-substitution in the body of originating, PostgreSQL, code. If the internal expression, but mainly the multiple values set inside one HPX datum gets too large or too elaborate, there is the option to convert the output value to TEXT by casting, and to start over in terms of only one net value, by casting that value back into an HPX type again, and removing all other internal structuring. A TEXT variable or table column, or even another HPX or numeric type, if the value is in range and can operate accurately there, can be used to store digit data alone. Secondary assignments reset the expression and values buffer within an HPX variable or table column.
--At the point of PostgreSQL code input and execution:
select pi(1001) as pi;
--Within a table creation command:
create table example_table
(
id BIGSERIAL PRIMARY KEY,
a HPZ,
b HPQ(50)
);
ALTER TABLE example_table ALTER COLUMN b TYPE HPQ(60);
ALTER TABLE example_table ALTER COLUMN b TYPE HPQ(50);
INSERT INTO example_table(a,b) VALUES(0, 0.1);
INSERT INTO example_table(a,b) VALUES(100,1.1);
INSERT INTO example_table(a,b) VALUES(200,2.2);
INSERT INTO example_table(a,b) VALUES(300,3.3);
INSERT INTO example_table(a,b) VALUES(400,4.4);
INSERT INTO example_table(a,b) VALUES(500,5.5);
INSERT INTO example_table(a,b) VALUES(600,6.6);
INSERT INTO example_table(a,b) VALUES(700,7.7);
INSERT INTO example_table(a,b) VALUES(800,8.8);
INSERT INTO example_table(a,b) VALUES(900,9.9);
--Or as variables, in some function:
create or replace function example_function()
returns void
language plpgsql
as
$$
declare
a HPQ(2);
b HPQ(2);
c HPQ(3);
begin
a = 0.1;
b = 0.1;
c=a*b;
precision(c,10);
return void
end;
$$
--Range and Multirange Types or Functions or Operators.
select hpzrange(precision(0,3), precision(100,3))
&& hpzrange(precision(20,3), precision(80,3))
AS Intersecting;
select hpqrange(precision(1.5,3), precision(25.5,3))
AS Mixed_Number_Range;
-Value assignment to a typed variable by =.
-Operators. Base 10 Arithmetic and comparisons support on Base 10 HPZ and HPQ, with casting:
::,=,!=,<>,>,<,>=,<=,+,-,*,/,%,^
These include full division and integer only division (from type inference), with no remainder, and a remainder only calculating operator, within all range possibilities of the involved two values under operation. There should be automatic casting involved, upon other numeric type values, up to HPZ or HPQ, where required and appropriate (in PostgreSQL expressions).
-Reified support with broader syntax and operations within PostgreSQL. HPX integration with Tables, the between keyword, Array types, Indexing, Variables and related phenomena, the Record type, direct compatibility with the Aggregate and Window functions, and Partitions are all parts of a larger subset that should re-interact with HPZ or HPQ successfully. HPX types should also be integrated with Range Types, Multirange Types, Operators, their Functions and their Window Functions.
hpzrange, hpzmultirange
hpqrange, hpqmultirange
-Ease of installation support. Particularly for Windows and Linux. *.exe, *.msi or *.rpm, *.deb, *.bin installers.
Upon a PostgreSQL installation. Installation and Activation instructions included, if necessary for successful use for the uninitiated. The extension should literally just install and be applicable, with no loading command necessary, from inside PostgreSQL. For every time the database process is run, by default.
-Mathematical and Operational functions support:
cast(HPZ as HPQ) returns HPQ;
cast(HPQ as HPZ) returns HPZ;
cast(TEXT as HPZ) returns HPZ;
cast(TEXT as HPQ) returns HPQ;
cast(HPQ as TEXT) returns TEXT;
cast(HPZ as TEXT) returns TEXT;
cast(HPZ as SMALLINT) returns SMALLINT;
cast(SMALLINT as HPZ) returns HPZ;
cast(HPZ as INTEGER) returns INTEGER;
cast(INTEGER as HPZ) returns HPZ;
cast(HPZ as BIGINT) returns BIGINT;
cast(BIGINT as HPZ) returns HPZ;
cast(HPQ as REAL) returns REAL;
cast(REAL as HPQ) returns HPQ;
cast(DOUBLE PRECISION as HPQ) returns HPQ;
cast(HPQ as DOUBLE PRECISION) returns DOUBLE PRECISION;
cast(HPQ as DECIMAL) returns DECIMAL;
cast(DECIMAL as HPQ) returns HPQ;
cast(HPQ as NUMERIC) returns NUMERIC;
cast(NUMERIC as HPQ) returns HPQ;
sign(HPQ input) returns HPZ;
abs(HPQ input) returns HPZ;
ceil(HPQ input) returns HPZ;
floor(HPQ input) returns HPZ;
round(HPQ input) returns HPZ;
reciprocal(HPQ input) returns HPQ;
pi(BIGINT precision) returns HPQ;
e(BIGINT precision) returns HPQ;
power(HPQ base, HPQ exponent) returns HPQ;
sqrt(HPQ input) returns HPQ;
nroot(HPZ theroot, HPQ input) returns HPQ;
log10(HPQ input) returns HPQ;
ln(HPQ input) returns HPQ;
log2(HPQ input) returns HPQ;
factorial(HPZ input) returns HPZ;
nCr(HPZ objects, HPZ selectionSize) returns HPZ;
nPr(HPZ objects, HPZ selectionSize) returns HPZ;
degrees(HPQ input) returns HPQ;
radians(HPQ input) returns HPQ;
sind(HPQ input) returns HPQ;
cosd(HPQ input) returns HPQ;
tand(HPQ input) returns HPQ;
asind(HPQ input) returns HPQ;
acosd(HPQ input) returns HPQ;
atand(HPQ input) returns HPQ;
sinr(HPQ input) returns HPQ;
cosr(HPQ input) returns HPQ;
tanr(HPQ input) returns HPQ;
asinr(HPQ input) returns HPQ;
acosr(HPQ input) returns HPQ;
atanr(HPQ input) returns HPQ;
-Informative articles on all these things exist at:
PostgreSQL v14 Database Documentation:
https://www.postgresql.org/docs/14/index.html
Comparison Operators: https://en.wikipedia.org/wiki/Relational_operator
Floor and Ceiling Functions: https://en.wikipedia.org/wiki/Floor_and_ceiling_functions
Arithmetic Operations: https://en.wikipedia.org/wiki/Arithmetic
Integer Division: https://en.wikipedia.org/wiki/Division_(mathematics)#Of_integers
Modulus Operation: https://en.wikipedia.org/wiki/Modulo_operation
Rounding (Commercial Rounding): https://en.wikipedia.org/wiki/Rounding
Factorial Operation: https://en.wikipedia.org/wiki/Factorial
Degrees: https://en.wikipedia.org/wiki/Degree_(angle)
Radians: https://en.wikipedia.org/wiki/Radian
Elementary Functions: https://en.wikipedia.org/wiki/Elementary_function
Trigonometry key values and the Unit Circle:
https://courses.lumenlearning.com/boundless-algebra/chapter/trigonometric-functions-and-the-unit-circle/
The End.
High Precision Numeric and Elementary Functions Support
In PostgreSQL v14 or beyond.
HPPM: High Precision PostgreSQL Mathematics.
-The introduction of Integer Z, or Rational Mixed Decimal Q, numbers support in 64 bit PostgreSQL. Via HPZ, and HPQ, original types. In this specification, they are collectively referred to as HPX types. These two types can be spelled in capital letters, or lower case. They are:
HPZ, HPQ or hpz, hpq.
There are also range and multirange types corresponding to both of those:
hpzrange, HPZRANGE, hpzmultirange, HPZMULTIRANGE,
hpqrange, HPQRANGE, hpqmultirange, HPQMULTIRANGE.
-The extension could be based on a library like MPIR, written in C. MPIR is an appropriate basis to use, for all targeted OS platforms for the plugin. There is already some support for this kind of mathematics, in terms of its logic, and further optimisation, publicly available already in C that can be apprehended for this extension and its PostgreSQL OS platforms.
-Real numbers are the values of Integer, non-recurring Rational Numbers and recurring, and/or Irrational Numbers. Recurring numbers can be appropriately truncated, via a finite Natural precision value, always at least 1, to obtain an approximating value. The approximating value can really be seen as a finite Rational number, possibly with Integer or Decimal parts, or both together. These numbers may be positive or negative, or zero, scalar values, and always do exist on the one dimensional number line.
-A defaulting number of significant figures (precision), will be stored inside each HPX datum or type variable or column type. This gets specified at type declaration, or around an expression or value datum, before further use. Or the defaulting precision amount is allocated. Precision can be accessed and changed, at any point, via a secondary, different variable declaration, or (another) precision function call.
Precision is set at type declaration, or from the default value. Precision is always apprehended before external or before internal evaluation begins. Precision is used to control numbers, operations involving them, and value output, when numeric manipulation occurs.
If an HPX value is data on its own, without any variable or a coded expression, it can gain the total default precision amount. If it is inserted into a table column with a different precision, then that precision is applied. When an HPX calculating expression is assigned into an HPX variable, it will have checked for (any) assignment, =, into a variable with its separate precision, before proceeding through the PostgreSQL code, value(s) and expression to the right of that assignment and correctly copying that expression inside the assigned variable. If however, an HPX value, in a PostgreSQL code expression, is sent straight into a RETURN statement or a SELECT statement, without assignment or a precision function call, or is just specified in a comparison, then that datum will contain the highest precision value out of any of the others in its PostgreSQL expression, by checking the largest one found as it is evaluation considered, from left to right, within that total expression. If nothing is set or specified, a total, separate defaulting precision value of 20 is the beginning point for all HPX data. An HPX datum can also have its precision accessed or altered via these functions:
precision(HPZ input, BIGINT input) returns HPZ;
precision(HPQ input, BIGINT input) returns HPQ;
precision(HPZ input) returns BIGINT;
precision(HPQ input) returns BIGINT;
expression(HPZ input) returns TEXT;
expression(HPQ input) returns TEXT;
-HPX values can be displayed directly. They sit on top of a few other phenomena. Forward and inverse expressions accuracy, withstanding truncation, can be achieved by distinctly storing, operating with and normalising a mathematical expression behind the data (or just one value, from sole value assignment). An expression has one or more links, from value(s) to variable(s), via applying of precision consideration or adjustment at evaluation time, internally. This system will uphold any precision, certainly ones within a very large range limit, controlled by the already available type, the BIGINT. It can enumerate digits of a frequency within the range of
-9223372036854775808 to +9223372036854775807. This is at least between negative and positive nine quintilion digit places. More than enough for the speeds of now, or maybe, tomorrow.
Naturally evaluation will slow down, or not conclude in useful time frames, before those limits, nowadays. That phenomenon can be allowed, and left to the context of the programmer to deal with or avoid as they may. They may try to minimise the extent of one internal expression by using re-substitution in the body of originating, PostgreSQL, code. If the internal expression, but mainly the multiple values set inside one HPX datum gets too large or too elaborate, there is the option to convert the output value to TEXT by casting, and to start over in terms of only one net value, by casting that value back into an HPX type again, and removing all other internal structuring. A TEXT variable or table column, or even another HPX or numeric type, if the value is in range and can operate accurately there, can be used to store digit data alone. Secondary assignments reset the expression and values buffer within an HPX variable or table column.
--At the point of PostgreSQL code input and execution:
select pi(1001) as pi;
--Within a table creation command:
create table example_table
(
id BIGSERIAL PRIMARY KEY,
a HPZ,
b HPQ(50)
);
ALTER TABLE example_table ALTER COLUMN b TYPE HPQ(60);
ALTER TABLE example_table ALTER COLUMN b TYPE HPQ(50);
INSERT INTO example_table(a,b) VALUES(0, 0.1);
INSERT INTO example_table(a,b) VALUES(100,1.1);
INSERT INTO example_table(a,b) VALUES(200,2.2);
INSERT INTO example_table(a,b) VALUES(300,3.3);
INSERT INTO example_table(a,b) VALUES(400,4.4);
INSERT INTO example_table(a,b) VALUES(500,5.5);
INSERT INTO example_table(a,b) VALUES(600,6.6);
INSERT INTO example_table(a,b) VALUES(700,7.7);
INSERT INTO example_table(a,b) VALUES(800,8.8);
INSERT INTO example_table(a,b) VALUES(900,9.9);
--Or as variables, in some function:
create or replace function example_function()
returns void
language plpgsql
as
$$
declare
a HPQ(2);
b HPQ(2);
c HPQ(3);
begin
a = 0.1;
b = 0.1;
c=a*b;
precision(c,10);
return void
end;
$$
--Range and Multirange Types or Functions or Operators.
select hpzrange(precision(0,3), precision(100,3))
&& hpzrange(precision(20,3), precision(80,3))
AS Intersecting;
select hpqrange(precision(1.5,3), precision(25.5,3))
AS Mixed_Number_Range;
-Value assignment to a typed variable by =.
-Operators. Base 10 Arithmetic and comparisons support on Base 10 HPZ and HPQ, with casting:
::,=,!=,<>,>,<,>=,<=,+,-,*,/,%,^
These include full division and integer only division (from type inference), with no remainder, and a remainder only calculating operator, within all range possibilities of the involved two values under operation. There should be automatic casting involved, upon other numeric type values, up to HPZ or HPQ, where required and appropriate (in PostgreSQL expressions).
-Reified support with broader syntax and operations within PostgreSQL. HPX integration with Tables, the between keyword, Array types, Indexing, Variables and related phenomena, the Record type, direct compatibility with the Aggregate and Window functions, and Partitions are all parts of a larger subset that should re-interact with HPZ or HPQ successfully. HPX types should also be integrated with Range Types, Multirange Types, Operators, their Functions and their Window Functions.
hpzrange, hpzmultirange
hpqrange, hpqmultirange
-Ease of installation support. Particularly for Windows and Linux. *.exe, *.msi or *.rpm, *.deb, *.bin installers.
Upon a PostgreSQL installation. Installation and Activation instructions included, if necessary for successful use for the uninitiated. The extension should literally just install and be applicable, with no loading command necessary, from inside PostgreSQL. For every time the database process is run, by default.
-Mathematical and Operational functions support:
cast(HPZ as HPQ) returns HPQ;
cast(HPQ as HPZ) returns HPZ;
cast(TEXT as HPZ) returns HPZ;
cast(TEXT as HPQ) returns HPQ;
cast(HPQ as TEXT) returns TEXT;
cast(HPZ as TEXT) returns TEXT;
cast(HPZ as SMALLINT) returns SMALLINT;
cast(SMALLINT as HPZ) returns HPZ;
cast(HPZ as INTEGER) returns INTEGER;
cast(INTEGER as HPZ) returns HPZ;
cast(HPZ as BIGINT) returns BIGINT;
cast(BIGINT as HPZ) returns HPZ;
cast(HPQ as REAL) returns REAL;
cast(REAL as HPQ) returns HPQ;
cast(DOUBLE PRECISION as HPQ) returns HPQ;
cast(HPQ as DOUBLE PRECISION) returns DOUBLE PRECISION;
cast(HPQ as DECIMAL) returns DECIMAL;
cast(DECIMAL as HPQ) returns HPQ;
cast(HPQ as NUMERIC) returns NUMERIC;
cast(NUMERIC as HPQ) returns HPQ;
sign(HPQ input) returns HPZ;
abs(HPQ input) returns HPZ;
ceil(HPQ input) returns HPZ;
floor(HPQ input) returns HPZ;
round(HPQ input) returns HPZ;
reciprocal(HPQ input) returns HPQ;
pi(BIGINT precision) returns HPQ;
e(BIGINT precision) returns HPQ;
power(HPQ base, HPQ exponent) returns HPQ;
sqrt(HPQ input) returns HPQ;
nroot(HPZ theroot, HPQ input) returns HPQ;
log10(HPQ input) returns HPQ;
ln(HPQ input) returns HPQ;
log2(HPQ input) returns HPQ;
factorial(HPZ input) returns HPZ;
nCr(HPZ objects, HPZ selectionSize) returns HPZ;
nPr(HPZ objects, HPZ selectionSize) returns HPZ;
degrees(HPQ input) returns HPQ;
radians(HPQ input) returns HPQ;
sind(HPQ input) returns HPQ;
cosd(HPQ input) returns HPQ;
tand(HPQ input) returns HPQ;
asind(HPQ input) returns HPQ;
acosd(HPQ input) returns HPQ;
atand(HPQ input) returns HPQ;
sinr(HPQ input) returns HPQ;
cosr(HPQ input) returns HPQ;
tanr(HPQ input) returns HPQ;
asinr(HPQ input) returns HPQ;
acosr(HPQ input) returns HPQ;
atanr(HPQ input) returns HPQ;
-Informative articles on all these things exist at:
PostgreSQL v14 Database Documentation:
https://www.postgresql.org/docs/14/index.html
Comparison Operators: https://en.wikipedia.org/wiki/Relational_operator
Floor and Ceiling Functions: https://en.wikipedia.org/wiki/Floor_and_ceiling_functions
Arithmetic Operations: https://en.wikipedia.org/wiki/Arithmetic
Integer Division: https://en.wikipedia.org/wiki/Division_(mathematics)#Of_integers
Modulus Operation: https://en.wikipedia.org/wiki/Modulo_operation
Rounding (Commercial Rounding): https://en.wikipedia.org/wiki/Rounding
Factorial Operation: https://en.wikipedia.org/wiki/Factorial
Degrees: https://en.wikipedia.org/wiki/Degree_(angle)
Radians: https://en.wikipedia.org/wiki/Radian
Elementary Functions: https://en.wikipedia.org/wiki/Elementary_function
Trigonometry key values and the Unit Circle:
https://courses.lumenlearning.com/boundless-algebra/chapter/trigonometric-functions-and-the-unit-circle/
The End.
Pavel Stehule
Oct 17, 2021, 12:17:31 AM10/17/21
to pgxn-...@googlegroups.com
ok. This can be a nice extension.
Usually (in Postgres) who proposes a feature, he should write it. Because proposed features are just wrapped in other libraries with C API, then the code should be very simple.
Next step is publishing this extension on pgxn and on github or gitlab.
Last step is waiting if users find your extensions and if users and others try to help with development. Unfortunately it is not too often. But that is reality. This functionality can be interesting, but for very specific users. I expect so few users on the planet need high precision functionality in the database - but I am sure these people exist, because Postgres is used in universities and for research too.
The best way how to start with development of Postgres extensions is compile Postgres from source code and look to contrib directory
More times I used some extension from contrib as template for my own extension.
You can check if there is some similar extension on https://pgxn.org/ . Maybe https://pgxn.org/dist/pgmp/ or https://pgxn.org/dist/bignum/ or https://pgxn.org/dist/complex/
You can learn how it is written
I'll reply (with pleasure) to all your questions related to extension development. It is not hard work.
Nice day
Pavel
The End.
--
You received this message because you are subscribed to the Google Groups "PGXN Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pgxn-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pgxn-users/f1addfed-16e8-403b-8a2e-3937c0954ea0n%40googlegroups.com.
Zachary1234
Oct 17, 2021, 10:42:21 PM10/17/21
to PGXN Users
Dear Pavel,
Thank you for replying replying to my extension request.
-I am not in a position to program or directly contribute towards this extension, myself. I do not come from a C programming background, and cannot presently
make the time to change that. I am trying to find someone, hopefully in your own position, who could do the required programming for me, at my behest.
-Given this, are you still able to contribute to a project such as this? I am trying to keep this as a purely volunteer development project.
-Do you have access to any peers, or anyone else, who can contribute towards the work to both help you, speed things up, and even
contribute to some testing? The work involved will tend to balloon out, as one PostgreSQL capability relates to others.
-The name I have come up with for this extension is HPPM, as per the project specification. I am hoping that all the development files, i.e. source code,
resource files or build scripts can be put up on a project home page on sourceforge.
-I contribute the following development hints, which are my own software ideas as to how things could potentially be arranged, if this
is any assistance to yourself.
------------------------------------------------------------------------------------------------
High Precision Numeric and Elementary Functions Support
In PostgreSQL v13 and beyond.
HPPM: High Precision PostgreSQL Mathematics.
------------------------------------------------------------------------------------------------
A) Value, or Expression and Values.
A) The Precision value, a strictly postive integer number P, P>=1.
B) Expression Normalisation code. Per PostgreSQL external to internal expression.
B) Precision limiting, reducing and enlargement code. Per operation or call.
B) Arithmetic operation symbols and that behaviour. Per operation, value pairs, expression pairs.
B) Comparators code, casting code. Per pair or per call on a value or sub expression.
B) Functions code. Per sub expression, or per value.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A) Must be aggregated, as one whole datum, for storage.
B) Can be stored, copied and used separately. Typically because of the possible relationship of being within or from a Trigger.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-In one total datum, there is always one solution value out of the internal total expression, at a time. That can be one value,
an expression of values, with one or more functions, or it can be multivariate, yet here it will always have one scalar output value.
-If the internal expression and multiple values set inside one HPX datum gets too large or elaborate, there is the option to convert
-If the internal expression and multiple values set inside one HPX datum gets too large or elaborate, there is the option to convert
the output value to TEXT by casting, and to start over in terms of only one value, but casting that back into an HPX type again,
via what will one value assignment, or an insert.
-When do you obtain expression evaluation? When you SELECT, cast to a string, or concatenate to a string, the datum or data,
-When do you obtain expression evaluation? When you SELECT, cast to a string, or concatenate to a string, the datum or data,
or one variable thereof. Similar does apply to API access from the database.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The End.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The End.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Could you please reply by all this to this conversation here?
A.D.
Pavel Stehule
Oct 17, 2021, 11:11:45 PM10/17/21
to pgxn-...@googlegroups.com
Dear Pavel,Thank you for replying replying to my extension request.-I am not in a position to program or directly contribute towards this extension, myself. I do not come from a C programming background, and cannot presentlymake the time to change that. I am trying to find someone, hopefully in your own position, who could do the required programming for me, at my behest.-Given this, are you still able to contribute to a project such as this? I am trying to keep this as a purely volunteer development project.-Do you have access to any peers, or anyone else, who can contribute towards the work to both help you, speed things up, and evencontribute to some testing? The work involved will tend to balloon out, as one PostgreSQL capability relates to others.-The name I have come up with for this extension is HPPM, as per the project specification. I am hoping that all the development files, i.e. source code,resource files or build scripts can be put up on a project home page on sourceforge.-I contribute the following development hints, which are my own software ideas as to how things could potentially be arranged, if thisis any assistance to yourself.
I expect that almost all people here have enough work already. I am working on relatively popular projects like orafce and plpgsql_check, and I can say, there are not any volunteers in this area. Young people have no C language knowledge, and older people need to pay bills. You can try to find it, but there is a low probability of success (maybe you can cooperate with some universities and do this work as student projects), or you can pay for development.
I can help with learning of development, but I have not any capacity to work on other projects. I have to reject paid projects now. Possibly nice projects are too much, there are lot of ideas, but there are not too much people, who can do this work. If you want to help, if you want to move with your project, then learn coding, and put your time to this. It is hard work that expect lot of time. Words and proposals are cheap.
Nice day
Pavel
To view this discussion on the web visit https://groups.google.com/d/msgid/pgxn-users/a3f6e23a-d1db-4568-bedc-fbdd1bfe211cn%40googlegroups.com.
Zachary1234
Oct 17, 2021, 11:22:34 PM10/17/21
to PGXN Users
Dear Pavel,
Thank you for your response. If this is the case, don't worry about it. If you could reply back to me here with any email address(es) or similar, for someone else who is in a position
to help me, I would be more than grateful. If you, or anyone else, who reads these messages, are willing and able to help me, under the context, I would be thrilled to hear.
Is there maybe anyone else out there who can help, here?
Z.M.
Bear Giles
Oct 20, 2021, 1:11:35 PM10/20/21
to pgxn-...@googlegroups.com
I'm definitely not volunteering but I have no idea what MPIR is. I can't speak for others but when I'm developing something I'll only work with libraries that are already available in .rpm or .deb packages. (Custom repos is fine.) It's just one less thing to track - someone else is responsible for locating the upstream resource, keeping it current, etc. (Worst case I'll create my own .deb file.)
Checking the Ubuntu repo I can find plenty of MPI = message passing protocol used for node-to-node communications within supercomputers. But nothing that looks like a math library. Of course this would only work with Ubuntu - you would need to identify other packages for RedHat-based systems, to say nothing of macs and windows systems.
I also tried checking if it's an R package - as in "MPI-R" - but no luck there either.
If a library is identified the core of what you're asking for is probably just simple UDT wrapper for the C 'typedef' and UDF facade for the library functions. That's something an advanced undergrad could do with a bit of oversight. However that's just the extension - the installers etc require very different specialized skills.
But no matter what the first question to be answered is how to obtain the library(ies) you're referring to.
Bear
To view this discussion on the web visit https://groups.google.com/d/msgid/pgxn-users/54455aff-9893-44df-85df-01859f661d48n%40googlegroups.com.
Zachary1234
Oct 21, 2021, 12:32:55 AM10/21/21
to PGXN Users
The MPIR library official website is at https://mpir.org/. It is Multiple Precision Integers and Rationals.
Hopefully that helps. Bear, does that make a difference in terms of someone being able to apprehend
and complete all of my vaunted Extension, as specified?
Bear Giles
Oct 21, 2021, 9:44:52 AM10/21/21
to pgxn-...@googlegroups.com
It helps - to create a UDT you need to be able to capture the complete state of the object. It's probably not a problem with this type of object but I've worked with libraries where the objects were smeared out in a way and that level of encapsulation would be difficult. It also makes it much easier to determine whether there's an alternative library with the same functionality but a more open license or an implementation that's easier to work with. There are plenty of high precision math libraries out there but we can't assume that they're drop-in replacements. For that we need to be able to see exactly how these alternatives compare to what you've identified as a reference implementation.
...
I think you've overlooked the fact that many if not most of the people with the experience to do what you're asking for are working professionals who need to run things by their employers to make sure there's no conflict of interest. You've given us no information about what organization you work for or why they want this extension. For all I know you're a direct competitor of my employee or one of its major clients. Any contribution would be an immense conflict of interest, one that could result in my immediate termination.
We simply can't proceed without that information - and I suspect people have remained silent since they're seeing how forthcoming you are with it since that's critical information to know when evaluating possible conflicts of interest.
Worse reading between the lines it seems likely that you're trying to replace an existing commercial product with PostgreSQL, which is fine, and you need UDT and UDF to match the existing database, which is a lot more iffy since there's court cases that have held that a direct copy of an implementation is an infringement on IP rights. (E.g., 'assemblers' can't use the same symbolic opcode - if one company uses 'load' a knockoff must use something like 'lda'. That choice is considered 'creative work'. They can still produce the same output since that's beyond their control - I think the ruling used an analogy to telephone numbers where you could change things like the order of first and last names but you still had to go to the same phone number.) It doesn't matter whether or not I agree with this court ruling, or the more recent one regarding the Java API, since it's something I have to consider as a working professional. Something like the name of the UDT is exactly the type of thing that would be considered IP of an existing product since it's completely arbitrary.
The other issue for me - I don't know about other people - is that I'm a firm believer in the adage that "nothing good starts with a lie". Unless you can prove you're one of a handful of people actually named "Arthur Dent" it's a huge red flag to me. It will also be a huge red flag to my employer when evaluating whether it would be a conflict of interest for me to take on this work since they have to ask if this was an unfortunate oversight or an attempt to hide the truth about potential conflicts of interest.
So, bottom line, I'm conflicted out since even if you provide all of the information now my employer will still nix any work performed by me beyond helping you clarify your requirements. This is unfortunate since I know you might be a company looking to save some money - or you might be a university professor trying to provide opportunities to students who could never afford a license to a critical technology in their field and you're only seeking the minimum required for their education. The latter might have been acceptable if it was mentioned from the start and both I and my employer could confirm it was intended for educational use (albeit could be used commercially by others) but now there's too many questions.
Bear
To view this discussion on the web visit https://groups.google.com/d/msgid/pgxn-users/4dc67151-4734-4bc9-9ac4-91fffdddb147n%40googlegroups.com.
Zachary1234
Oct 21, 2021, 11:36:28 PM10/21/21
to PGXN Users
Okay. I have been using a pseudonym for the public internet just to preserve some anonymity for myself when dealing with people on forums.
I am Zachary Mitchell, and I live in Australia. I am simply an individual, who, for my own purposes, have found limitations
in PostgreSQL that I wish to be improved on. I am not working as a database developer, or engaged in any commercial database development
work. I would certainly not be a direct competitor with your employer, or their interests.
What I have found is that Decimal or Numeric types in Postgresql are not supported well by elementary mathematical functions.
The functions that are included require types of a smaller range, and those types are prone to floating point errors. I want PostgreSQL
to be able to run base 10 mathematics for numbers as large or small as appropriate computer hardware or OS support can
even possibly support, and also within reasonable speed limits. For now, the size or precision limits for PostgreSQL base 10
mathematics are pretty arbitrary. I am hoping to get a plugin developed that changes this. Such that the only limits on the
precision of base 10 mathematics in PostgreSQL are either the amount of memory from hardware or OS availability thereof,
or another phenomenon which dovetails with that, such as the extent of a very large indexing value, which I take to be the BIGINT.
I am not trying to replace any database product.
I hope that this is enough, and that this doesn't come too late for you to help me. I have found it very difficult to find
willing contributors, since in my context, I cannot contribute myself, or learn enough about C and PostgreSQL extension development
in the forseeable future.
Such improvements indeed would correspond with research or student use. Applications include encryption use
and mathematical research, continuous or discrete.
Is this enough information for your purposes? Can you do any more to help me, and could kindly reply to me here in these forums?
I can consider sending you even more information, if you want or need.
Z.M.
David Fetter
Oct 27, 2021, 3:06:26 AM10/27/21
to pgxn-...@googlegroups.com
On Thu, Oct 21, 2021 at 08:36:27PM -0700, Zachary1234 wrote:
> Okay. I have been using a pseudonym for the public internet just to
> preserve some anonymity for myself when dealing with people on forums.
So you lied and you have literally nothing to offer except your
> Okay. I have been using a pseudonym for the public internet just to
> preserve some anonymity for myself when dealing with people on forums.
imperious demands for some bullshit feature that in decades of work in
DBMSs I have yet to see anyone actually use, but you felt plenty free
to come pestering people for it.
I don't know how anybody else around here feels, and I certainly would
never presume to speak for any of them, but for myself, you're going
on a pretty short list I keep of people unworthy of my trust and
you're getting a heart-felt "go fuck yourself."
Sincerely,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David E. Wheeler
Oct 30, 2021, 2:34:12 PM10/30/21
to pgxn-...@googlegroups.com
On Oct 27, 2021, at 03:06, David Fetter <da...@fetter.org> wrote:
>> Okay. I have been using a pseudonym for the public internet just to
>> preserve some anonymity for myself when dealing with people on forums.
>
> So you lied and you have literally nothing to offer except your
> imperious demands for some bullshit feature that in decades of work in
> DBMSs I have yet to see anyone actually use, but you felt plenty free
> to come pestering people for it.
>
> I don't know how anybody else around here feels, and I certainly would
> never presume to speak for any of them, but for myself, you're going
> on a pretty short list I keep of people unworthy of my trust and
> you're getting a heart-felt "go fuck yourself.”
>> Okay. I have been using a pseudonym for the public internet just to
>> preserve some anonymity for myself when dealing with people on forums.
>
> So you lied and you have literally nothing to offer except your
> imperious demands for some bullshit feature that in decades of work in
> DBMSs I have yet to see anyone actually use, but you felt plenty free
> to come pestering people for it.
>
> I don't know how anybody else around here feels, and I certainly would
> never presume to speak for any of them, but for myself, you're going
> on a pretty short list I keep of people unworthy of my trust and
This might be a little harsh. I think it’s fair to say that there might be some academic interest in the topic, but given how little people have needed that precision over the decades, it may be difficult to find collaborators.
Best,
David
David E. Wheeler
Oct 30, 2021, 2:38:31 PM10/30/21
to pgxn-...@googlegroups.com
> So you lied and you have literally nothing to offer except your
> imperious demands for some bullshit feature that in decades of work in
> DBMSs I have yet to see anyone actually use, but you felt plenty free
> to come pestering people for it.
>
> I don't know how anybody else around here feels, and I certainly would
> never presume to speak for any of them, but for myself, you're going
> on a pretty short list I keep of people unworthy of my trust and
> you're getting a heart-felt "go fuck yourself.”
> imperious demands for some bullshit feature that in decades of work in
> DBMSs I have yet to see anyone actually use, but you felt plenty free
> to come pestering people for it.
>
> I don't know how anybody else around here feels, and I certainly would
> never presume to speak for any of them, but for myself, you're going
> on a pretty short list I keep of people unworthy of my trust and
Hey David, hope you’re well. Bit of feedback: This is more aggressive --- and, frankly, abusive --- than I’d like to see in our community. You may be right about Mitchell, but there isn’t evidence enough, and in any event I don’t think what we’ve seen so far merits quite such a thrashing.
I suggest responding to such posts more constructively, advising your interlocutor that there may be issues with their approach, what those are, and how they can overcome them. If then they shit all over you, then we know and can take action to protect the community and its discourse. But I don’t think we’re there yet, and in any event I don’t want to shut anyone down in quite this way.
Thanks,
David
David E. Wheeler
Oct 30, 2021, 2:40:26 PM10/30/21
to pgxn-...@googlegroups.com
On Oct 30, 2021, at 14:38, David E. Wheeler <da...@justatheory.com> wrote:
> Hey David, hope you’re well. Bit of feedback: This is more aggressive --- and, frankly, abusive --- than I’d like to see in our community. You may be right about Mitchell, but there isn’t evidence enough, and in any event I don’t think what we’ve seen so far merits quite such a thrashing.
>
> I suggest responding to such posts more constructively, advising your interlocutor that there may be issues with their approach, what those are, and how they can overcome them. If then they shit all over you, then we know and can take action to protect the community and its discourse. But I don’t think we’re there yet, and in any event I don’t want to shut anyone down in quite this way.
And now I get to deliver a mea culpa. 🤦🏻♂️
> Hey David, hope you’re well. Bit of feedback: This is more aggressive --- and, frankly, abusive --- than I’d like to see in our community. You may be right about Mitchell, but there isn’t evidence enough, and in any event I don’t think what we’ve seen so far merits quite such a thrashing.
>
> I suggest responding to such posts more constructively, advising your interlocutor that there may be issues with their approach, what those are, and how they can overcome them. If then they shit all over you, then we know and can take action to protect the community and its discourse. But I don’t think we’re there yet, and in any event I don’t want to shut anyone down in quite this way.
I meant this to be private feedback, not public. My apologies, David, for my crap vetting of the recipients.
Best,
David
Reply all
Reply to author
Forward
0 new messages