Re: Should we still have old release notes in docs?

2019-02-12 Thread Thomas Kellerer

Tom Lane schrieb am 12.02.2019 um 17:12:

Yeah, see 527b5ed1a et al.

The part about having a unified release-note archive somewhere else is
still WIP.  The ball is in the web team's court on that, I think.


The Bucardo team has already done that:

https://bucardo.org/postgres_all_versions.html





Re: Compromised postgresql instances

2018-06-08 Thread Thomas Kellerer
> Please cite actual instances of such reports. Vague queries like this help
nobody.

There were several questions on SO 

https://stackoverflow.com/questions/49815460
https://stackoverflow.com/questions/47499766
https://stackoverflow.com/questions/47741077
https://dba.stackexchange.com/questions/184540

And a blog post going into details on how that specific attack works.

https://www.imperva.com/blog/2018/03/deep-dive-database-attacks-scarlett-johanssons-picture-used-for-crypto-mining-on-postgre-database/





--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: Time range

2019-05-31 Thread Thomas Kellerer



Donald Shtjefni schrieb am 31.05.2019 um 13:35:
> I was wondering why there is not a type Range of time without time zone, I 
> think it may be useful for someone, Is good if i do PR.

you can easily create one: 

   create type timerange as range (subtype = time);

Thomas

 




Re: PostgreSQL vs SQL/XML Standards

2018-10-29 Thread Thomas Kellerer
>> I have a access to too old 11.2 Oracle.  There I had to modify query
>> because there is not boolean type. I replaced bool by int, but I got a
>> error
>> ORA-19224:XPTY-004 .. expected node()*, got xs:string - it doesn't work
>> with/without string() wrappings.
>>
>The problem is in last line - the expression  "sale/@taxable = false()" is
>not valid on Oracle. Using string() wrapping is a issue, because it returns
">true", "false", but Oracle int doesn't accept it.

That line seems to be valid - but you need to pass an XMLTYPE value, not a
VARCHAR

https://dbfiddle.uk/?rdbms=oracle_11.2&fiddle=21cdf890a26e97fa8667b2d6a960bd33

As far as I can tell inside XQuery Oracle does support boolean, but not as a
return type 





--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: [Proposal] Add accumulated statistics for wait event

2018-07-23 Thread Thomas Kellerer
> This proposal is about recording additional statistics of wait
events. 
> The pg_stat_activity view is very useful in analysis for performance
> issues. 
> But it is difficult to get information of wait events in detail, 
> when you need to deep dive into analysis of performance. 
> It is because pg_stat_activity just shows the current wait status of
> backend. 

There is an extension that samples the information from pg_stat_activity
(similar to Oracle's ASH). 

https://github.com/postgrespro/pg_wait_sampling

Maybe it's worthwhile to combine the efforts? 




--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: PostgreSQL and Real Application Testing (RAT)

2019-08-27 Thread Thomas Kellerer
ROS Didier schrieb am 27.08.2019 um 12:47:
> In my business, one of the things blocking the migration from Oracle
> to PostgreSQL is not having the equivalent of Oracle Real Application
> Testing .
>
> This product captures a charge in production and replay it in a test
> environment.
>
> this allows to know the impacts of a migration to a newer version,
> the creation of an index..
>
> is there an equivalent in the PostgreSQL community?
>
> if not, do you think it's technically possible to do it?
>
> who would be interested in this project?
Not sure how up-to-date that is, but you might want to have a look here:

https://wiki.postgresql.org/wiki/Statement_Playback





Re: no mailing list hits in google

2019-08-28 Thread Thomas Kellerer

Merlin Moncure schrieb am 28.08.2019 um 18:22:

My test case here is the query: pgsql-hackers


That search term is the first hit on DuckDuckGo:
https://duckduckgo.com/?q=pgsql-hackers+ExecHashJoinNewBatch&t=h_&ia=web

Searching for "postgres ExecHashJoinNewBatch" returns that ot position 4
https://duckduckgo.com/?q=postgres+ExecHashJoinNewBatch&t=h_&ia=web





Re: Which PG version does CVE-2021-20229 affected?

2021-03-05 Thread Thomas Kellerer
Michael Paquier schrieb am 05.03.2021 um 08:38:
> On Fri, Mar 05, 2021 at 12:32:43AM -0700, bchen90 wrote:
>> NVD link:
>>
>> https://nvd.nist.gov/vuln/detail/CVE-2021-20229#vulnCurrentDescriptionTitle
>
> This link includes incorrect information.  CVE-2021-20229 is only a
> problem in 13.0 and 13.1, fixed in 13.2.  Please see for example here:
> https://www.postgresql.org/support/security/
>
> The commit that fixed the issue is c028faf, mentioning 9ce77d7 as the
> origin point, a commit introduced in Postgres 13.

I think the information is correct as it says "Up to (excluding) 13.2"

I understand the "(excluding)" part, such that the "excluded" version
is _not_ affected by it.

But it's really a confusing way to present that kind of information.





Re: Migration Oracle multitenant database to PostgreSQL ?

2020-11-24 Thread Thomas Kellerer


ROS Didier schrieb am 24.11.2020 um 09:09:
> I would like to know if it is possible to migrate Oracle multitenant
> database (with multiple PDB) to PostgreSQL ?
Postgres' databases are very similar to Oracle's PDBs.

Probably the biggest difference is, that you can't shutdown
a single database as you can do with a PDB.

Database users in Postgres are like Oracle's "common users", they are
global for the whole instance (aka "cluster" in Postgres' terms). There
are no database specific users.

Thomas









Re: Jsonpath ** vs lax mode

2021-01-21 Thread Thomas Kellerer
Alexander Korotkov schrieb am 20.01.2021 um 18:13:
> We have a bug report which says that jsonpath ** operator behaves strangely 
> in the lax mode [1].

That report was from me ;)

Thanks for looking into it.

> At first sight, we may just say that lax mode just sucks and
> counter-intuitive results are expected.  But at the second sight, the
> lax mode is used by default and current behavior may look too
> surprising.

I personally would be fine with the manual stating that the Postgres extension
to the JSONPath processing that allows a recursive lookup using ** requires 
strict
mode to work properly.

It should probably be documented in chapter 9.16.2 "The SQL/JSON Path Language",
maybe with a little warning in the description of jsonb_path_query** and in
chapter 8.14.16 as well (or at least that's were I would expect such a warning)

Regards
Thomas




Re: Why does creating logical replication subscriptions require superuser?

2021-01-22 Thread Thomas Kellerer
Andrey Borodin schrieb am 22.01.2021 um 08:32:

> Replication is running under superuser and e.g. one can add system catalog to 
> subscription.
> Or exploit this fact other way. Having superuser you can just COPY FROM 
> PROGRAM anything.

It was my understanding that the replication process itself runs with the user 
specified
when creating the subscription - which is no necessarily a superuser. Only a 
user that
is part of the "replication" role.

The replication user also needs to be granted SELECT privileges on all tables 
of the publication,
so it's quite easy to control what the replication user has access to.
Plus the publication also limits what the replication can see.

I second the idea that not requiring a superuser to create a subscription would 
make things
a lot easier. We worked around that by creating a security definer function 
that runs
the CREATE SUBSCRIPTION command.

Thomas




Re: COPY table_name (single_column) FROM 'unknown.txt' DELIMITER E'\n'

2021-05-05 Thread Thomas Kellerer
Joel Jacobson schrieb am 05.05.2021 um 17:30:
> Could it be an idea to exploit the fact that DELIMITER E'\n' is currently an 
> error?
>
>     ERROR:  COPY delimiter cannot be newline or carriage return
>
> That is, to change E'\n' to be a valid delimiter, which would simply read 
> each line
> delimited by newlines, as a single column.
>
> The hack I'm currently abusing is to find some one-byte character that is not 
> present anywhere in the text file,
> and then to use that character as a delimiter. This doesn't work when needing 
> to deal with a text file
> which content is unknown at the time when writing the code though, so it's 
> mostly useful for throwaway one-off queries.

What about

delimiter E'\1'

The probability that a file contains the ASCII "character" 1 seems rather low.

Thomas






Re: FEATURE REQUEST: Role vCPU limit/priority

2024-01-23 Thread Thomas Kellerer
Yoni Sade schrieb am 21.01.2024 um 19:07:
> It would be useful to have the ability to define for a role default
> vCPU affinity limits/thread priority settings so that more active
> sessions could coexist similar to MySQL resource groups
> .

To a certain extent, you can achieve something like that using Linux cgroups

https://www.cybertec-postgresql.com/en/linux-cgroups-for-postgresql/






Re: SELECT INTO deprecation

2020-12-03 Thread Thomas Kellerer
Stephen Frost schrieb am 02.12.2020 um 18:58:
> We should either remove it, or remove the comments that it's deprecated,
> not try to make it more deprecated or try to somehow increase the
> recommendation to not use it.

(I am writing from a "user only" perspective, not a developer)

I don't see any warning about the syntax being "deprecated" in the current 
manual.

There is only a note that says that CTAS is "recommended" instead of SELET INTO,
but for me that's something entirely different than "deprecating" it.

I personally have nothing against removing it, but I still see it used
a lot in questions on various online forums, and I would think that
a lot of people would be very unpleasantly surprised if a feature
gets removed without any warning (the current "recommendation" does not
constitute a deprecation or even removal warning for most people I guess)

I would vote for a clear deprecation message as suggested by Peter, but I would
add "and will be removed in a future version" to it.

Not sure if maybe even back-patching that warning would make sense as well, so
that also users of older versions get to see that warning.

Then target 15 or 16 as the release for removal, but not 14

Thomas




Re: Should we still have old release notes in docs?

2019-02-12 Thread Thomas Kellerer

Tom Lane schrieb am 12.02.2019 um 17:12:

Yeah, see 527b5ed1a et al.

The part about having a unified release-note archive somewhere else is
still WIP.  The ball is in the web team's court on that, I think.


The Bucardo team has already done that:

https://bucardo.org/postgres_all_versions.html





Re: Time range

2019-05-31 Thread Thomas Kellerer



Donald Shtjefni schrieb am 31.05.2019 um 13:35:
> I was wondering why there is not a type Range of time without time zone, I 
> think it may be useful for someone, Is good if i do PR.

you can easily create one: 

   create type timerange as range (subtype = time);

Thomas

 




Re: Compromised postgresql instances

2018-06-08 Thread Thomas Kellerer
> Please cite actual instances of such reports. Vague queries like this help
nobody.

There were several questions on SO 

https://stackoverflow.com/questions/49815460
https://stackoverflow.com/questions/47499766
https://stackoverflow.com/questions/47741077
https://dba.stackexchange.com/questions/184540

And a blog post going into details on how that specific attack works.

https://www.imperva.com/blog/2018/03/deep-dive-database-attacks-scarlett-johanssons-picture-used-for-crypto-mining-on-postgre-database/





--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: PostgreSQL and Real Application Testing (RAT)

2019-08-27 Thread Thomas Kellerer
ROS Didier schrieb am 27.08.2019 um 12:47:
> In my business, one of the things blocking the migration from Oracle
> to PostgreSQL is not having the equivalent of Oracle Real Application
> Testing .
>
> This product captures a charge in production and replay it in a test
> environment.
>
> this allows to know the impacts of a migration to a newer version,
> the creation of an index..
>
> is there an equivalent in the PostgreSQL community?
>
> if not, do you think it's technically possible to do it?
>
> who would be interested in this project?
Not sure how up-to-date that is, but you might want to have a look here:

https://wiki.postgresql.org/wiki/Statement_Playback





Re: no mailing list hits in google

2019-08-28 Thread Thomas Kellerer

Merlin Moncure schrieb am 28.08.2019 um 18:22:

My test case here is the query: pgsql-hackers


That search term is the first hit on DuckDuckGo:
https://duckduckgo.com/?q=pgsql-hackers+ExecHashJoinNewBatch&t=h_&ia=web

Searching for "postgres ExecHashJoinNewBatch" returns that ot position 4
https://duckduckgo.com/?q=postgres+ExecHashJoinNewBatch&t=h_&ia=web





Re: [Proposal] Add accumulated statistics for wait event

2018-07-23 Thread Thomas Kellerer
> This proposal is about recording additional statistics of wait
events. 
> The pg_stat_activity view is very useful in analysis for performance
> issues. 
> But it is difficult to get information of wait events in detail, 
> when you need to deep dive into analysis of performance. 
> It is because pg_stat_activity just shows the current wait status of
> backend. 

There is an extension that samples the information from pg_stat_activity
(similar to Oracle's ASH). 

https://github.com/postgrespro/pg_wait_sampling

Maybe it's worthwhile to combine the efforts? 




--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: PostgreSQL vs SQL/XML Standards

2018-10-29 Thread Thomas Kellerer
>> I have a access to too old 11.2 Oracle.  There I had to modify query
>> because there is not boolean type. I replaced bool by int, but I got a
>> error
>> ORA-19224:XPTY-004 .. expected node()*, got xs:string - it doesn't work
>> with/without string() wrappings.
>>
>The problem is in last line - the expression  "sale/@taxable = false()" is
>not valid on Oracle. Using string() wrapping is a issue, because it returns
">true", "false", but Oracle int doesn't accept it.

That line seems to be valid - but you need to pass an XMLTYPE value, not a
VARCHAR

https://dbfiddle.uk/?rdbms=oracle_11.2&fiddle=21cdf890a26e97fa8667b2d6a960bd33

As far as I can tell inside XQuery Oracle does support boolean, but not as a
return type 





--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: Patch: Global Unique Index

2022-11-23 Thread Thomas Kellerer

Tom Lane schrieb am 18.11.2022 um 16:06:

Do we need new syntax actually? I think that a global unique index
can be created automatically instead of raising an error "unique
constraint on partitioned table must include all partitioning
columns"


I'm not convinced that we want this feature at all: as far as I can
see, it will completely destroy the benefits of making a partitioned
table in the first place.  But if we do want it, I don't think it
should be so easy to create a global index by accident as that syntax
approach would make it.  I think there needs to be a pretty clear YES
I WANT TO SHOOT MYSELF IN THE FOOT clause in the command.


There are many Oracle users that find global indexes useful despite
their disadvantages.

I have seen this mostly when the goal was to get the benefits of
partition pruning at runtime which turned the full table scan (=Seq Scan)
on huge tables to partition scans on much smaller partitions.
Partition wise joins were also helpful for query performance.
The substantially slower drop partition performance was accepted in thos cases

I think it would be nice to have the option in Postgres as well.

I do agree however, that the global index should not be created automatically.

Something like CREATE GLOBAL [UNIQUE] INDEX ... would be a lot better


Just my 0.05€




Re: Patch: Global Unique Index

2022-11-24 Thread Thomas Kellerer
Pavel Stehule schrieb am 24.11.2022 um 07:03:
> There are many Oracle users that find global indexes useful despite
> their disadvantages.
>
> I have seen this mostly when the goal was to get the benefits of
> partition pruning at runtime which turned the full table scan (=Seq Scan)
> on huge tables to partition scans on much smaller partitions.
> Partition wise joins were also helpful for query performance.
> The substantially slower drop partition performance was accepted in thos 
> cases
>
>
> I think it would be nice to have the option in Postgres as well.
>
> I do agree however, that the global index should not be created 
> automatically.
>
> Something like CREATE GLOBAL [UNIQUE] INDEX ... would be a lot better
>
>
> Is it necessary to use special marks like GLOBAL if this index will
> be partitioned, and uniqueness will be ensured by repeated
> evaluations?
>
> Or you think so there should be really forced one relation based
> index?
>
> I can imagine a unique index on partitions without a special mark,
> that will be partitioned,  and a second variant classic index created
> over a partitioned table, that will be marked as GLOBAL.


My personal opinion is, that a global index should never be created
automatically.

The user should consciously decide on using a feature
that might have a serious impact on performance in some areas.





Re: Decomposing xml into table

2020-06-23 Thread Thomas Kellerer
Surafel Temesgen schrieb am 23.06.2020 um 13:59:
>> Did you try the xmltable function?
>
> yes i know it  but i am proposing changing given xml data in to
> relational form and insert it to desired table at once
Well, xmltable() does change the XML data to a relational form and
the result can directly be used to insert into a table

   insert into target_table (...)
   select ...
   from xmltable(...);





Re: Why forbid "INSERT INTO t () VALUES ();"

2020-06-24 Thread Thomas Kellerer
Fabien COELHO schrieb am 24.06.2020 um 14:18:
> I would like to create an "all defaults" row, i.e. a row composed of the 
> default values for all attributes, so I wrote:
>
>   INSERT INTO t() VALUES ();
>
> This is forbidden by postgres, and also sqlite.
>
> Is there any good reason why this should be the case?
>

Maybe because

   insert into t default values;

exists (and is standard SQL if I'm not mistaken)

Thomas





Re: [PATCH] distinct aggregates within a window function WIP

2020-01-13 Thread Thomas Kellerer
Tom Lane schrieb am 13.01.2020 um 15:19:

> what it is is attaching DISTINCT to a window function itself.
> I'd still ask whether it's well-defined though, or even minimally
> sensible.  Window functions are generally supposed to produce one
> row per input row --- how does that square with the implicit row
> merging of DISTINCT?  They're also typically row-order-sensitive
> --- how does that work with DISTINCT?  Also, to the extent that
> this is sensible, can't you get the same results already today
> with appropriate use of window framing options?

I find the example using array_agg() and cumulative window functions a
bit confusing as well, but I think there are situations where having this
is really helpful, e.g.:

   count(distinct some_column) over (partition by something)

I know it's not an argument, but Oracle supports this and porting
queries like that from Oracle to Postgres isn't really fun.

Thomas







Re: Do we need to handle orphaned prepared transactions in the server?

2020-01-21 Thread Thomas Kellerer
> First and foremost is to define what an orphaned transaction is. At
> this stage, I believe any prepared transaction that has been there
> for more than X time may be considered as an orphan. X may be defined
> as an integer in seconds (a GUC perhaps). May be there are better
> ways to define this. Please feel free to chime in.


What about specifying a timeout when starting the prepared transaction?

I can imagine situations where a timeout of hours might be needed/anticipated
(e.g. really slow external systems) and situations where the developer
knows that the other systems are never slower than a few seconds.

Something like:

   prepare transaction 42 timeout interval '2 days';

or

   prepare transaction 42 timeout interval '30 second';

Or maybe even with a fixed timestamp instead of an interval?

   prepare transaction 42 timeout timestamp '2020-01-30 14:00:00';

Thomas




Re: Do we need to handle orphaned prepared transactions in the server?

2020-01-22 Thread Thomas Kellerer
Tom Lane schrieb am 22.01.2020 um 16:05:
> Craig Ringer  writes:
>> So I don't really see the point of doing anything with 2PC xacts
>> within Pg proper. It's the job of the app that prepares the 2PC xacts,
>> and if that app is unable to resolve them for some reason there's no
>> generally-correct action to take without administrator action.
>
> Right.  It's the XA transaction manager's job not to forget uncommitted
> transactions.  Reasoning as though no TM exists is not only not very
> relevant, but it might lead you to put in features that actually
> make the TM's job harder.  In particular, a timeout (or any other
> mechanism that leads PG to abort or commit a prepared transaction
> of its own accord) does that.
>
> Or another way to put it: the fundamental premise of a prepared
> transaction is that it will be possible to commit it on-demand with
> extremely low chance of failure.  Designing in a reason why we'd
> fail to be able to do that would be an anti-feature.

That's a fair point, but the reality is that not all XA transaction managers
do a good job with that.

Having somthing on the database side that can handle that in
exceptional cases would be very welcome.

(In Oracle you can't sometimes even run DML on tables where you have orphaned
XA transactions - which is extremely annoying, because by default
only the DBA can clean that up)

Thomas






Re: open-source equivalent of golden-gate

2020-02-11 Thread Thomas Kellerer
ROS Didier schrieb am 11.02.2020 um 11:23:
> In the Oracle world we use the product "golden gate" to execute
> transactions from a source database (Oracle, Mysql) to a PostgreSQL
> instance.
>
> This allows 2 Oracle and PostgreSQL databases to be updated at the
> same time in real time.
>
> I would like to know if there is an equivalent open-source product.
>
> Thanks in advance
>
> Best Regards
> Didier ROS

The closest solutions to golden gate are probably

* https://debezium.io/
* https://www.symmetricds.org/

Thomas




Re: Persist MVCC forever - retain history

2020-07-05 Thread Thomas Kellerer

Konstantin Knizhnik schrieb am 05.07.2020 um 19:31:

I am surprised that you are saying you didn't feel big interest. My
reading of the thread is the opposite, that there was quite some
interest, but that there are technical challenges to overcome. So you
gave up on that work?

No, I have not gave up.
But...
There are well known problems of proposed approach:
1. Not supporting schema changes
2. Not compatible with DROP/TRUNCATE
3. Presence of large number of aborted transaction can slow down data access.
4. Semantic of join of tables with different timestamp is obscure.


Oracle partially solved this (at least 1,3 and 4 - don't know about 3) by storing the old 
versions in a separate table that is automatically managed if you enable the feature. If 
a query uses the AS OF to go "back in time", it's rewritten to access the 
history table.

Thomas





Re: EDB builds Postgres 13 with an obsolete ICU version

2020-08-04 Thread Thomas Kellerer
Dave Page schrieb am 04.08.2020 um 10:06:
> Correct - updating ICU would mean a reindex is required following any
> upgrade, major or minor.
>
> I would really like to find an acceptable solution to this however as
> it really would be good to be able to update ICU.
>

What about providing a newer ICU version as kind of an "add-on" download 
containing only the needed DLLs (assuming it's as easy as only replacing the 
DLLs)?

Then everyone who wishes to use a newer ICU version can manually install them.
If that download carries a big "ATTENTION: reindex required" I don't think this 
would be a big risk.

Thomas






Re: EDB builds Postgres 13 with an obsolete ICU version

2020-08-11 Thread Thomas Kellerer

Jaime Casanova schrieb am 11.08.2020 um 20:39:

As a follow-up to bug #16570 [1] and other previous discussions
on the mailing-lists, I'm checking out PG13 beta for Windows
from:
  https://www.enterprisedb.com/postgresql-early-experience
and it ships with the same obsolete ICU 53 that was used
for PG 10,11,12.
Besides not having the latest Unicode features and fixes, ICU 53
ignores the BCP 47 tags syntax in collations used as examples
in Postgres documentation, which leads to confusion and
false bug reports.
The current version is ICU 67.



Sadly, that is managed by EDB and not by the community.

You can try 
https://www.2ndquadrant.com/en/resources/postgresql-installer-2ndquadrant/
which uses ICU-62.2, is not the latest but should allow you to follow
the examples in the documentation.



One of the reasons I prefer the EDB builds is, that they provide a ZIP file 
without the installer overhead.
Any chance 2ndQuadrant can supply something like that as well?

Thomas




Re: EDB builds Postgres 13 with an obsolete ICU version

2020-08-18 Thread Thomas Kellerer
Magnus Hagander schrieb am 18.08.2020 um 11:38:
> It might be a slightly larger percentage on Windows who use it, but
> I'm willing to bet it's still quite low.

I have seen increasingly more questions around ICU collations on Windows due to 
the fact that people that migrate from SQL Server to Postgres very often keep 
Windows as the operating system and they want to get SQL Server's 
case-insensitivity (at least partially) using ICU collations.

Thomas






Re: Official Windows Installer and Documentation

2022-07-27 Thread Thomas Kellerer

David G. Johnston schrieb am 27.07.2022 um 21:21:

And then there is the issue of file ownership.

Assuming we want better documentation for this specific issue for
back-patching what would that look like?

Going forward should our installer be creating the postgres user for
consistency with other platforms or not?


Didn't the installer used to do that in earlier releases and that
was removed when Postgres was able to "drop privileges" when the
service is started?

I remember a lot of problems around the specific Postgres service
account when that still was the case.

As far as I can tell, most of the problems of the Windows installer
stem from the fact that it tries to use icacls to set privileges
on the data directory. This seems to fail quite frequently,
causing the infamous "Problem running post-install step" error.

The fact that the installer still defaults to using "c:\Program Files"
for the location of the data directoy might be related to that.
(but then I don't know enough of the internals of the installer
and Windows)

Just my 0.02€

Thomas




Re: Partition prune with stable Expr

2020-09-28 Thread Thomas Kellerer
Andy Fan schrieb am 28.09.2020 um 02:54:
> Well, that's very interesting.  Specific to my user case, 
> SELECT * FROM p WHERE pkey = to_date('2018-12-13', '-mm-dd)';

Why use to_date() at all for a constant value?
Can't you use a standard ANSI date literal (date '2018-12-13')?

Alternatively, you could use make_date(2018,12,13) which is marked as immutable.

Thomas




Re: Let's make PostgreSQL multi-threaded

2023-06-07 Thread Thomas Kellerer

Tomas Vondra schrieb am 07.06.2023 um 21:20:

Also, which other projects did this transition? Is there something we
could learn from them? Were they restricted to much smaller list of
platforms?


Firebird did this a while ago if I'm not mistaken.

Not open source, but Oracle was historically multi-threaded on Windows and 
multi-process on all other platforms.
I _think_ starting with 19c you can optionally run it multi-threaded on Linux 
as well.

But I doubt, they are willing to share any insights ;)





Re: Migration database from mysql to postgress

2023-06-23 Thread Thomas Kellerer
Alfredo Alcala schrieb am 23.06.2023 um 11:30:
> I need to move some databases from a MySQL server to Postgresql.
>
> Can someone tell me the migration procedure, tools, and recommendations? 


Despite its name, "ora2pg" can also migrate MySQL to Postgres

https://ora2pg.darold.net/