Large objects names
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.
However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.
Is is OK to rename them internally?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
I will probably keep the current names for a few releases. Once
interfaces start using the relkind field to identify them, rather than
the xinv* naming, I will be able to change the names to anything else
and no external interface will care.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.
--
Peter T Mount peter@retep.org.uk or petermount@earthling.net
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
How about giving them their own subdirectory large_object/_lob_###,
then there would be no naming conflict ?
Since all others call them LOB I would use _lob_### instead.
Andreas
Import Notes
Resolved by subject fallback
Peter T Mount wrote:
On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.
The same goes for ODBC.
On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.
So does ODBC. Let's start using relkind = 'l', then I can change the
name in a later release, and no one will see the change.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.
I am suggesting changes in later releases to older interfaces can
communicated with 6.4 without any problems.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
How about giving them their own subdirectory large_object/_lob_###,
then there would be no naming conflict ?
Since all others call them LOB I would use _lob_### instead.
That would be interesting.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)On Thu, 6 Aug 1998, Bruce Momjian wrote:
On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.I am suggesting changes in later releases to older interfaces can
communicated with 6.4 without any problems.
That sounds ok.
--
Peter T Mount peter@retep.org.uk or petermount@earthling.net
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
On Thu, 6 Aug 1998, Bruce Momjian wrote:
On Wed, 5 Aug 1998, Bruce Momjian wrote:
Currently, large objects are stored internally as xinv### and xinx###.
I would like to rename this for 6.4 to be _lobject_### to prevent
namespace collisions, and make them clearer for administrators.However, this may cause problems for backward compatability for large
object users. As I see there are going to be other new large object
things in 6.4, it may not be an issue.Is is OK to rename them internally?
Shouldn't be a problem. JDBC does refer to the xin prefix with the
getTables method, so it's simply a single change there.I am suggesting changes in later releases to older interfaces can
communicated with 6.4 without any problems.That sounds ok.
Yes. Older odbc/java/psql interfaces still use the xinv pattern to
restrict table lists. As new interfaces use relkind, I can then change
the internal name.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)