[SQL] Get name of columns in a table
Hi everybody! Is it possible to get thecoluns names of an a table in the database with a sqlquery?? Thanks, a lot. e-mail[EMAIL PROTECTED][EMAIL PROTECTED]
[SQL] Re: Get name of columns in a table
On Fri, 27 Jul 2001, [iso-8859-1] María Elena Hernández wrote: > Is it possible to get thecoluns names of an a table in the database with a sql > query?? "psql -E" will show the SQL commands that psql internally uses to display tables, database, etc. Once in psql, use "\d table_name" to see fields in a table and the SQL behind that. -- Joel Burton <[EMAIL PROTECTED]> Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[SQL] Who do I make _ not a wildcard?
In PG the _ is a wildcard that means any singal char. I need to do a search for the actual _ char and not get back thousands of wrong matches. Is there and escape char that I could use? This needs to work with PG 7.0.3 & 7.1.2. TIA -- Roy Souther <[EMAIL PROTECTED]> 01100010 10101110 11000110 11010110 0100 10110010 10010110 11000110 01001110 0110 11001110 00010110 10010110 00101110 1100 1100 ---(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] Who do I make _ not a wildcard?
On Sat, 28 Jul 2001, Roy Souther wrote: > In PG the _ is a wildcard that means any singal char. I need to do a search > for the actual _ char and not get back thousands of wrong matches. Is there > and escape char that I could use? This needs to work with PG 7.0.3 & 7.1.2. \\_ should work for a literal escape. At least on current sources you can do something like: like 'blah!_%' escape '!' where ! becomes the escape character for the string. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] nullif BUG???
"Josh Berkus" <[EMAIL PROTECTED]> writes: > Er... what were you expecting, exactly? AFAICT, the quoted behavior is correct per the defined behavior of nullif(), cf http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/functions-conditional.html NULLIF(value1, value2) The NULLIF function returns NULL if and only if value1 and value2 are equal. Otherwise it returns value1. > Except for IS NULL (and COALESCE, which uses IS NULL) any operation > involving a NULL is also NULL. Well, that's not quite the correct reasoning. NULLIF and COALESCE are both shorthands for CASE expressions, and hence are capable of returning non-NULL for a NULL input. It all depends on how the CASE tests are phrased. NULLIF is essentially CASE WHEN value1 = value2 THEN NULL ELSE value1 END In the quoted example, "NULL = 5" will yield NULL, which is interpreted as a FALSE case test, so you get the ELSE case, ie value1, ie NULL. regards, tom lane ---(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
[SQL] Re: performance issue with distance function
Hi Ryan, There is a bit of a strange way around the distance overhead issue : Create another table with structure like (lat1,long1,zip1,lat2,long2,zip2,distance) and precalculate the distance for each possibility. This means n*(n-1) rows if you have n location rows. You would then include this table in your query and use distance like you wanted to initially ( should work fast provided you index it on lat1,long1,distance) The calculation overhead of distance is then removed from your query ( at the expense of some disk space ). The insert of each new location requires n calculations of distance - you could perform this in the background I guess ! regards Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
