Re: [GENERAL] CREATE SYNONYM in PostgreSQL

Thank you for replay. >You will not be able to do it without modifying the grammar. SYNONYM >isn't even a keyword in stock PG. If I understood correctly since SYNONYM is not the part of the grammar, the parser throw a syntax error before reaching to hook. - Regards, Vinayak, -- View this

Re: [GENERAL] permission denied for schema topology

Thanks Tom and everyone that replied. Since my last email my service provider managed to solve the problem on my main database. I looked at the schemas listed in phpPgAdmin on this database before it was fixed and there were two main schemas listed, "public" and "topology", both owned by postgres.

Re: [GENERAL] PostgreSQL Portable

Hi Craig, On Fri, 12 Sep 2014 11:33:55 +0800, Craig Ringer wrote: >On 09/11/2014 03:16 PM, George Neuner wrote: >> >> If the driver permits it and you [or your users] can be trusted to >> perform a safe unmount via the OS *before* disconnecting the device, >> then you can enable write caching f

Re: [GENERAL] PostgreSQL Portable

Hey, I had many external hard drive crash (savage unplug, power off, pc forced restart). The server on the virtual machine was never hurt, nor the data. Cheers, Rémi-C 2014-09-12 15:34 GMT+02:00 George Neuner : > Hi Craig, > > On Fri, 12 Sep 2014 11:33:55 +0800, Craig Ringer > wrote: > > >On 09

Re: [GENERAL] Regarding timezone

On 09/11/2014 10:59 PM, Dev Kumkar wrote: On Wed, Sep 10, 2014 at 8:43 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: You'd want to get a new version of the IANA timezone database files for that. Depending on what packaging you're using, this might be an operating-system update no

Re: [GENERAL] permission denied for schema topology

On 09/12/2014 02:27 AM, Iain Mott wrote: Thanks Tom and everyone that replied. Since my last email my service provider managed to solve the problem on my main database. I looked at the schemas listed in phpPgAdmin on this database before it was fixed and there were two main schemas listed, "publi

[GENERAL] 2 left joins causes seqscan

Hi, Today i ran into a situation where a second left join on an indexed field would prevent the index from being used, even though the index is clearly more efficient. Removing either of the 2 joins would cause that the planner will use the index again. I tested this on postgres 9.1 and 9.3 on my

Re: [GENERAL] 2 left joins causes seqscan

Willy-Bas Loos wrote: > As you can see, the second query is far more efficient, even > though it scans both tables twice to combine the results. But the two queries don't return the same results. Of course the second one will be faster. The simple equivalent of your second query is: explain a