I get this error in the log, don't know what impact this might have?

2021-11-23 19:53:50 *** (root)::[Data Source] ERROR: column pad.adsrc does not exist

2021-11-23 19:53:50 *** (root)::[Data Source] LINE 1: ...tttypmod) as data_type, a.attname as column_name, pad.adsrc ...

2021-11-23 19:53:50 *** (root)::[Data Source]

I believe this is related to pg_attrdef.adsrc which was removed from PostgreSQL in v12

i do some web search engine ( bing ..) and the error in not specific to manifold ! ( see Forums PostgreSQL.fr )

on github some people ( dev ?) speak about this !! see Column `adsrc` does not exist in PostgreSQL 12 · Issue #562 · ADOdb/ADOdb · GitHub .

Manifold has a nice documentation about database and some differences betweem them . see PostgreSQL, PostGIS (manifold.net)

regard's

Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en

That link proposes a fix to the problem in the PHP library being discussed. The issue is with how Manifold is querying PostgreSQL when the data source is created.

i.e. a bug in Manifold 9.

If you think it is, send in a bug report. Bugs are always a possibility, but if you cannot describe the situation with the clarity and precision required for a responsible bug report, don't make the mistake of failing to consider the possibility that the problem might not be a bug but an error in concept or operation.

A strong indication that you might be jumping to conclusions is that in this thread you haven't mentioned what was done that generated those log messages. For example, if it's a query that was used, you haven't provided the query text that results in the log messages cited, or the schemas for what the query uses. You only cited the log messages. That seems to indicate that you might believe the query text has no errors, and instead troubleshooting should begin by assuming the log messages indicate an error in the system. If so, that's getting it backwards, as experience shows queries very frequently tend to have errors in them (typos, errors in concept, etc.) while bugs are very infrequent.

Just guessing here given the absence of info, but it seems to me the right path is to start by debugging the query, eliminating the possibility of errors in the query or in configuration, not by assuming what was done is perfect and thus the error must be in the system. There's always time once you eliminate the most likely source of errors to move on to less likely sources of errors.

It's no accident that the bug report page includes this advice:

users should not let the consideration of a possible bug lead them astray if they have encountered a problem. Few things are as effective at stopping the solutions process as deciding too early on that the problem must be a bug. Do not allow assumptions about a possible bug to prevent you from taking effective measures to solve problems.

Bugs are very rare. It is almost always a mistake to think that a problem arises from a bug and not from an error in concept or operation. If you have a problem, hit the books and apply your maximum RTFM skills.

But, like I say, bugs are always possible, so if you believe this is a bug it is important to send in a bug report. Doing a good job of sending in a bug report requires sending in the essential information you've not posted in this thread, such as the query you are using, the schemas of what is involved, versions of software you are using, and other essentials. That's not wasted effort, because frequently during the process of gathering those details people discover a mistake being made, and immediately solve the problem.

I shouldn't have created this as a separate discussion thread as it is an error message that relates to a problem with materialized views in another thread. I didn't quite appreciate they were linked at the time of writing them both. So all debugging discussion has had happened in the other thread.

the post show that the implementation of the ORM / wrapper around postgresql using PHP need some update.

So any wrapper implementation that is base on the old version of postgresql have to perhaps update their wrapper !!!

Sorry i think you are perhaps in the truth i should check if manifold documentation cover database version supported by manifold 9 for any list databases : postgres/postgis, MySQL oracle, MySQL Maria, geopakage .

The errors should appear for any others wrappers that implement an acces to data manage by postgresql whatever language is use ( python,java,JavaScript,c/c#, PHP,SQL ), whatever library, cli, applications: editor to manage postgres , http server base on postgresql (PHP module for apache or IIS is common and is the P find in the end of LAMP or WAMP) .

The problem should be local : i mean a wrapper is local ( many wrappers ?), otherwise it is a protocol issue ( http / IP)!

I ll confirm later ...all need time but your recent post about test an older versions of postgres i think show the problem is on manifold side...

When issue arise : 32/64bit, compiler version,runtime version, application version of each layers ( DLL exe, ) matters....

The manifold documentation about install cover "

postgresql-11.2-1-windows-x64.exe".

Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en

You should describe more your context when post about an issue.

I mean :

-which os tool , code source script, application version you use

-when and where and how this issue occur ( log ? ..)

.

My post was out the context because about different layer ( ado) en language (PHP) even the base layer is postgres ( c/ PHP wrapper ? ).

Book about Science , cosmological model , Interstellar travels

Boyle surface fr ,en