[SQL] \copy multiline

am I missing an continuation-character/option/variable that would allow multiline statements in this case? Cheers, -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] enum data type vs table

On Wed, 25 May 2011 17:23:26 -0500, Peter Koczan wrote: > On Tue, May 17, 2011 at 11:23 PM, Seb wrote: >> Are there any guidelines for deciding whether to 1) create an enum >> data type or 2) create a table with the set of values and then have >> foreign keys referenc

[SQL] enum data type vs table

t? Thanks. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] self join

* FROM tmp t1 WHERE NOT EXISTS(SELECT TRUE FROM tmp t2 WHERE > t2.b=t1.a); This produces exactly the result I'm after. I'll need to understand the EXISTS statement there in more detail. Thanks! -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to y

[SQL] self join

r just: a | b ---+--- 1 | 2 4 | 5 -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] slightly OT - Using psql from Emacs with sql.el

e#toc3 bottom section -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] slightly OT - Using psql from Emacs with sql.el

-functions 'sl/sql-add-newline-before-output))) ... but this breaks navigation (e.g. 'C-c C-p') -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

[SQL] slightly OT - Using psql from Emacs with sql.el

abase_name=# database_name-# database_name-# database_name-# before showing the output of the query. This doesn't happen when working with psql directly from a shell. Has someone dealt with this problem or can suggest some ideas to avoid this? Thanks, -- Seb -- Sent via pgsql-sql mailing

Re: [SQL] indexes

would be > better to index it. Thanks for all your pointers! Do views use the indexes in the underlying tables, whenever say a SELECT operation is called on the view? If so, indexes on views don't make any sense right? -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@pos

Re: [SQL] rename primary key

y constraint. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

[SQL] indexes

stions. Thanks. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] rename primary key

table that is looked up by the foo table? -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

[SQL] rename primary key

Hi, Is it possible to rename a primary key? I learnt that to rename foreign keys one has to drop it and recreate with the new name, or add a new new and drop the old one. What is the approach for primary keys? Thanks. Cheers, -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql

Re: [SQL] Fwd: conditional rule not applied

e carefully to understand the issues a little better. Cheers, -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] Fwd: conditional rule not applied

On Wed, 6 Jan 2010 13:01:02 -0800, Richard Broersma wrote: > On Wed, Jan 6, 2010 at 12:40 PM, Seb wrote: >> I'm trying to create a rule to be applied on update to a view that >> consists of two joined tables.  Table 'shoes' below is left-joined >> with tab

[SQL] Fwd: conditional rule not applied

); -- Testing: result should be a new record in 'shoelaces' UPDATE footwear SET sl_name = 'sl3' WHERE sh_name = 'sh2'; -- but that doesn't happen: SELECT * FROM shoelaces; sl_id | sh_id | sl_name ---+---+- 1 | 1 | sl1 2 | 3 | sl2

Re: [SQL] updateable/insertable view having left joined tables

sh_id, sl_name) SELECT New.sh_id, New.sl_name WHERE New.sl_name IS NOT NULL;); I could find out doing a number of tests, but it would be good to understand what is going on. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription:

[SQL] updateable/insertable view having left joined tables

I'm not sure how a rule to do this would look like, so any pointers would be appreciated. Thanks. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] complex column definition in query

On Wed, 3 Jun 2009 07:04:32 +0200, "A. Kretschmer" wrote: > In response to Seb : >> Hi, >> Say we have a table: >> SELECT * FROM weather; city | temp_lo | temp_hi | prcp >> ---+-+-+--- San Francisco | 46 | 50 | >> 0.

[SQL] complex column definition in query

temp ---+-- San Francisco | 43 San Francisco | 50 San Francisco | 57 Hayward | 30 Hayward | 54 Hayward | 58 Somewhere | 25 Somewhere | 60 Somewhere | 50 (6 rows) Any ideas appreciated! Thanks. Cheers, -- Seb --

[SQL] RE : [SQL] Convert text from UTF8 to ASCII

Hi Perhaps you should try to set your db client_encoding to UTF8. How do you know you have 'patiënt' instead of 'patiënt'? I mean i also deals with UTF8 databases and all i store is correctly stored. But i can't check it with command line psql as my shell is configured with iso-8859-1 charse

Re: [SQL] surrogate vs natural primary keys

single field in t2, thereby avoiding repeating multiple pieces of information? Thanks, -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] surrogate vs natural primary keys

efer to it more efficiently. Is this something we should be considering when choosing natural vs. surrogate keys? Thanks again. -- Seb -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql

Re: [SQL] surrogate vs natural primary keys

precisely what I'm after: *criteria* to help me decide which approach to take for different scenarios. Such guidance is what seems to be lacking from most of the discussions I've seen on the subject. It's hard to distill this information when most of the discussion is centered on a

[SQL] surrogate vs natural primary keys

Hi, I've been reading several articles on this hotly debated issue and still can't find proper criteria to select one or the other approach for the database I'm currently designing. I'd appreciate any pointers. Thanks. Cheers, -- Seb -- Sent via pgsql-sql mai

[SQL] Date/Time types

IMESTAMP with a precision, but nothing works... Thanks for your help Seb ---(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