On Thursday, May 24, 2012 08:12:56 PM Josh Berkus wrote:
> > Yes, we do. It would be best to conclude that things I do on hackers
> > relate in some way to those goals, even if it isn't immediately clear
> > how.
> See, now you've got me all curious. How does inter-DB queries relate to
> the New R
> Yes, we do. It would be best to conclude that things I do on hackers
> relate in some way to those goals, even if it isn't immediately clear
> how.
See, now you've got me all curious. How does inter-DB queries relate to
the New Replication?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexp
On May24, 2012, at 11:39 , Susanne Ebrecht wrote:
> There are lots of offices / departments creating maps. Topography maps,
> pipeline maps, nature conservancy (e.g. where are the nests from endangered
> birds?), mineral resources, wire maps, street maps, bicycle / jogging maps,
> tourists maps, tr
Am 22.05.2012 15:27, schrieb Albe Laurenz:
If you need different applications to routinely access each other's
tables, why not assign them to different schemas in one database?
I just saw another use case here.
There are lots of offices / departments creating maps. Topography maps,
pipeline ma
On May 23, 2012, at 1:55 PM, Simon Riggs wrote:
>> Well, I *will* point out that you have your work cut out for you on 9.3
>> already ...
>
> Yes, we do. It would be best to conclude that things I do on hackers
> relate in some way to those goals, even if it isn't immediately clear
> how.
Simon
On 23 May 2012 21:15, Josh Berkus wrote:
>> However, given sufficient people speaking against it, I'll leave this idea.
>
> Well, I *will* point out that you have your work cut out for you on 9.3
> already ...
Yes, we do. It would be best to conclude that things I do on hackers
relate in some wa
Simon,
> However, given sufficient people speaking against it, I'll leave this idea.
Well, I *will* point out that you have your work cut out for you on 9.3
already ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On tis, 2012-05-22 at 18:00 +0200, Susanne Ebrecht wrote:
> CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a
> level and do it by creating a database.
>
> I would like to get default collation per schema / table in 9.2 or 9.3
> but that is my personal wish,
Another way I've been
> That's only true if you try to satisfy both goals at once, which I'm
> not suggesting. So I believe that proposition to be false.
Oh, ok. Per your original email and follow-up arguments, you seemed to
be doing just that.
>> An alternative idea -- and one which could be deployed a lot faster -
On 22 May 2012 18:56, Josh Berkus wrote:
> I'm not arguing that we don't have users who would like interdatabase
> queries, especially when they port applications from MySQL or MSSQL. We
> have a lot of such users.
Lots and lots, yes.
> However, we *also* have a lot of users who
> would like t
On Tue, May 22, 2012 at 10:56 AM, Josh Berkus wrote:
> I'm not arguing that we don't have users who would like interdatabase
> queries, especially when they port applications from MySQL or MSSQL. We
> have a lot of such users. However, we *also* have a lot of users who
> would like to treat sepa
> Why is it OK to allow somebody to access multiple schema in one query,
> but not multiple databases? Are you arguing that schemas are also
> broken?
Because the purpose of a database is to be a Catalog, i.e. an isolated
container, which is not the purpose of schemas. To the extent to which
we
On Tue, May 22, 2012 at 10:43 AM, Simon Riggs wrote:
> On 22 May 2012 18:35, Josh Berkus wrote:
>>
>>> If I have a customer with 1 database per user, how do they run a query
>>> against 100 user tables? It would require 100 connections to the
>>> database. Doing that would require roughly x100 th
On Tue, May 22, 2012 at 1:27 PM, Simon Riggs wrote:
> Ack, part from the bit about OIDs no longer being unique. That might
> be an upgrade issue but its obviously something we wouldn't allow if
> we did that.
And how exactly are you going to disallow that? We currently enforce
the uniqueness of
On 22 May 2012 18:35, Josh Berkus wrote:
>
>> If I have a customer with 1 database per user, how do they run a query
>> against 100 user tables? It would require 100 connections to the
>> database. Doing that would require roughly x100 the planning time and
>> x100 the connection delay. Larger SQL
> If I have a customer with 1 database per user, how do they run a query
> against 100 user tables? It would require 100 connections to the
> database. Doing that would require roughly x100 the planning time and
> x100 the connection delay. Larger SQL statements pass their results
> between execut
On 22 May 2012 18:18, Josh Berkus wrote:
>
>> 1. Ability to have a Role that can only access one Database
>>
>> 2. Allow user info to be dumped with a database, to make a db
>> completely self-consistent
>>
>> 3. Allow databases to be transportable
>>
>> 4. Allow users to access tables in >1 datab
On 22 May 2012 14:05, Robert Haas wrote:
> On Tue, May 22, 2012 at 8:40 AM, Andrew Dunstan wrote:
>> That seems to be leaving aside the fact that we don't currently have any
>> notion of how to allow FDWs to write the foreign tables.
>>
>> What is more, isn't the postgres FDW about talking to any
> 1. Ability to have a Role that can only access one Database
>
> 2. Allow user info to be dumped with a database, to make a db
> completely self-consistent
>
> 3. Allow databases to be transportable
>
> 4. Allow users to access tables in >1 database easily, with appropriate
> rights.
The las
On May22, 2012, at 18:00 , Susanne Ebrecht wrote:
> Am 22.05.2012 17:42, schrieb Tom Lane:
>> Encoding yes, but since 9.1 we have pretty fine-grained control of
>> collation. So I think this argument is a lot weaker than it used
>> to be. It would only really apply if you have one of the corner
>
On Tue, May 22, 2012 at 12:00 PM, Susanne Ebrecht
wrote:
> Usually you want to set the collation once per language schema. E.g. schema
> russian gets Russian collation and schema British gets British collation and
> so on.
>
> CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a level
Am 22.05.2012 17:42, schrieb Tom Lane:
Encoding yes, but since 9.1 we have pretty fine-grained control of
collation. So I think this argument is a lot weaker than it used
to be. It would only really apply if you have one of the corner
cases where utf8 doesn't work for you.
Yeah it got better
Susanne Ebrecht writes:
> The use case in my mind for accessing more databases is when you want to
> access stuff different languages.
> You only can set encoding / LC_Collate per database not per schema.
> So for different languages you might need different databases to do
> correct sorting /
Am 22.05.2012 15:27, schrieb Albe Laurenz:
If you need different applications to routinely access each other's
tables, why not assign them to different schemas in one database?
The use case in my mind for accessing more databases is when you want to
access stuff different languages.
You only c
Simon Riggs wrote:
> On 21 May 2012 20:40, Stephen Frost wrote:
>
>>> This is important. I like the idea of breaking down the barriers
>>> between databases to allow it to be an option for one backend to
>>> access tables in multiple databases.
> So collecting a few requirements from various pla
On Tue, May 22, 2012 at 8:40 AM, Andrew Dunstan wrote:
> That seems to be leaving aside the fact that we don't currently have any
> notion of how to allow FDWs to write the foreign tables.
>
> What is more, isn't the postgres FDW about talking to any postgres source?
> If so, does it have special
On 05/22/2012 07:56 AM, Robert Haas wrote:
On Tue, May 22, 2012 at 7:35 AM, Florian Pflug wrote:
* Allow users to access tables in>1 database easily, with appropriate rights.
That one I'm very sceptical about. In the long run, I think we want better
separation of databases, not less, and thi
On May22, 2012, at 13:47 , Simon Riggs wrote:
> On 22 May 2012 12:35, Florian Pflug wrote:
>>> * Allow users to access tables in >1 database easily, with appropriate
>>> rights.
>>
>> That one I'm very sceptical about. In the long run, I think we want better
>> separation of databases, not less,
On 22/05/12 13:47, Simon Riggs wrote:
On 22 May 2012 12:35, Florian Pflug wrote:
* Allow users to access tables in>1 database easily, with appropriate rights.
That one I'm very sceptical about. In the long run, I think we want better
separation of databases, not less, and this requirement carr
On 22/05/12 13:24, Simon Riggs wrote:
On 22 May 2012 12:05, José Luis Tallón wrote:
IMVHO: s/database/schema/g does resolve many of the problems that you were
referring to... and 'dblink' should solve the rest, right?
Please, feel free to point out what I am (most probably) not considering --
On Tue, May 22, 2012 at 7:35 AM, Florian Pflug wrote:
>> * Allow users to access tables in >1 database easily, with appropriate
>> rights.
>
> That one I'm very sceptical about. In the long run, I think we want better
> separation of databases, not less, and this requirement carries a huge risk
>
On 22 May 2012 12:35, Florian Pflug wrote:
>> * Allow users to access tables in >1 database easily, with appropriate
>> rights.
>
> That one I'm very sceptical about. In the long run, I think we want better
> separation of databases, not less, and this requirement carries a huge risk
> of standi
On May22, 2012, at 11:46 , Simon Riggs wrote:
> * Ability to have a Role that can only access one Database
>
> * Allow user info to be dumped with a database, to make a db
> completely self-consistent
These two could be achieved by having database-local roles I think.
> * Allow databases to be t
On 22 May 2012 12:05, José Luis Tallón wrote:
> IMVHO: s/database/schema/g does resolve many of the problems that you were
> referring to... and 'dblink' should solve the rest, right?
> Please, feel free to point out what I am (most probably) not considering --
> not experienced enough yet :)
T
On 22/05/12 11:46, Simon Riggs wrote:
On 21 May 2012 20:40, Stephen Frost wrote:
This is important. I like the idea of breaking down the barriers
between databases to allow it to be an option for one backend to
access tables in multiple databases. The current mechanism doesn't
actually prevent
On 21 May 2012 20:40, Stephen Frost wrote:
>> This is important. I like the idea of breaking down the barriers
>> between databases to allow it to be an option for one backend to
>> access tables in multiple databases. The current mechanism doesn't
>> actually prevent looking at data from other d
36 matches
Mail list logo
