Re: [GENERAL] Making changes to PostgreSQL's configure logic so as to have contrib modules installed in a specific directory and make them use PGXS?

2017-01-31 Thread Tom Lane
postgres user  writes:
> I want to configure my PostgreSQL installation in such a manner such that
> the contrib modules of the PostgreSQL distribution are stored in a specific
> directory and they should use the PGXS extensions management system
> supported by Postgres, as they are currently packaged along with Postgres
> and follow a specific directory structure they are installed along with
> Postgres but I don't want that. I want all those contrib module extensions
> to use a separate pg_config and hence want their makefiles to use PGXS. How
> do I go about doing that.

What exactly are you trying to accomplish here?  Why do you think it's a
good idea for your extensions to not use the base system's configuration?
It's very easy to construct examples in which such an extension build
would flat out not work with the base system, so your requirement really
has to be that the extension deviate in just limited ways from the base
--- but you've not said in just what ways you want it to deviate.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Making changes to PostgreSQL's configure logic so as to have contrib modules installed in a specific directory and make them use PGXS?

2017-01-31 Thread Melvin Davidson
Probably your best best is to install normally, then move the contribs to a
directory of your choice
and make a symbolic link from the old directory. That way it should work
with both PostgreSQL
and PGXS.

On Tue, Jan 31, 2017 at 7:35 PM, Adrian Klaver 
wrote:

> On 01/31/2017 03:04 PM, postgres user wrote:
>
>> Hi,
>>
>> I want to configure my PostgreSQL installation in such a manner such
>> that the contrib modules of the PostgreSQL distribution are stored in a
>> specific directory and they should use the PGXS extensions management
>> system supported by Postgres, as they are currently packaged along with
>> Postgres and follow a specific directory structure they are installed
>> along with Postgres but I don't want that. I want all those contrib
>> module extensions to use a separate pg_config and hence want their
>> makefiles to use PGXS. How do I go about doing that.
>>
>
> Not sure, though some more information would help:
>
> 1) Am I right in assuming you are building everything from source?
>
> 2) If not what is your install procedure?
>
> 3) When you say all the contrib modules do really mean all or all in some
> list?
>
> 4) Where is the directory you want them to be installed in located?
>
> 5) What OS are you using?
>
> 6) Have you looked at an OS packaging systems to do this?
>
>
>> Thanks
>>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.


Re: [GENERAL] Making changes to PostgreSQL's configure logic so as to have contrib modules installed in a specific directory and make them use PGXS?

2017-01-31 Thread Adrian Klaver

On 01/31/2017 03:04 PM, postgres user wrote:

Hi,

I want to configure my PostgreSQL installation in such a manner such
that the contrib modules of the PostgreSQL distribution are stored in a
specific directory and they should use the PGXS extensions management
system supported by Postgres, as they are currently packaged along with
Postgres and follow a specific directory structure they are installed
along with Postgres but I don't want that. I want all those contrib
module extensions to use a separate pg_config and hence want their
makefiles to use PGXS. How do I go about doing that.


Not sure, though some more information would help:

1) Am I right in assuming you are building everything from source?

2) If not what is your install procedure?

3) When you say all the contrib modules do really mean all or all in 
some list?


4) Where is the directory you want them to be installed in located?

5) What OS are you using?

6) Have you looked at an OS packaging systems to do this?



Thanks



--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Making changes to PostgreSQL's configure logic so as to have contrib modules installed in a specific directory and make them use PGXS?

2017-01-31 Thread postgres user
Hi,

I want to configure my PostgreSQL installation in such a manner such that
the contrib modules of the PostgreSQL distribution are stored in a specific
directory and they should use the PGXS extensions management system
supported by Postgres, as they are currently packaged along with Postgres
and follow a specific directory structure they are installed along with
Postgres but I don't want that. I want all those contrib module extensions
to use a separate pg_config and hence want their makefiles to use PGXS. How
do I go about doing that.

Thanks


Re: [GENERAL] Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

2017-01-31 Thread Nikolai Zhubr

31.01.2017 19:51, Andres Freund:
[...]

Exactly same trouble with 9.4 (Specifically EDB 9.4.10-1 win32)


That's good to know, less because of 519b0757, more because of the latch
changes - but they also went in in 9.5...


Would it make sense to check some even older ones?


Could you use process monitor or such to see what the process is doing
while using a lot of CPU?


I'm not sure how to do this, especially considering that the process in 
question is running as a service?


Now, some more input:

* 9.5.2 server running on linux x86_64 - unaffected! (What a relief! We 
are moving to Centos soon anyway!)


* 9.4.4 server running on win7 32-bit - affected, same thing as on XP.


Thank you.

Nikolai



Regards,

Andres





--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

2017-01-31 Thread Andres Freund
On 2017-01-31 11:45:33 +0300, Nikolai Zhubr wrote:
> 31.01.2017 10:37, I wrote:
> > [...]
> > > > 1. "select localtimestamp" 40 times (As separate requests, one by
> > > > one, but
> > > > no delay inserted in between)
> > > > 2. wait 1/2 second.
> > > > 3. goto 1
> > > 
> > > Craig, could this be a side-effect of 519b0757? That's new in 9.5, and
> > > that's directly related to the code paths discussed here.
> > 
> > Meanwhile I'll redo my tests using 9.4 instead of 9.5 and report back.
> 
> Exactly same trouble with 9.4 (Specifically EDB 9.4.10-1 win32)

That's good to know, less because of 519b0757, more because of the latch
changes - but they also went in in 9.5...

> Would it make sense to check some even older ones?

Could you use process monitor or such to see what the process is doing
while using a lot of CPU?

Regards,

Andres


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Why is table not found?

2017-01-31 Thread Egon Frerich
Thank you all for your answers.

You see: it is a newbie question.

Egon

Am 31.01.2017 um 14:45 schrieb Egon Frerich:
>
> I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
> find the the table. In sql field is shown:
>
> > -- Table: "Raum"
>
> > -- DROP TABLE "Raum";
>
> > CREATE TABLE "Raum"
> > (
> >   "RaumID" serial NOT NULL, -- Automatisch vergebenes
> Identifizierungsmerkmal für den Raum
> >   "Raum" character varying(15), -- Bezeichnung des Raums
> >   CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
> > )
> > WITH (
> >   OIDS=FALSE
> > );
> > ALTER TABLE "Raum"
> >   OWNER TO egon;
> > COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes
> Identifizierungsmerkmal für den Raum';
> > COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';
>
>
> > -- Index: "Raum_RaumID_idx"
>
> > -- DROP INDEX "Raum_RaumID_idx";
>
> > CREATE INDEX "Raum_RaumID_idx"
> >   ON "Raum"
> >   USING btree
> >   ("RaumID");
>
> But psql tells me "Raum" is not existent:
>
> > egon@xfEinzel ~ $ psql Hausrat
> > psql (9.3.15)
> > Type "help" for help.
>
> > Hausrat=# SELECT * FROM Raum;
> > ERROR:  relation "raum" does not exist
> > LINE 1: SELECT * FROM Raum;
> >   ^
> > Hausrat=#
>
> Why?
>
> Egon
>
> > > >




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Why is table not found?

2017-01-31 Thread Alban Hertroys

> On 31 Jan 2017, at 14:45, Egon Frerich  wrote:
>> 
>> CREATE TABLE "Raum"
>> (
>>  "RaumID" serial NOT NULL, -- Automatisch vergebenes

> But psql tells me "Raum" is not existent:
> 
>> egon@xfEinzel ~ $ psql Hausrat
>> psql (9.3.15)
>> Type "help" for help.
>> 
>> Hausrat=# SELECT * FROM Raum;
>> ERROR:  relation "raum" does not exist
>> LINE 1: SELECT * FROM Raum;

Instead of adding quotes to your select statement (as others suggested), IMHO 
the better thing to do is to remove them from your create statements. Most of 
the time there is no benefit creating case-sensitive identifiers in a database.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Why is table not found?

2017-01-31 Thread John McKown
On Tue, Jan 31, 2017 at 7:45 AM, Egon Frerich  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
> find the the table. In sql field is shown:
>
> > -- Table: "Raum"
> >
> > -- DROP TABLE "Raum";
> >
> > CREATE TABLE "Raum"
> > (
> >   "RaumID" serial NOT NULL, -- Automatisch vergebenes
> Identifizierungsmerkmal für den Raum
> >   "Raum" character varying(15), -- Bezeichnung des Raums
> >   CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
> > )
> > WITH (
> >   OIDS=FALSE
> > );
> > ALTER TABLE "Raum"
> >   OWNER TO egon;
> > COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes
> Identifizierungsmerkmal für den Raum';
> > COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';
> >
> >
> > -- Index: "Raum_RaumID_idx"
> >
> > -- DROP INDEX "Raum_RaumID_idx";
> >
> > CREATE INDEX "Raum_RaumID_idx"
> >   ON "Raum"
> >   USING btree
> >   ("RaumID");
> >
> But psql tells me "Raum" is not existent:
>
> > egon@xfEinzel ~ $ psql Hausrat
> > psql (9.3.15)
> > Type "help" for help.
> >
> > Hausrat=# SELECT * FROM Raum;
> > ERROR:  relation "raum" does not exist
> > LINE 1: SELECT * FROM Raum;
> >   ^
> > Hausrat=#
>
> Why?
>

​Because, "Raum" is not equal to Raum. This is because, when a name is not
enclosed in " marks, PostgreSQL will force it to be lower case. So "Raum"
is mixed cased, as you would expect. But Raum is basically converted to
"raum".​
ref:
https://www.postgresql.org/docs/9.5/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS




>
> Egon
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIbBAEBAgAGBQJYkJTwAAoJECc7nbY+bg5uiRQP9iC4UtbHpPvdvV796fxcMSFp
> dncPHzkTKHvcEh3V9t/Xn/BzEHBDAO6RO8jmU18Ja9f/0nOyNXrWxal0OJZXint5
> l3/qRKbekkl7zfogysh4XgZQkpWwsJcYDGoG5tCUQm8TJ3sCk9a9+mbkDhy0Vsev
> MPeyYl/fYvlTBkiRmlPZTOX7YjRzeryKXguB3PBke3Vo6SZ1sFWnMjJ7bc2b
> 4cW9hmInmwXZ4EBOfcUW4QnfM0mgHBMGxJwYVQfeC6fQeqT8emh0KQLqozjFe/tk
> KNKDU0RebcrBgXP/lIGI34XahZW+WOdLli/t8wBUNiINruY2FlizuH6Uuak3tLjC
> cD7vi0SzNK2YFr9Rozw8ow9WVxSfjWBLiOA1GkFdhxKb80NLHthzo8oIVaCqz0bj
> 71kA0ewgZ9NMay6ch1VjqSPPFhAZHc1Ho3xIAa0BsZpvEdccDBsL+yk/6DGDYua9
> 5oT1p6CZqfDJqxEIoUiNaJEKm3An5ySN8hHn527/apG9yA9QMh5qJPHA0wRqtLxN
> hNSxugKhS6UOw/Wivbx0OIhN8jqBv4m22UgO9pFGgxHLs1hheSTMUSbExFCLuK+z
> sS1Kw9syplk+lFTzK6mqNpr3BQ6v2fmkPmRTZoID4e9T3DY8Bna2JXG2U1QGEzwa
> kwpJOMAvY3DDPv3pIK8=
> =i8FY
> -END PGP SIGNATURE-
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown


Re: [GENERAL] Why is table not found?

2017-01-31 Thread Rob Sargent
You must quite as "Raum"

> On Jan 31, 2017, at 6:45 AM, Egon Frerich  wrote:
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
> find the the table. In sql field is shown:
> 
>> -- Table: "Raum"
>> 
>> -- DROP TABLE "Raum";
>> 
>> CREATE TABLE "Raum"
>> (
>>  "RaumID" serial NOT NULL, -- Automatisch vergebenes
> Identifizierungsmerkmal für den Raum
>>  "Raum" character varying(15), -- Bezeichnung des Raums
>>  CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
>> )
>> WITH (
>>  OIDS=FALSE
>> );
>> ALTER TABLE "Raum"
>>  OWNER TO egon;
>> COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes
> Identifizierungsmerkmal für den Raum';
>> COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';
>> 
>> 
>> -- Index: "Raum_RaumID_idx"
>> 
>> -- DROP INDEX "Raum_RaumID_idx";
>> 
>> CREATE INDEX "Raum_RaumID_idx"
>>  ON "Raum"
>>  USING btree
>>  ("RaumID");
>> 
> But psql tells me "Raum" is not existent:
> 
>> egon@xfEinzel ~ $ psql Hausrat
>> psql (9.3.15)
>> Type "help" for help.
>> 
>> Hausrat=# SELECT * FROM Raum;
>> ERROR:  relation "raum" does not exist
>> LINE 1: SELECT * FROM Raum;
>>  ^
>> Hausrat=#
> 
> Why?
> 
> Egon
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
> 
> iQIbBAEBAgAGBQJYkJTwAAoJECc7nbY+bg5uiRQP9iC4UtbHpPvdvV796fxcMSFp
> dncPHzkTKHvcEh3V9t/Xn/BzEHBDAO6RO8jmU18Ja9f/0nOyNXrWxal0OJZXint5
> l3/qRKbekkl7zfogysh4XgZQkpWwsJcYDGoG5tCUQm8TJ3sCk9a9+mbkDhy0Vsev
> MPeyYl/fYvlTBkiRmlPZTOX7YjRzeryKXguB3PBke3Vo6SZ1sFWnMjJ7bc2b
> 4cW9hmInmwXZ4EBOfcUW4QnfM0mgHBMGxJwYVQfeC6fQeqT8emh0KQLqozjFe/tk
> KNKDU0RebcrBgXP/lIGI34XahZW+WOdLli/t8wBUNiINruY2FlizuH6Uuak3tLjC
> cD7vi0SzNK2YFr9Rozw8ow9WVxSfjWBLiOA1GkFdhxKb80NLHthzo8oIVaCqz0bj
> 71kA0ewgZ9NMay6ch1VjqSPPFhAZHc1Ho3xIAa0BsZpvEdccDBsL+yk/6DGDYua9
> 5oT1p6CZqfDJqxEIoUiNaJEKm3An5ySN8hHn527/apG9yA9QMh5qJPHA0wRqtLxN
> hNSxugKhS6UOw/Wivbx0OIhN8jqBv4m22UgO9pFGgxHLs1hheSTMUSbExFCLuK+z
> sS1Kw9syplk+lFTzK6mqNpr3BQ6v2fmkPmRTZoID4e9T3DY8Bna2JXG2U1QGEzwa
> kwpJOMAvY3DDPv3pIK8=
> =i8FY
> -END PGP SIGNATURE-
> 
> 
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Why is table not found?

2017-01-31 Thread Martijn Tonies (Upscene Productions)

Hello Egon,

You created the table using delimited identifiers:

"Raum"

which is not the same as

Raum of raum or RAUM

When you use delimited identifiers (eg: "MyTable" instead of MyTable), the
name becomes case sensitive.

When you use SQL, you need to use delimited identifiers:

select * from "Raum"



With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Database Workbench - developer tool for Oracle, MS SQL Server, PostgreSQL,
SQL Anywhere, MySQL, InterBase, NexusDB and Firebird.


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
find the the table. In sql field is shown:


-- Table: "Raum"

-- DROP TABLE "Raum";

CREATE TABLE "Raum"
(
  "RaumID" serial NOT NULL, -- Automatisch vergebenes

Identifizierungsmerkmal für den Raum

  "Raum" character varying(15), -- Bezeichnung des Raums
  CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
)
WITH (
  OIDS=FALSE
);
ALTER TABLE "Raum"
  OWNER TO egon;
COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes

Identifizierungsmerkmal für den Raum';

COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';


-- Index: "Raum_RaumID_idx"

-- DROP INDEX "Raum_RaumID_idx";

CREATE INDEX "Raum_RaumID_idx"
  ON "Raum"
  USING btree
  ("RaumID");


But psql tells me "Raum" is not existent:


egon@xfEinzel ~ $ psql Hausrat
psql (9.3.15)
Type "help" for help.

Hausrat=# SELECT * FROM Raum;
ERROR:  relation "raum" does not exist
LINE 1: SELECT * FROM Raum;
  ^
Hausrat=#


Why?

Egon

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIbBAEBAgAGBQJYkJTwAAoJECc7nbY+bg5uiRQP9iC4UtbHpPvdvV796fxcMSFp
dncPHzkTKHvcEh3V9t/Xn/BzEHBDAO6RO8jmU18Ja9f/0nOyNXrWxal0OJZXint5
l3/qRKbekkl7zfogysh4XgZQkpWwsJcYDGoG5tCUQm8TJ3sCk9a9+mbkDhy0Vsev
MPeyYl/fYvlTBkiRmlPZTOX7YjRzeryKXguB3PBke3Vo6SZ1sFWnMjJ7bc2b
4cW9hmInmwXZ4EBOfcUW4QnfM0mgHBMGxJwYVQfeC6fQeqT8emh0KQLqozjFe/tk
KNKDU0RebcrBgXP/lIGI34XahZW+WOdLli/t8wBUNiINruY2FlizuH6Uuak3tLjC
cD7vi0SzNK2YFr9Rozw8ow9WVxSfjWBLiOA1GkFdhxKb80NLHthzo8oIVaCqz0bj
71kA0ewgZ9NMay6ch1VjqSPPFhAZHc1Ho3xIAa0BsZpvEdccDBsL+yk/6DGDYua9
5oT1p6CZqfDJqxEIoUiNaJEKm3An5ySN8hHn527/apG9yA9QMh5qJPHA0wRqtLxN
hNSxugKhS6UOw/Wivbx0OIhN8jqBv4m22UgO9pFGgxHLs1hheSTMUSbExFCLuK+z
sS1Kw9syplk+lFTzK6mqNpr3BQ6v2fmkPmRTZoID4e9T3DY8Bna2JXG2U1QGEzwa
kwpJOMAvY3DDPv3pIK8=
=i8FY
-END PGP SIGNATURE-




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general 




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Why is table not found?

2017-01-31 Thread Raymond O'Donnell

On 31/01/17 13:45, Egon Frerich wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
find the the table. In sql field is shown:


-- Table: "Raum"

-- DROP TABLE "Raum";

CREATE TABLE "Raum"
(
  "RaumID" serial NOT NULL, -- Automatisch vergebenes

Identifizierungsmerkmal für den Raum

  "Raum" character varying(15), -- Bezeichnung des Raums
  CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
)
WITH (
  OIDS=FALSE
);
ALTER TABLE "Raum"
  OWNER TO egon;
COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes

Identifizierungsmerkmal für den Raum';

COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';


-- Index: "Raum_RaumID_idx"

-- DROP INDEX "Raum_RaumID_idx";

CREATE INDEX "Raum_RaumID_idx"
  ON "Raum"
  USING btree
  ("RaumID");


But psql tells me "Raum" is not existent:


egon@xfEinzel ~ $ psql Hausrat
psql (9.3.15)
Type "help" for help.

Hausrat=# SELECT * FROM Raum;
ERROR:  relation "raum" does not exist
LINE 1: SELECT * FROM Raum;


Object names are folded to lower-case automatically, unless you enclose 
them in double-quotes:


  select * from "Raum";

Ray.



--
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Why is table not found?

2017-01-31 Thread Egon Frerich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I created a db 'Hausrat' with a table "Raum". If I look in pgadmin I
find the the table. In sql field is shown:

> -- Table: "Raum"
>
> -- DROP TABLE "Raum";
>
> CREATE TABLE "Raum"
> (
>   "RaumID" serial NOT NULL, -- Automatisch vergebenes
Identifizierungsmerkmal für den Raum
>   "Raum" character varying(15), -- Bezeichnung des Raums
>   CONSTRAINT "Raum_pkey" PRIMARY KEY ("RaumID")
> )
> WITH (
>   OIDS=FALSE
> );
> ALTER TABLE "Raum"
>   OWNER TO egon;
> COMMENT ON COLUMN "Raum"."RaumID" IS 'Automatisch vergebenes
Identifizierungsmerkmal für den Raum';
> COMMENT ON COLUMN "Raum"."Raum" IS 'Bezeichnung des Raums';
>
>
> -- Index: "Raum_RaumID_idx"
>
> -- DROP INDEX "Raum_RaumID_idx";
>
> CREATE INDEX "Raum_RaumID_idx"
>   ON "Raum"
>   USING btree
>   ("RaumID");
>
But psql tells me "Raum" is not existent:

> egon@xfEinzel ~ $ psql Hausrat
> psql (9.3.15)
> Type "help" for help.
>
> Hausrat=# SELECT * FROM Raum;
> ERROR:  relation "raum" does not exist
> LINE 1: SELECT * FROM Raum;
>   ^
> Hausrat=#

Why?

Egon

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIbBAEBAgAGBQJYkJTwAAoJECc7nbY+bg5uiRQP9iC4UtbHpPvdvV796fxcMSFp
dncPHzkTKHvcEh3V9t/Xn/BzEHBDAO6RO8jmU18Ja9f/0nOyNXrWxal0OJZXint5
l3/qRKbekkl7zfogysh4XgZQkpWwsJcYDGoG5tCUQm8TJ3sCk9a9+mbkDhy0Vsev
MPeyYl/fYvlTBkiRmlPZTOX7YjRzeryKXguB3PBke3Vo6SZ1sFWnMjJ7bc2b
4cW9hmInmwXZ4EBOfcUW4QnfM0mgHBMGxJwYVQfeC6fQeqT8emh0KQLqozjFe/tk
KNKDU0RebcrBgXP/lIGI34XahZW+WOdLli/t8wBUNiINruY2FlizuH6Uuak3tLjC
cD7vi0SzNK2YFr9Rozw8ow9WVxSfjWBLiOA1GkFdhxKb80NLHthzo8oIVaCqz0bj
71kA0ewgZ9NMay6ch1VjqSPPFhAZHc1Ho3xIAa0BsZpvEdccDBsL+yk/6DGDYua9
5oT1p6CZqfDJqxEIoUiNaJEKm3An5ySN8hHn527/apG9yA9QMh5qJPHA0wRqtLxN
hNSxugKhS6UOw/Wivbx0OIhN8jqBv4m22UgO9pFGgxHLs1hheSTMUSbExFCLuK+z
sS1Kw9syplk+lFTzK6mqNpr3BQ6v2fmkPmRTZoID4e9T3DY8Bna2JXG2U1QGEzwa
kwpJOMAvY3DDPv3pIK8=
=i8FY
-END PGP SIGNATURE-




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] using hstore to store documents

2017-01-31 Thread Rita
I think Xpath in postgresql is fast enough. I am dumping the raw xml file
into a table and then generating data from it. I want all the data to be
consistent thats why I am using a database.

I am planning to use triggers to generate content of
table1_master...table2_master, etc...

master -> table 1_master
-> table 2_master
-> table 3_master ->   table 1_table3




On Sun, Jan 29, 2017 at 9:45 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Saturday, January 28, 2017, Rita  wrote:
>
>> After xmltest has been populated, I can run xpath and unest to get my
>> data into a row but I would like to store that result in another table, I
>> am guessing I should look into triggers for something like that?
>>
>
> I suspect that using xpath in the database is not the right tool for doing
> what you describe.  Whatever middleware layer receives the XML should be
> considered for the logic of deserialization and storage to the database in
> normalized form.  If you do want something like that in the database I'd
> probably write a volatile function the receives xml and does whatever it
> needs to do.  I cannot imagine the indirection of a trigger would be
> gainful here.
>
> In particular, at scale you'd probably be better off with using
> a streaming parser instead of a DOM one.
>
> David J.




-- 
--- Get your facts first, then you can distort them as you please.--


Re: [GENERAL] Causeless CPU load waves in backend, on windows, 9.5.5 (EDB binary).

2017-01-31 Thread Nikolai Zhubr

31.01.2017 10:37, I wrote:

[...]

1. "select localtimestamp" 40 times (As separate requests, one by
one, but
no delay inserted in between)
2. wait 1/2 second.
3. goto 1


Craig, could this be a side-effect of 519b0757? That's new in 9.5, and
that's directly related to the code paths discussed here.


Meanwhile I'll redo my tests using 9.4 instead of 9.5 and report back.


Exactly same trouble with 9.4 (Specifically EDB 9.4.10-1 win32)

Would it make sense to check some even older ones?


Thank you.

Nikolai



Thank you.

Nikolai






--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general