[HACKERS] a quick question
Hey, me and a few other folks were having a discussion off list, and the subject of inserts and missing columns came up. you may remember the point in the I'm done post by Bruce. It said: o -Disallow missing columns in INSERT ... VALUES, per ANSI What is this, and why is it marked done? We used to allow INSERT INTO tab VALUES (...) to skip the trailing columns and automatically fill in null's. That is fixed, per ANSI. Anyway, I just tested it on 7.3b1 and I can still do an insert with the columns missing and it fills in defaults or nulls, with defaults being the preference. So, are we gonna make postgresql throw an error when someone tries to submit an insert with too few columns to match up to the implicit column list, or not? This just seems like a change designed to piss off users to me, but I can see where it does encourage better query crafting. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] a quick question
On Tue, 2002-09-17 at 16:44, scott.marlowe wrote: Hey, me and a few other folks were having a discussion off list, and the subject of inserts and missing columns came up. you may remember the point in the I'm done post by Bruce. It said: o -Disallow missing columns in INSERT ... VALUES, per ANSI What is this, and why is it marked done? We used to allow INSERT INTO tab VALUES (...) to skip the trailing columns and automatically fill in null's. That is fixed, per ANSI. So, are we gonna make postgresql throw an error when someone tries to submit an insert with too few columns to match up to the implicit column list, or not? There was a vote to keep previous behaviour when the column list wasn't supplied, so it's not to ANSI spec, it's to our improved version ;) INSERT INTO (...) VALUES (...) will not allow you to skip value entries, but the keyword DEFAULT is available now, so it shouldn't be much of an issue. -- Rod Taylor ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Another quick question...
If you have RelationGetRelationName(rel) to get the name of a relation, how do you get it's fully qualified schema name? Or how do I get the schema name for the relation? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Another quick question...
Christopher Kings-Lynne [EMAIL PROTECTED] writes: If you have RelationGetRelationName(rel) to get the name of a relation, how do you get it's fully qualified schema name? Or how do I get the schema name for the relation? Well, you can do get_namespace_name(rel-rd_rel-relnamespace), but I don't really agree with changing error messages to *always* quote the schema name. I think that'd be overly verbose. An appropriate solution is to mention the schema name only when it's necessary to identify the relation (ie, the rel would not be found in your current search path). generate_relation_name() in backend/utils/adt/ruleutils.c illustrates how to do this. Maybe that code ought to be promoted into some more widely useful location. See also the recently added format_procedure() and format_operator() in regproc.c. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Another quick question...
Christopher Kings-Lynne [EMAIL PROTECTED] writes: If you have RelationGetRelationName(rel) to get the name of a relation, how do you get it's fully qualified schema name? Or how do I get the schema name for the relation? Well, you can do get_namespace_name(rel-rd_rel-relnamespace), but I don't really agree with changing error messages to *always* quote the schema name. I think that'd be overly verbose. An appropriate solution is to mention the schema name only when it's necessary to identify the relation (ie, the rel would not be found in your current search path). The problem I see is that imagine you're browsing your logs. If you see an error message (or a notice) that refers just to a table, you have no idea which schema the table is in... Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Another quick question...
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Well, you can do get_namespace_name(rel-rd_rel-relnamespace), but I don't really agree with changing error messages to *always* quote the schema name. I think that'd be overly verbose. The problem I see is that imagine you're browsing your logs. If you see an error message (or a notice) that refers just to a table, you have no idea which schema the table is in... Well, yeah, you may need to do a little bit of detective work to interpret a logged error message. Perhaps the table name in question was dropped (and even recreated) since the logged event. Perhaps it's in another database than you thought. Or perhaps it's a long-dead temp table. Then we could move to the same set of issues with respect to the types, functions, operators, etc that might impinge on the error condition. I tend to think that error messages should be written for the convenience of the interactive user, who has some chance of knowing the context. Being verbose for the log just makes the log bigger (note recent complaints about volume of log output...) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
