Thread: 7.2b5 libpq++ include files broken?

Hi,

as of 7.2b5 'libpq++.h' includes 'libpq++/pgconnection.h' which in
turn tries to include 'postgres_fe.h' which can't be found because it
has bee moved to the 'internal' subdirectory.

Are applications now required to supply -I/usr/include/pgsql/internal
in addition to -I/usr/include/pgsql or is the relocation of headers to
the 'internal' subdirectory still incomplete?

cu
    Reinhard

Reinhard Max <max@suse.de> writes:
> as of 7.2b5 'libpq++.h' includes 'libpq++/pgconnection.h' which in
> turn tries to include 'postgres_fe.h' which can't be found because it
> has bee moved to the 'internal' subdirectory.

Why was it moved to the internal subdirectory?  This seems a clear
error, as it will break a lot of stuff, and there is not a namespace
reason to do it.

            regards, tom lane

I wrote:
> Reinhard Max <max@suse.de> writes:
>> as of 7.2b5 'libpq++.h' includes 'libpq++/pgconnection.h' which in
>> turn tries to include 'postgres_fe.h' which can't be found because it
>> has bee moved to the 'internal' subdirectory.

> Why was it moved to the internal subdirectory?

After playing with this a bit, I see that postgres_fe.h is just a
wrapper around c.h, which we probably don't want to move out of
internal.  So relocating the file won't help.

AFAICT the only reason pgconnection.h includes postgres_fe.h is that
it needs DLLIMPORT.  So a possible solution is to move DLLIMPORT's
definition out of c.h and into pg_config.h --- or even better, put
the nontrivial cases into the appropriate pg_config_os.h file.
Comments?

            regards, tom lane

Tom Lane writes:

> Reinhard Max <max@suse.de> writes:
> > as of 7.2b5 'libpq++.h' includes 'libpq++/pgconnection.h' which in
> > turn tries to include 'postgres_fe.h' which can't be found because it
> > has bee moved to the 'internal' subdirectory.
>
> Why was it moved to the internal subdirectory?  This seems a clear
> error, as it will break a lot of stuff, and there is not a namespace
> reason to do it.

First, "postgres_fe.h" was invented to be the first file included by
client programs *within* the PostgreSQL source tree *only*.  (Remember we
annoyed the PHP folks over this but forced them to fix it.)  Second, and
more importantly, it includes c.h, which has namespace problems written
all over it.  I think postgres_fe.h should not be included by libpq++ at
all.  The only thing I recall it needing is the namespace configure test,
which it already gets via pg_config.h.

--
Peter Eisentraut   peter_e@gmx.net

Tom,

My PG environment:

psql (PostgreSQL) 7.1rc4
contains readline, history support


Here is my question: By update a view, I want to update a table, it works if I create a rule without 'where'
restriction'create rule xxx as on update yyy to zzz ...', but it fails if I add a WHERE after this clause. 


An example can be seen: ( "t1" is a simple table including only one column "c1";   "v_t1" is a simple view of "t1" and
rule"update_v_t1" update "t1" instead of update view "v_t1", which is not applicate directly) 


First, I create a table ("t1"):
create table "t1" ("c1" char(20));

Second, I create its view:
create view "v_t1" as select * from "t1";

Thirdly, I create the update-related rule as:
create rule update_v_t1 as on update to v_t1 do instead update t1 set "c1" = new."c1" where "c1" = old."c1";

OK. After I inserted some data into table "t1", I can update view "v_t1" just like what I want on "t1".

Problem comes when I try to define some more complex rule:

Forthly, I drop my previous rule update_v_t1
drop rule update_v_t1

5th, I re-create that rule
create rule update_v_t1 as on update to v_t1 where 1 = 1 do instead update t1 set "c1" = new."c1" where "c1" =
old."c1";      ( just added some RESTRICTION "where 1=1" ) 

I was told
"CREATED"

But when I try to update on "v_t1" any more, I was always told:
ERROR:  Cannot update a view without an appropriate rule




Is this a bug?

Please help.

Thank all of you


Eddy