Thread: Is it possible to remove the public schema?
Hello all I've been approached by the development people about removing the 'public' schema. They complain about having to manually remove the 'public_' tag from table names generated by their development software whenever they link to PG via ODBC. Renaming or using another schema is not what they're after either. 1. If it is possible to remove the public schema, what are the ramifications to existing databases in our system (ie, will a dump/restore be required, etc)? 2. If it's not possible, can it be done via the ODBC driver? Thanks Henry -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440
"Henry Combrinck" <henry@metroweb.co.za> writes:
> I've been approached by the development people about removing the 'public'
> schema. They complain about having to manually remove the 'public_' tag
> from table names generated by their development software whenever they
> link to PG via ODBC.
> Renaming or using another schema is not what they're after either.
Hmm ... you can certainly drop the public schema if you want, but that
just means that you have to put your tables into some other schema.
It sounds to me like the real problem is with non-schema-aware client
software. I think your options are to fix that, or downgrade to a
non-schema-aware database (eg. Postgres 7.2 or before).
regards, tom lane
On Thursday October 21 2004 10:07, Tom Lane wrote: > "Henry Combrinck" <henry@metroweb.co.za> writes: > > I've been approached by the development people about removing the > > 'public' schema. They complain about having to manually remove the > > 'public_' tag from table names generated by their development software > > whenever they link to PG via ODBC. > > > It sounds to me like the real problem is with non-schema-aware client > software. I think your options are to fix that, or downgrade to a > non-schema-aware database (eg. Postgres 7.2 or before). And you do NOT want to downgrade to Pgsql 7.2 or before. Check out the list of changes and bug-fixes since 7.2 to see what you'll be downgrading to. You'll likely have far more trouble than modifying your client software. Ed
> It sounds to me like the real problem is with non-schema-aware client > software. They're using Office XP Developer (Access 2000). No hope of fixing that. > ...I think your options are to fix that, or downgrade to a > non-schema-aware database (eg. Postgres 7.2 or before). ...and miss out on the nourishing goodness of 7.4? I don't think so! Thanks anyway. Regards Henry -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440
Henry Combrinck wrote: >>It sounds to me like the real problem is with non-schema-aware client >>software. > > > They're using Office XP Developer (Access 2000). No hope of fixing that. Don't be pessimistic - give Bill a call and see if he'll accept a patch... Failing that, I wrote a small VBA procedure to do something very similar once. Wasn't difficult as I recall, but there was some irritating glitch with looping through linked tables. Can't remember what at the moment, and aren't near a Windows machine. -- Richard Huxton Archonet Ltd
Bill, Madonna, and I are going out for beers after work. I'll mention it.
Richard Huxton
<dev@archonet.com> To: Henry Combrinck <henry@metroweb.co.za>
Sent by: cc: pgsql-general@postgresql.org
pgsql-general-owner@pos Subject: Re: [GENERAL] Is it possible to remove the public
schema?
tgresql.org
10/21/2004 02:33 PM
Henry Combrinck wrote:
>>It sounds to me like the real problem is with non-schema-aware client
>>software.
>
>
> They're using Office XP Developer (Access 2000). No hope of fixing that.
Don't be pessimistic - give Bill a call and see if he'll accept a patch...
Failing that, I wrote a small VBA procedure to do something very similar
once. Wasn't difficult as I recall, but there was some irritating glitch
with looping through linked tables. Can't remember what at the moment,
and aren't near a Windows machine.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Henry Combrinck wrote:
>> <>It sounds to me like the real problem is with non-schema-aware client
>> software.
>> They're using Office XP Developer (Access 2000). No hope of fixing that.
>
No problem at all.
It's easy to automate the table linking process.
I have a table in access that holds - among other things - the internal
and external name of my linked tables, in which database, schema and
server they locate.
This is used by a little procedure that goes through this list and
creates the ODBC linked table entries for me.
You need a connection-string:
strConn = "ODBC;"
strConn = strConn & "DSN=" & strDSN & ";"
strConn = strConn & "DATABASE=" & strDBName & ";"
strConn = strConn & "UID=" & strDBUser & ";"
strConn = strConn & "PWD=" & strDBPassword & ";"
strConn = strConn & "TABLE=" & strDBScheme & "." & strTblExtern
You should check if an entry allready exists.
If it exist test if it works by calling
CurrentDb.TableDefs(strTblIntern).RefreshLink
Catch an error in case, the link info is stale.
If an error rose then refresh the link infos.
Set db = CurrentDb()
Set tbl = db.TableDefs(strTblIntern)
If tbl.Connect <> strConn Then
tbl.Connect = strConn
tbl.RefreshLink
End If
If the table entry doesn't exist, create it.
Set tbl = db.CreateTableDef(strTblIntern, _
dbAttachSavePWD, _
strDBScheme & "." & strTblExtern, _
strConn)
db.TableDefs.Append tbl
Dropping and recreating the links takes a little longer than, first
checking for existence.
############################
BTW this creates a link entry for a table in another Access mdb-file
DoCmd.TransferDatabase acLink, "Microsoft Access",
"d:\some\folder\my_access.mdb", acTable, strTblExtern, strTblIntern
> No problem at all. > It's easy to automate the table linking process. > > I have a table in access that holds - among other things - the internal > and external name of my linked tables, in which database, schema and > server they locate. [snip] Thank you very much for the information. Regards Henry -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440