Hi,
thank you for your patience in explaining. Rest assured that I've read
the relevant messages multiple times.
Tom Lane wrote:
> the
> default expression is a separate entity from the attribute itself,
That was the point I didn't understand...
> ..
> Otherwise we couldn't handle the concept t
Markus Wanner <[EMAIL PROTECTED]> writes:
> And why do we keep the attributes defaults in their own table with their
> own OID, instead of merging them into pg_attributes?
That has already been explained multiple times in this thread, but: the
default expression is a separate entity from the attri
Hi,
Stephen Frost wrote:
> As part of pg_attribute.. Having a seperate table would be an
> alternative to adding a column to pg_shdepend.
Aha. Hm...
I thought tracking dependencies between tables and attributes
complicates DROP TABLE? Why doesn't that concern apply here?
And why do we keep the
* Markus Wanner ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > * Markus Wanner ([EMAIL PROTECTED]) wrote:
> >> What does the subobject column for pg_shdepend buy us?
> >
> > Tracking column-level ACL dependencies rather than having those
> > dependencies only be at the table-level. This co
Hi,
Stephen Frost wrote:
> * Markus Wanner ([EMAIL PROTECTED]) wrote:
>> What does the subobject column for pg_shdepend buy us?
>
> Tracking column-level ACL dependencies rather than having those
> dependencies only be at the table-level. This complicates
> pg_shdepend some, but simplifies the d
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
> What does the subobject column for pg_shdepend buy us?
Tracking column-level ACL dependencies rather than having those
dependencies only be at the table-level. This complicates
pg_shdepend some, but simplifies the dependency handling in the
AC
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> I think adding a subobject column to pg_shdepend is probably the best
>> answer --- we only didn't do that to start with because we thought it
>> wasn't needed.
>
> Yep. I did consider adding it, but there was no use for it at the time
> so I just lef
Tom Lane wrote:
> I think adding a subobject column to pg_shdepend is probably the best
> answer --- we only didn't do that to start with because we thought it
> wasn't needed.
Yep. I did consider adding it, but there was no use for it at the time
so I just left it out. It's not like it's very
Stephen Frost <[EMAIL PROTECTED]> writes:
>> Huh? Maybe I missed something, but I didn't think that was suggested
>> anywhere.
> I had suggested a single table, with an OID, which would house anything
> that needed a seperate OID for columns (defaults and ACLs currently) in
> [EMAIL PROTECTED]
[
Tom,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Markus Wanner <[EMAIL PROTECTED]> writes:
> > ISTM that we should at least combine defaults and ACLs then, as proposed
> > by Stephen.
>
> Huh? Maybe I missed something, but I didn't think that was suggested
> anywhere.
I had suggested a single table
Markus Wanner <[EMAIL PROTECTED]> writes:
> ISTM that we should at least combine defaults and ACLs then, as proposed
> by Stephen.
Huh? Maybe I missed something, but I didn't think that was suggested
anywhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Tom Lane wrote:
> Well, as far as the dependency system goes this way is more convenient.
> If pg_attribute entries had their own OIDs it would be fairly hard
> to implement DROP TABLE except with an intermediate step of dropping
> each of the col
Markus Wanner <[EMAIL PROTECTED]> writes:
> Just to understand the issue here: what's the reason for having an OID
> for the default value and possible another one for a ACLs, but none for
> the attribute itself?
Well, as far as the dependency system goes this way is more convenient.
If pg_attri
Hi,
Tom Lane wrote:
Yah. However, I started to look at doing this and immediately hit a
stumbling block: we need a representation in pg_depend for a column's
default expression (as distinct from the column itself).
Just to understand the issue here: what's the reason for having an OID
for th
On Mon, Sep 22, 2008 at 5:41 AM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > If we were to accept the pg_attrdef approach, why aren't we
> > > doing a pg_attracl table instead of adding a column to pg_attribut
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > If we were to accept the pg_attrdef approach, why aren't we
> > doing a pg_attracl table instead of adding a column to pg_attribute?
>
> That's actually not an unreasonable question. If you were to do that
> the
Stephen Frost <[EMAIL PROTECTED]> writes:
> Honestly, I really disliked the code which assumed pg_attribute had no
> NULLable/toastable columns and used what seemed like pretty gruesome
> hacks to create pg_attribute structures.
Agreed, but that seems orthogonal to the point here, which is that a
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I can think of a way around that: represent a default expression using
> classid = OID of pg_attribute, objid = OID of table, objsubid = column
> attnum. This is distinct from the column itself, which is represented
> with classid = OID of pg_class. It seem
On Sun, Sep 21, 2008 at 11:09 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> A possible objection to this plan is that if the column-level privileges
> patch doesn't get in, then we're left with a useless column in
> pg_attribute. But an always-null column doesn't cost much of anything,
> and we know t
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Hrm, I thought if anything we wanted to put them in pg_constraints (at
> least inherited ones). Now maybe I have defaults confused with NOT
> NULLs... But don't we want to be able to give defaults names and and
> such?
No, I think you're thinking of N
[EMAIL PROTECTED] writes:
> pgadmin has some umm, interesting queries over pg_depends. It sounds
> like this change could complicate those. I doubt it's an
> insurmountable problem of course.
Yeah. But the only real point of the change is cleanliness, and if it's
injecting ugliness into clients t
pgadmin has some umm, interesting queries over pg_depends. It sounds
like this change could complicate those. I doubt it's an
insurmountable problem of course.
On 9/21/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> A possible objectio
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A possible objection to this plan is that if the column-level privileges
>> patch doesn't get in, then we're left with a useless column in
>> pg_attribute. But an always-null column doesn't cost much of anything,
>> and we know tha
Tom Lane wrote:
A possible objection to this plan is that if the column-level privileges
patch doesn't get in, then we're left with a useless column in
pg_attribute. But an always-null column doesn't cost much of anything,
and we know that sooner or later we will support per-column ACLs:
they
I had a thought while looking over the column-level privileges patch
that Stephen Frost is working on. To wit, that the only reason that
column default expressions are stored in a separate catalog pg_attrdef
is the historical assumption in some parts of the code that pg_attribute
rows are fixed-wi
25 matches
Mail list logo
