On Fri, Nov 4, 2011 at 16:04, Tom Lane wrote:
> Magnus Hagander writes:
>> Updated patch attached that does this, and the proper schema qualifications.
>
> I'd schema-qualify the quote_ident and regclass names too.
>
> Also, just as a matter of style, I think it'd be better to assign short
> alia
Magnus Hagander writes:
> Updated patch attached that does this, and the proper schema qualifications.
I'd schema-qualify the quote_ident and regclass names too.
Also, just as a matter of style, I think it'd be better to assign short
aliases to the table names ("pg_catalog.pg_class c" etc) and u
On Fri, Nov 4, 2011 at 15:44, Tom Lane wrote:
> Stephen Frost writes:
>> I just noticed it was pulling from pg_depend and we could be creating
>> multiple dependencies on a single sequence by having two tables use it
>> as a default value. If that situation doesn't cause a problem for this,
>> t
Stephen Frost writes:
> I just noticed it was pulling from pg_depend and we could be creating
> multiple dependencies on a single sequence by having two tables use it
> as a default value. If that situation doesn't cause a problem for this,
> then that's fine. :) Couldn't remember if we distingu
Magnus Hagander writes:
> On Fri, Nov 4, 2011 at 15:19, Tom Lane wrote:
>> The join conditions are far from adequate. You can *not* just check the
>> objid, you *must* check classid (and refclassid) to avoid being fooled
> Uh, it does check classid. Or are you saying it's checked the wrong way?
On Fri, Nov 4, 2011 at 15:29, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> If there is noone owning it at all, it just falls through the if/else
>> block and ignores it if that happens (PQntuples() returns 0).
>
> Ah, right, but 'result' is still non-zero, ok.
Yes, tha
* Magnus Hagander (mag...@hagander.net) wrote:
> If there is noone owning it at all, it just falls through the if/else
> block and ignores it if that happens (PQntuples() returns 0).
Ah, right, but 'result' is still non-zero, ok.
> Is there really a case for multiple sequences to own it? How woul
On Fri, Nov 4, 2011 at 15:19, Tom Lane wrote:
> Magnus Hagander writes:
>> The attached patch makes the \d output for psql on a sequence show
>> which table/column owns the sequence. The table already showed the
>> dependency the other way through the default value, but going from
>> sequence bac
Magnus Hagander writes:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not possible.
> Comments/reviews?
Th
On Fri, Nov 4, 2011 at 15:09, Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>> The attached patch makes the \d output for psql on a sequence show
>> which table/column owns the sequence. The table already showed the
>> dependency the other way through the defaul
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not pos
On Fri, Nov 4, 2011 at 9:01 AM, Magnus Hagander wrote:
> The attached patch makes the \d output for psql on a sequence show
> which table/column owns the sequence. The table already showed the
> dependency the other way through the default value, but going from
> sequence back to table was not pos
The attached patch makes the \d output for psql on a sequence show
which table/column owns the sequence. The table already showed the
dependency the other way through the default value, but going from
sequence back to table was not possible.
Comments/reviews?
--
Magnus Hagander
Me: http://www.
13 matches
Mail list logo
