Re: [SQL] What's wrong with COPY rights in 7.3.4?
COPY is done with the rights of the server backend, not your client. You can also use \copy in psql and that is done in the client. --- Olivier Hubaut wrote: > Hi, > > I tried to use the COPY function in v7.3.4 but I have a problem. > According to the documentation, anyboy having the good rights on the > table he want to copy could do it without any problem. > > When I tried it, I found that using this command is impossible if you > aren't an administrator for the instance of PostgreSQL. > > Is it a bug or a *feature*? > > The commands I tried are the followings: > > COPY table FROM '/file.sql'; > > and > > COPY table TO '/file.sql'; > > Thanks for responding. > > -- > Ci-git une signature avortee. > ** RIP ** > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] Help converting Oracle instead of triggers to PostgreSQL
Generally speaking you can send articles to me or to [EMAIL PROTECTED]
for inclusion on the techdocs site.
I'll try to update the links you mentioned below as well. thanks.
Robert Treat
On Thursday 04 December 2003 12:52, Clint Stotesbery wrote:
> Hi Christoph,
> Thanks for the links but the techdoc links for converting from Oracle to
> PostgreSQL has 2 links that don't go to their intended targets anymore, one
> is in the 7.3 docs which is really limited (only covers simple things), and
> the Ora2Pg one I don't really get that well.
>
> As far as updateable views, that's why you need instead of triggers.
> Regular triggers can't be done on views. So if I make an instead of trigger
> on a view that's for updates then I have an updateable view. I figured it
> out last night and I was along the right track in my original post with
> using an instead of rule to call a function. The trick is that I have to
> pass in all the old.col and new.col stuff into the function that I call
> from the rule. In Oracle since the instead of stuff is a trigger I had
> access to the new.col and old.col stuff. To do it in PostgreSQL rules I had
> to pass it all in. I'm going to write a doc about the problems I've
> encountered during my conversion project and then submit it to the Postgres
> people I think (to who though?). My programming and tech writing background
> should help I hope. Thanks for the suggestions Christoph.
> -Clint
>
>
> Original Message Follows
> From: Christoph Haller <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> Subject: Re: [SQL] Help converting Oracle instead of triggers to PostgreSQL
> Date: Thu, 04 Dec 2003 17:16:32 MET
>
> Not sure if this is of any help ...
> AFAIK there are no updatable views in pg.
> But aside from that, I cannot see nothing what could not be
> done by a pg trigger function:
> CREATE TRIGGER name { BEFORE | AFTER } { event [OR ...] }
> ON table FOR EACH { ROW | STATEMENT }
> EXECUTE PROCEDURE func ( arguments )
>
> Also try
>
> http://techdocs.postgresql.org/#convertfrom
>
> Converting from other Databases to PostgreSQL
>
> and/or
>
> http://openacs.org/search/search?q=oracle+to+pg+porting&t=Search
>
> HTH
>
> Regards, Christoph
>
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
> _
> Get holiday tips for festive fun.
> http://special.msn.com/network/happyholidays.armx
>
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] Is it possible to set a NOT NULL constraint deferrable?
Olivier Hubaut wrote: > I can put all the other constaints deferrable, but the *NOT NULL* one > seems to be undeferrable. > > Is ther a way to by-pass this or is do you know if this is planned in > the future versions? Only foreign key constraints are deferrable. Many want UNIQUE to be deferrable, but you are the first to ask for NOT NULL. Not sure when this will be done. Sorry. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] Index not recognized
"Grace C. Unson" <[EMAIL PROTECTED]> writes: > Why is it that my index for text[] data type is not recognized by the > Planner? > > I did these steps: > > 1. create function textarr(text[]) returns text language sql as 'select > $1[1]' strict immutable > 2. create index org_idx on EmpData (textarr(org)); This index will only be used if you use the expression textarr(org) in your query. You would probably have some success if you did: select * from empdata where textarr(org) = 'math' > 3. vacuum full > 4. explain analyze select name from EmpData where org *= 'math'; Is this *= operator from the contrib/array directory? It's not an indexable operator at all using standard btree indexes. The GiST indexing does make indexable operators that can do things like *= but that's a whole other ball of wax. What are you really trying to do? > Result: > = > Seq Scan on EmpData (cost=0.00..3193.20 rows=102 width=488) > (actual time=3.71.35..371.35 rows=0 loops=1) > > Filter: (org[0]='math'::text) Well that's awfully odd. I don't know how that expression came out of the query you gave. You'll have to give a lot more information about how you're defining *= and why you think it's related to the function you used to define the index. -- greg ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
