Re: collations in shared catalogs? - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: collations in shared catalogs?
Date
Msg-id 20150225224704.GZ29780@tamriel.snowman.net
Whole thread Raw
In response to Re: collations in shared catalogs?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: collations in shared catalogs?  (David Steele <david@pgmasters.net>)
List pgsql-hackers
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > > Tom Lane wrote:
> > >> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> > >>> How did that happen? And how could it possibly work?
> >
> > >> It probably doesn't, and the reason nobody has noticed is that the
> > >> security label stuff has fewer users than I have fingers (and those
> > >> people aren't using provider names that would cause anything interesting
> > >> to happen).
> >
> > > The BDR code has recently started using security labels as a place to
> > > store table-specific data.  That widens its use a fair bit ... and most
> > > likely, other extensions will also start using them as soon as they
> > > realize that it can be used for stuff other than actual security labels.
> >
> > Yeah?  Would they be OK with redefining the provider field as "name",
> > or would the length limit be an issue?
>
> Nah, it's fine.  The provider name used there is "bdr".

Agreed, the provider field should be fine as a name field.  Not that I
expect it to be an issue, but I'd definitely like to keep the label
field as text as those can definitely be longer (the very simply example
included in the security label docs is over half the length of a name
field already..).  Now if we increased name to 128 characters...

/me runs and hides.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Precedence of standard comparison operators
Next
From: Jim Nasby
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)