Alvaro Herrera wrote:
> Would it be possible to dump USING as an equivalent ON condition
> on output (nodeToString), and then examine simple ON conditions to
> turn them into USING conditions on input (stringToNode)?
You know, I'm not necessarily against some warning that a USING
clause in a v
Excerpts from Tom Lane's message of vie jun 03 10:59:00 -0400 2011:
> I'm inclined to write this off as "so don't do that". There's nothing
> that pg_dump can do to make this work: it has to use the USING syntax
> for the join, and that doesn't offer any way to qualify the column name
> on just o
On Fri, Jun 3, 2011 at 10:42 AM, Jehan-Guillaume (ioguix) de Rorthais
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6051
> Logged by: Jehan-Guillaume (ioguix) de Rorthais
> Email address: j...@dalibo.com
> PostgreSQL version: 9.1beta1
> Operating system
Robert Haas writes:
> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
>> Now, if the query doesn't involve any explicit reference to "joinalias.*",
>> we could probably fake it with some ugly thing involving
>> COALESCE(leftcol, rightcol) ... but I don't think people will want to
>> read that, an
On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane wrote:
>>> Personally my advice is to avoid USING: it wasn't one of the SQL
>>> committee's better ideas.
>
>> I don't understand why we can't just translate the USING into some
>>
I understood that USING is not a cool thing to use inside views, will avoid
it.
Still gonna use it in reports and applications, since there is no risk to
affect backups and raises an error.
It would be nice to had an NOTICE or WARNING about the USING clause inside
VIEWs, saying that it's not reco
"Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Personally my advice is to avoid USING: it wasn't one of the SQL
>>> committee's better ideas.
> There's no query you can write with USING that you can't write in a
> longer form with ON; but a query of moderate complexity can become
> significant
Robert Haas wrote:
> Tom Lane wrote:
>> Personally my advice is to avoid USING: it wasn't one of the SQL
>> committee's better ideas.
>
> I don't understand why we can't just translate the USING into some
> equivalent construct that doesn't involve USING. I proposed that
> a while ago and you
Robert Haas writes:
> On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane wrote:
>> Personally my advice is to avoid USING: it wasn't one of the SQL
>> committee's better ideas.
> I don't understand why we can't just translate the USING into some
> equivalent construct that doesn't involve USING.
There i
Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
> > (4) It strikes me that it might be possible to address this problem a
> > bit more cleanly by allowing mdnblocks() and smgrnblocks() and
> > RelationGetNumberOfBlocksInF
On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane wrote:
> "Daniel Cristian Cruz" writes:
>> CREATE TABLE a (
>> id_a serial primary key,
>> v text
>> );
>> CREATE TABLE b (
>> id_b serial primary key,
>> id_a integer REFERENCES a (id_a),
>> v text
>> );
>> CREATE TABLE c (
>> id_c serial primary k
On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:34 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Excerpts from Euler Taveira de Oliveira's message of jue may 26 12:00:05
>>> -0400 2011:
I think we should emit the real cause in those cases, if possible (n
The following bug has been logged online:
Bug reference: 6051
Logged by: Jehan-Guillaume (ioguix) de Rorthais
Email address: j...@dalibo.com
PostgreSQL version: 9.1beta1
Operating system: Linux x86_64
Description:wCTE query fail with wrong error text on a table with
r
"Daniel Cristian Cruz" writes:
> CREATE TABLE a (
> id_a serial primary key,
> v text
> );
> CREATE TABLE b (
> id_b serial primary key,
> id_a integer REFERENCES a (id_a),
> v text
> );
> CREATE TABLE c (
> id_c serial primary key,
> id_b integer references b (id_b),
> v text
> );
> CREA
The following bug has been logged online:
Bug reference: 6050
Logged by: Daniel Cristian Cruz
Email address: danielcrist...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Linux
Description:Dump and restore of view after a schema change: can't
restore the view
D
2011/6/2 Robert Haas :
>
> It's a fairly unusual case to have two inheritance children one of
> which has a foreign key referencing the other, and to then try to
BTW, when the both tables refer to tr_test1 directly the same thing
happens on truncating:
create table tr_test1(id1 int, primary key
16 matches
Mail list logo
