[SQL] WITH RECURSIVE: ARRAY[id] All column datatypes must be hashable
Hello I try to build a SQL for isolating hole pedigrees/families form a table with persons. Each person may have father_id and mother_id set to their parents as foreign keys on the same persons table. I was inspired by http://akretschmer.blogspot.com/2008/10/waiting-for-84.html and I tryed to develop the idea further to isolate the hole family of a given person, not only his direct parents or children. Despite the terrible bloating of the SQL... it works as long as no consanguinity will be encountered, else the SQL runs in an endless loop. I tryed to apply the trick with "path and cycle" from the "Postgresql 8.4 Documentation" whether we have reached the same row again while following a particular path of links. We add two columns path and cycle to the loop-prone query: WITH RECURSIVE search_graph(id, link, data, depth, path, cycle) AS ( SELECT g.id, g.link, g.data, 1, ARRAY[g.id],false FROM graph g UNION ALL SELECT g.id, g.link, g.data, sg.depth + 1, path || g.id, g.id = ANY(path) FROM graph g, search_graph sg WHERE g.id = sg.link AND NOT cycle ) SELECT * FROM search_graph; However it doesn't works like this: WITH RECURSIVE person (id,name,father_id,mother_id,level,path,cycle) AS ( SELECT f.id, f.name, f.father_id, f.mother_id, 0, ARRAY[f.id], false FROM pedigree f I get: ERROR: could not implement recursive UNION DETAIL: All column datatypes must be hashable. ** Error ** ERROR: could not implement recursive UNION SQL state: 0A000 Detail: All column datatypes must be hashable. It works without the ARRAY... I would very appreciate any help, then I couldn't find anything on the net about "All column datatypes must be hashable", excepting the postgresql sources... Thanks rawi -- View this message in context: http://www.nabble.com/WITH-RECURSIVE%3A-ARRAY-id--All-column-datatypes-must-be-hashable-tp25167538p25167538.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
re[SQL] solved: WITH RECURSIVE: ARRAY[id] All column datatypes must be hashable
me again... I figured it out... The Error was caused because I used UNION in place of UNION ALL. I still don't understand why the ARRAY (path) could not be grouped... Bye rawi -- View this message in context: http://www.nabble.com/WITH-RECURSIVE%3A-ARRAY-id--All-column-datatypes-must-be-hashable-tp25167538p25168751.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] hopeless, SQL not resolved yet
Thank you very much for the answer! No, I'm not that good... I got finally a fully kinky SQL, which resolves nothing and runs endless for a couple of test records... I think, it would be better to open for this matter a new thread... Regards Rawi -- View this message in context: http://www.nabble.com/WITH-RECURSIVE%3A-ARRAY-id--All-column-datatypes-must-be-hashable-tp25167538p25190245.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
re[SQL] cursively isolate pedigrees, based only on person_id, mother_id and father_id
Hello! Given a table "persons", where the individuals are bound to each other only via the foreign keys mother_id and father_id as self joins on persons, like that create table persons ( id serial primary key, sex character(1), father_id integer default null references persons(id) on update cascade on delete set null, mother_id integer default null references persons(id) on update cascade on delete set null ); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(1,'m',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(2,'f',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(8,'m',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(9,'f',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(3,'m',1,2); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(4,'f',8,9); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(5,'f',3,4); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(6,'m',3,4); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(7,'m',8,9); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(10,'m',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(11,'m',10,5); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(12,'f',7,5); -- consanguinity INSERT INTO persons(id, sex, father_id,mother_id) VALUES(100,'m',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(200,'f',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(300,'m',100,200); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(400,'f',null,null); INSERT INTO persons(id, sex, father_id,mother_id) VALUES(500,'f',300,400); These would be the graphs of the 2 families: http://www.nabble.com/file/p25191664/family1.jpg http://www.nabble.com/file/p25191664/family2.jpg I hoped to find a recursive SQL or function, which would extract the WHOLE family of any given person.id from the table with many families. After failing to accomplish this with a recursive SQL I found on the web an advice from Celko (???) http://www.eggheadcafe.com/conversation.aspx?messageid=29498840&threadid=29498808 to better keep away form such things... :( Did someone gathered a closer expertise to that? Thank you very much for any hint! Regards Rawi -- View this message in context: http://www.nabble.com/recursively-isolate-pedigrees%2C-based-only-on-person_id%2C-mother_id-and-father_id-tp25191664p25191664.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Hibernate, web application and only one sequence for all primary keys
Hello! The subject says it... Grails/Hibernate wishes per default one sequence for all tables-PKs and all PKs as BigInt. What would you think about a database with some tens of tables and incidentally low to moderate insert concurrency spread in about the half of the tables from at most 10 concurrent users with some 10-20 inserts each? And (for the eventuality of an unexpected need to scale up in the future - e.g. integration of multiple databases), from about which size would you expect performance penalties due to the sole sequence and the BigInt-PKs? I first intend to deploy it on an Intel Pentium 2 Duo (2.5-2.8GHz) with 3 GB RAM and SATA hard disk under Ubuntu Server. Thank you very much in advance! Regards Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25490498.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Hibernate, web application and only one sequence for all primary keys
SORRY for incorrectly posting this here! I couldn't move it to PostgreSQL - performance... afterwards. While I don't want to double-post: It would be perfect, if the mail list admin - please - could correct my mistake... Regards, Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25490895.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Hibernate, web application and only one sequence for all primary keys
Tom Lane-2 wrote: > >> Grails/Hibernate wishes per default one sequence for all tables-PKs and >> all >> PKs as BigInt. > > Redesign that software; this is fundamentally broken and stupid. > Thank you Tom... but redesigning Grails and Hibernate is far beyond my possibilities :) I could work around this in my app and explicitly ask Hibernate to use my hand made sequences in PostgreSQL. While this asks me for some more definition work, I wanted to know, if this is worth the effort... I know it now, thanks :) Kind regards, Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25491915.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Hibernate, web application and only one sequence for all primary keys
Leo Mannhart wrote: > > Caveat: If you use the standard sequence generator in hibernate, it is > not using the postgres-sequence in the "usual" manner. hibernate itself > caches 50 ID's as sequence numbers by default. This means, hibernate > only does a select on the database sequence every 50 numbers. it > multyplies the database sequence by 50 to get the "real" sequence > number. it generates the sequence numbers in blocks of 50 numbers or > according to the sequence cache size. > That said, you would probably not see any performance bottlenecks > because of the sequence number generator in the database, even with > thousands of inserts per second. > Hi Leo, thank you for the explanation! I don't know if it is that cool to lose up to 50 IDs on each session-end of Hibernate... And what do you suppose it would happen, if I set the cache size of Hibernate's own sequence (after generation) by hand to 1 instead of 50? I wouldn't need tausends of inserts per second... Kind regards, Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25491924.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Hibernate, web application and only one sequence for all primary keys
Tom Lane-2 wrote: > >> Grails/Hibernate wishes per default one sequence for all tables-PKs and >> all >> PKs as BigInt. > > Redesign that software; this is fundamentally broken and stupid. > Hi Tom, its me again... I only need to further understand... What for a source did have the OIDs in the past, as they were standard in each table? I thought they have been also generated by an unique sequence? Regards, Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25491931.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Thank you all for your help...
I appreciate very much your opinions. They'll help me to adjust my approach to this problem. As I meant, it wouldn't be "cool" to have hibernate hoarding 50 ids, I didn't mean the id-gaps and id-loss, that's no problem, but also to lose the timely clear id alignment in the case of parallel access of the database with another application... Sure, I'll have timestamps vor that, but... :) Finally I'll go - certainly - with one sequence per PK. Thanks Kind regards, Rawi -- View this message in context: http://www.nabble.com/Hibernate%2C-web-application-and-only-one-sequence-for-all-primary-keys-tp25490498p25504364.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] kind of RULE on SELECT depending on existence of a WHERE condition
Hi please help me with the following scenario: I'd gladly have all persons (contacts, customers, staff etc) in one table "people" with some distinctive flags. My reason for this, is that simple contacts could become customers or even staff, staff members could be in the same time also customers etc and I would be glad to manage all the data in one table to avoid the same Person-Record in three tables. Now, the SELECTs would be generated from an application (hibernate) automatically inserting some WHERE condition on the flags of the recorded people depending on the rights of the user. Some isn't allowed to see staff, an other shouldn't see customers etc. But - for the case, that an application-programmer or even I (tired, middle in the night) forget to program the insertion of the needed limiting WHERE condition - it would be great to have some sort of rule ON SELECT, so a SELECT without WHERE on the flags would return NOTHING. Is there a way to achieve this? Thank you for reading and hoping my problem can be solved. Rawi -- View this message in context: http://old.nabble.com/kind-of-RULE-on-SELECT-depending-on-existence-of-a-WHERE-condition-tp27741669p27741669.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] kind of RULE on SELECT depending on existence of a WHERE condition
> Not quite the way you suggest. You could build a series of views with > the WHERE conditions built in to them, and grant permissions on those > though. Thank you very much for your help. Unfortunately is this not what I hoped... The permissions will be granted dynamic by the application out of the user-records and expressed in the WHERE flags. I'll need another approach... Cheers, Rawi -- View this message in context: http://old.nabble.com/kind-of-RULE-on-SELECT-depending-on-existence-of-a-WHERE-condition-tp27741669p27742718.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] kind of RULE on SELECT depending on existence of a WHERE condition
Richard Huxton wrote: > > You could write a set-returning function that takes either: > 1. A list of conditions > 2. The text for a WHERE clause > If it gets no conditions or a blank string, it returns nothing. > You will need to create the function with SECURITY DEFINER permissions, > That's a very good suggestion. I've just red about SECURITY DEFINER... great. Thanks -- View this message in context: http://old.nabble.com/kind-of-RULE-on-SELECT-depending-on-existence-of-a-WHERE-condition-tp27741669p27753818.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Index Usage and Running Times by FullTextSearch with prefix matching
Hi
I tested the following:
CREATE TABLE t1
(
id serial NOT NULL,
a character varying(125),
a_tsvector tsvector,
CONSTRAINT t1_pkey PRIMARY KEY (id)
);
INSERT INTO t1 (a, a_tsvector)
VALUES ('o,p,f,j,z,j',
to_tsvector('o,p,f,j,z,j');
CREATE INDEX a_tsvector_idx ON t1 USING gin (a_tsvector);
(I have generated 90 records with random words like this)
Now querying: normal full text search
SELECT count(a)
FROM t1
WHERE a_tsvector @@ to_tsquery('a & b & c & d')
(RESULT: count: 619)
Total query runtime: 353 ms.
Query Plan:
"Aggregate (cost=6315.22..6315.23 rows=1 width=36)"
" -> Bitmap Heap Scan on t1 (cost=811.66..6311.46 rows=1504 width=36)"
"Recheck Cond: (a_tsvector @@ to_tsquery('a & b & c &
d'::text))"
"-> Bitmap Index Scan on a_tsvector_idx (cost=0.00..811.28
rows=1504 width=0)"
" Index Cond: (a_tsvector @@ to_tsquery('a & b & c
& d'::text))"
And querying: FTS with prefix matching:
SELECT count(a)
FROM t1
WHERE a_tsvector @@ to_tsquery('aaa:* & b:* & c:* & d:*')
(RESULT: count: 619)
Total query runtime: 21266 ms.
Query Plan:
"Aggregate (cost=804.02..804.03 rows=1 width=36)"
" -> Bitmap Heap Scan on t1 (cost=800.00..804.02 rows=1 width=36)"
"Recheck Cond: (a_tsvector @@ to_tsquery('aaa:* & b:* & c:* &
d:*'::text))"
"-> Bitmap Index Scan on a_tsvector_idx (cost=0.00..800.00 rows=1
width=0)"
" Index Cond: (a_tsvector @@ to_tsquery('aaa:* & b:* & c:* &
d:*'::text))"
I don't understand the big query time difference, despite the explainig
index usage.
NOnetheless I'd like to simulate LIKE 'aaa%' with full text search. Would I
have a better sollution?
Many thanks in advance!
Rawi
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-Usage-and-Running-Times-by-FullTextSearch-with-prefix-matching-tp5759021.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
--
Sent via pgsql-sql mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Re: Index Usage and Running Times by FullTextSearch with prefix matching
Tom Lane-2 wrote > FWIW, I get fairly decent performance for cases like this in HEAD > (at least with a GIN index; GIST seems much less able to do well with > short prefixes). What PG version are you testing? Thank you Tom, I'm testing on PG 9.1 on UbuntuServer 12.10, 64bit I'll update to 9.2 the next days and try again. Kind Regards Rawi -- View this message in context: http://postgresql.1045698.n5.nabble.com/Index-Usage-and-Running-Times-by-FullTextSearch-with-prefix-matching-tp5759021p5759045.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Re: Index Usage and Running Times by FullTextSearch with prefix matching
Tom Lane-2 wrote
> FWIW, I get fairly decent performance for cases like this in HEAD
> (at least with a GIN index; GIST seems much less able to do well with
> short prefixes).
Short or long prefixes seem to be equaly unfavorable. Even with the full
length of the words, but queried as prefix I get a runtime of 25342ms
compared to 353ms without prefixes:
SELECT count(a)
FROM t1
WHERE a_tsvector @@ to_tsquery('a:* & b:* & c:* & d:*')
Total query runtime: 25342 ms
"Aggregate (cost=804.02..804.03 rows=1 width=36)"
" -> Bitmap Heap Scan on t1 (cost=800.00..804.02 rows=1 width=36)"
"Recheck Cond: (a_tsvector @@ to_tsquery('a:* & b:* &
c:* & d:*'::text))"
"-> Bitmap Index Scan on a_tsvector_idx (cost=0.00..800.00 rows=1
width=0)"
" Index Cond: (a_tsvector @@ to_tsquery('a:* & b:* &
c:* & d:*'::text))"
Kind Regards
Rawi
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-Usage-and-Running-Times-by-FullTextSearch-with-prefix-matching-tp5759021p5759046.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
--
Sent via pgsql-sql mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
[SQL] apt.postgresql.org vs. Pitti PPA - install error
Working on Ubuntu 13.04 64bit (raring) I red, that Pitti-PPA will be discontinued in the future, so we should make the switch to apt.postgresql.org. But trying to "aptitude install postgresql-9.3" (and with 9.2 - the same) I get an install error: The following packages have unmet dependencies: postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is installed. Going back to the Pitti PPA I could install pg-9.2 without problems (there will be no 9.3 in there) Regards Rawi -- View this message in context: http://postgresql.1045698.n5.nabble.com/apt-postgresql-org-vs-Pitti-PPA-install-error-tp5759622.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] apt.postgresql.org vs. Pitti PPA - install error
/etc/apt/sources.list.d/apt_postgresql_org.list: deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main 9.3 (for 9.2 also tryed only 'deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main') lsb_release -c Codename: raring but there is no repository for raring... so I took then the precise one... Thank you! Regards, Rawi -- View this message in context: http://postgresql.1045698.n5.nabble.com/apt-postgresql-org-vs-Pitti-PPA-install-error-tp5759622p5759636.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Re: Index Usage and Running Times by FullTextSearch with prefix matching
rawi wrote > > Tom Lane-2 wrote >> FWIW, I get fairly decent performance for cases like this in HEAD >> (at least with a GIN index; GIST seems much less able to do well with >> short prefixes). What PG version are you testing? > Thank you Tom, > > I'm testing on PG 9.1 on UbuntuServer 12.10, 64bit > > I'll update to 9.2 the next days and try again. > > Kind Regards > Rawi Just tested with 9.2: pretty much the same -- View this message in context: http://postgresql.1045698.n5.nabble.com/Index-Usage-and-Running-Times-by-FullTextSearch-with-prefix-matching-tp5759021p5759645.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] Re: Index Usage and Running Times by FullTextSearch with prefix matching
Tom Lane-2 wrote
> rawi <
> only4com@
> > writes:
>> And querying: FTS with prefix matching:
>
>> SELECT count(a)
>> FROM t1
>> WHERE a_tsvector @@ to_tsquery('aaa:* & b:* & c:* & d:*')
>
>> (RESULT: count: 619)
>> Total query runtime: 21266 ms.
>
> FWIW, I get fairly decent performance for cases like this in HEAD
> (at least with a GIN index; GIST seems much less able to do well with
> short prefixes). What PG version are you testing?
Last tests with PG 9.2:
Whereas the "whole words" full text search stays at ~350ms for 900,000
records I tryed the number of records, which are becoming to make one
suffer, querying for prefixes:
RECORDS RUNTIME (ms)
10,000 13
100,000 81
200,000 172
400,000 7,284
900,000 20,888
Regards, Rawi
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Index-Usage-and-Running-Times-by-FullTextSearch-with-prefix-matching-tp5759021p5760297.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
--
Sent via pgsql-sql mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] apt.postgresql.org vs. Pitti PPA - install error
Sorry for bumping the thread... ... but I'd like to install now finally postgresql 9.3 - and it doesn't work. Same conditions: Ubuntu 13.04 64bit (raring) /etc/apt/sources.list.d/apt_postgresql_org.list contains: deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main lsb_release -c Codename: raring Same fault: The following packages have unmet dependencies: postgresql-common : Breaks: logrotate (>= 3.8) but 3.8.3-3ubuntu2 is installed So, how to install the 9.3 precise-version on raring? Thanks in advance! Regards Rawi -- View this message in context: http://postgresql.1045698.n5.nabble.com/apt-postgresql-org-vs-Pitti-PPA-install-error-tp5759622p5770437.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] apt.postgresql.org vs. Pitti PPA - install error
> So either you try to compile your own binary packages > from the source packages or you download the postgresql-common .deb > and try to forcly install it (man pkg, dpkg --force-help, dpkg > --force-breaks). Jan, thank you, but both alternatives are - for me - not secure. So I hoped, that Pitti (once again) would support 9.3 in his repository. Then the precise-version 9.2 from his PPA is doing very well on raring. Or alternatively here, the dependency constraint in postgresql-common would be widened; then I doubt that logrotate in raring could have less functionality than in precise. But I'm no pro, so I have no real insider look; That's why I'll have to wait. Regards, Rawi -- View this message in context: http://postgresql.1045698.n5.nabble.com/apt-postgresql-org-vs-Pitti-PPA-install-error-tp5759622p5770447.html Sent from the PostgreSQL - sql mailing list archive at Nabble.com. -- Sent via pgsql-sql mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
