[Info-Ingres] FW: Ingres command line client - vertical output?
Martin Bowes
In MySQL's command line client, if you end a query with \G (as opposed to \g) it outputs results in vertical format instead of the usual table format (handy as it makes tables with large numbers of columns a bit more readable).
Is this possible in Ingres? I'm pretty sure the answer is no. I've just read the manual and can't see anything that would say otherwise.
Here's an example of what I mean from MySQL. Vertical:
mysql> select * from op_sys \G
*************************** 1. row ***************************
id: 1
value: All
sortkey: 100
isactive: 1
visibility_value_id: NULL
*************************** 2. row ***************************
id: 5
value: Other
sortkey: 500
isactive: 1
visibility_value_id: NULL
Marty
Karl Schendel
On Mar 22, 2011, at 7:57 AM, Martin Bowes wrote:
> Hi All,
>
> In MySQL's command line client, if you end a query with \G (as opposed to \g) it outputs results in vertical format instead of the usual table format (handy as it makes tables with large numbers of columns a bit more readable).
>
> Is this possible in Ingres? I'm pretty sure the answer is no. I've just read the manual and can't see anything that would say otherwise.
Ingres's terminal monitor doesn't do it. QBF can do something
vaguely similar to this vertical format.
It would certainly be possible; it's just a formatting change in the tm.
I think I'd be tempted to use something other than \G, though;
maybe \v or something like that.
Sounds like a good sprint project. :-)
Karl
Martin Bowes
Once the \vertical is issued the display become vertical on each subsequent query until the \novertical is issued at which point the normal tabular format is returned.
Sounds lika an OpenSource project to me.
Marty
-----Original Message-----
From: Martin Bowes [mailto:martin...@ctsu.ox.ac.uk]
Sent: 22 March 2011 11:57
To: Ingres and related product discussion forum
Subject: [Info-Ingres] FW: Ingres command line client - vertical output?
Hi All,
In MySQL's command line client, if you end a query with \G (as opposed to \g) it outputs results in vertical format instead of the usual table format (handy as it makes tables with large numbers of columns a bit more readable).
Is this possible in Ingres? I'm pretty sure the answer is no. I've just read the manual and can't see anything that would say otherwise.
Here's an example of what I mean from MySQL. Vertical:
mysql> select * from op_sys \G
*************************** 1. row ***************************
id: 1
value: All
sortkey: 100
isactive: 1
visibility_value_id: NULL
*************************** 2. row ***************************
id: 5
value: Other
sortkey: 500
isactive: 1
visibility_value_id: NULL
Marty
_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres
Martin Bowes
So the session starts in tabular, the first \x converts it to vertical, the next \x converts it to tabular and so on.
I know Geraint Jones was planning a few terminal monitor additions for the UKIUA codesproint in Slough, 4-6th June.
Perhaps I can persuade him to add this as well.
BTW. Are you turning up to Codesprint and/or the UKIUA Conference this year?
I'm fully prepared to let you drink all of Roy's Red wine.
Karl Schendel
On Mar 22, 2011, at 8:46 AM, Martin Bowes wrote:
> I've just been told PostgresSQL does this with a \x toggle switch.
>
> So the session starts in tabular, the first \x converts it to vertical, the next \x converts it to tabular and so on.
>
> I know Geraint Jones was planning a few terminal monitor additions for the UKIUA codesproint in Slough, 4-6th June.
> Perhaps I can persuade him to add this as well.
I liked your idea of \v and \nov much better than \x. I'm not
sure which language has a word-equivalent for "vertical"
that starts with the letter x ...
I just took a very very quick look at front/tm/qr, and I don't think that
a vertical mode would be hard to implement at all. Definitely
a good sprint project. (And yes, I plan on being there!)
Karl
Ingres Forums
> I know Geraint Jones was planning a few terminal monitor additions
Well, since Marty mentions it there are a few small changes I was
looking at. Nowhere near submissible as they stand I'm sure, and no
design spec yet (that's doing things the wrong way round really isn't
it...)
Nevertheless, if there's to be a sprint this year I'd apprecate the
opportunity to maybe get some sanity checking, pointers for improvement,
what-to-do-next...?
Briefly the changes are:
\sh <command> (if a command's specified run it & return, rather than
starting an interactive shell - trivial change)
\redir <file> (send query output to a file)
\colformat colname format (if a following query includes column name
"colname", output it using display format "format" - just pulling some
of the existing report writer display formatting into tm)
The vertical display stuff sounds equally worthwhile - if not more so
if it's something users are asking about.
GJ
--
geraintjones
------------------------------------------------------------------------
geraintjones's Profile: http://community.ingres.com/forum/member.php?userid=57763
View this thread: http://community.ingres.com/forum/showthread.php?t=13137
Karl Schendel
On Mar 22, 2011, at 11:04 AM, Ingres Forums wrote:
>
>> I know Geraint Jones was planning a few terminal monitor additions
>
> Well, since Marty mentions it there are a few small changes I was
> looking at. Nowhere near submissible as they stand I'm sure, and no
> design spec yet (that's doing things the wrong way round really isn't
> it...)
No, no, that's the right way. Don't let anyone tell you different. :-)
> Briefly the changes are:
> \sh <command> (if a command's specified run it & return, rather than
> starting an interactive shell - trivial change)
> \redir <file> (send query output to a file)
> \colformat colname format (if a following query includes column name
> "colname", output it using display format "format" - just pulling some
> of the existing report writer display formatting into tm)
How is /redir different from /script?
I rather like the others. Some might argue that \colformat colname
should in fact be \colformat table.colname, but I think they
would be wrong...
Karl
Ingres Forums
Hello GJ,
A few of these topics are already available:
- \s or \sh or \shell ==>Escapes to the operating system.
- \w or \write filename ==>Writes the contents of the query buffer to
the named file.
- \script [filename] ==> Toggles between logging and not logging the
session to a file.
Here whole options:
http://tinyurl.com/4jphrnp
Great thoughts :-)
Bilgihan
--
bilgihan
------------------------------------------------------------------------
bilgihan's Profile: http://community.ingres.com/forum/member.php?userid=8658
Roy Hann
> Nevertheless, if there's to be a sprint this year [...].
The sprints are organized by Ingres Corp, but I have been told several
times in the last few weeks that there will be a sprint the weekend
before the UK IUA conference again this year. So plan accordingly and
watch for the official announcement.
--
Roy
UK Ingres User Association Conference 2011 will be on Tuesday June 7 2011.
Register at http://www.regonline.co.uk/ukiua2011
Ingres Forums
> How is /redir different from /script?
The idea with /redir is it sends only the output of the query to the
file, stdout still gets the rowcount and any errors etc.
I thought it might be useful after I'd been creating a large csv file
using the new tm commands /silent, /vdelim etc:
http://tinyurl.com/4lvssza
Perhaps an example:
[ingres@vm64 tm]$ sql iidbdb
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation
Ingres Linux Version II 10.1.0 (a64.lnx/00)NPTL login
Tue Mar 22 15:45:03 2011
continue
* select 1\p\g
/* SQL Startup File */
select 1
Executing . . .
┌──────┐
│col1 │
├──────┤
│ 1│
└──────┘
(1 row)
continue
* \redir /tmp/outputfile1
Query output redirected into `/tmp/outputfile1'.
* * select 2\p\g
select 2
Executing . . .
(1 row)
continue
* \q
Your SQL statement(s) have been committed.
Ingres Version II 10.1.0 (a64.lnx/00)NPTL logout
Tue Mar 22 15:45:20 2011
[ingres@vm64 tm]$ cat /tmp/outputfile1
┌──────┐
│col1 │
├──────┤
│ 2│
└──────┘
[ingres@vm64 tm]$
Ingres Forums
> I just took a very very quick look at front/tm/qr,
> and I don't think that a vertical mode would be
> hard to implement at all.
That's gone and done it, my Ingres 10.1 build is now further
contaminated with more of my dodgy C code.
Actually, I don't think I'd ever have attempted digging into the Ingres
source to make changes like this without having been to previous sprints
- come on you would-be sprinters, get yourselves along to the next
one...
* select 1,2 union select 3,4;\g
Executing . . .
┌──────┬──────┐
│col1 │col2 │
├──────┼──────┤
│ 1│ 2│
│ 3│ 4│
└──────┴──────┘
(2 rows)
continue
* \vert
* select 1,2 union select 3,4;\g
Executing . . .
**** Row : 1 ****
col1 : 1
col2 : 2
**** Row : 2 ****
col1 : 3
col2 : 4
(2 rows)
Karl Schendel
On Mar 23, 2011, at 11:11 AM, Ingres Forums wrote:
> * \vert
> * select 1,2 union select 3,4;\g
> Executing . . .
>
> **** Row : 1 ****
> col1 : 1
> col2 : 2
>
> **** Row : 2 ****
> col1 : 3
> col2 : 4
>
> (2 rows)
Excellent. :-)
Karl
Paul Mason
> Executing . . .
>
> **** Row : 1 ****
> col1 : 1
> col2 : 2
>
> **** Row : 2 ****
> col1 : 3
> col2 : 4
>
> (2 rows)
>
>
> --
> geraintjones
Very nice!
Martin Bowes
I've asked Geraint to look at variables...I think he hates me.
Marty
________________________________________
From: Paul Mason [Paul....@ingres.com]
Sent: 23 March 2011 17:45
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical output?
> * select 1,2 union select 3,4;\g
> Executing . . .
>
> **** Row : 1 ****
> col1 : 1
> col2 : 2
>
> **** Row : 2 ****
> col1 : 3
> col2 : 4
>
> (2 rows)
>
>
> --
> geraintjones
Very nice!
Ingres Forums
Martin Bowes;36576 Wrote:
> Has anyone got anymore ideas for terminal monitor?
>
> I've asked Geraint to look at variables...I think he hates me.
>
> Marty
>
>
Marty -- when you say "variables", are you referring to something like
what's described at ' Session wide SQL variables - Ingres Community
Wiki' (http://community.ingres.com/wiki/Session_wide_SQL_variables)?
Ian's looked into this a bit and had started working on this at last
year's UK Code Sprint.
--
zelaine
------------------------------------------------------------------------
zelaine's Profile: http://community.ingres.com/forum/member.php?userid=13865
Ian Kirkham
Fret not!
The local symbols support from last Sprint would probably cover
variables giving you similar variable support to what is in DBProcs.
What it would not cover (yet?) is control flow.
The reason this was not added into the code line is that I wanted to
address pass by reference and potentially stop the tabular results when
assignment was performed - looked useful at first and then became
irritating. The latter would need some switching in TM.
The local symbols had slipped my mind but I'll resurrect it as I get
time. (Maybe thus w/e?)
Regards,
Ian
-----Original Message-----
From: info-ingr...@kettleriverconsulting.com
[mailto:info-ingr...@kettleriverconsulting.com] On Behalf Of
Martin Bowes
Sent: 23 March 2011 20:59
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical
output?
Has anyone got anymore ideas for terminal monitor?
I've asked Geraint to look at variables...I think he hates me.
Marty
________________________________________
From: Paul Mason [Paul....@ingres.com]
Sent: 23 March 2011 17:45
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical
output?
> * select 1,2 union select 3,4;\g
> Executing . . .
>
> **** Row : 1 ****
> col1 : 1
> col2 : 2
>
> **** Row : 2 ****
> col1 : 3
> col2 : 4
>
> (2 rows)
>
>
> --
> geraintjones
Very nice!
James K. Lowden
Martin Bowes <martin...@ctsu.ox.ac.uk> wrote:
> I've just been told PostgresSQL does this with a \x toggle switch.
>
> So the session starts in tabular, the first \x converts it to vertical, the next \x converts it to tabular and so on.
The gold standard for interactive SQL shell funcionality has to be sqsh. If you're thinking of enhancing the tm, you could do a lot worse than take a page out its manual.
(A good open source project would be to marry sqsh to Ingres.)
sqsh commands end with \go instead of \g. To alter the appearance of the output, \go takes options; the most useful of these is -m:
\go -m vert vertical
\go -m meta display only metadata
\go -m html html format
\go -m bcp suited for later uploading
This approach is much more flexible and, I think you'll agree, more intuitive than toggling a state variable or using different command terminators to change the output format.
--jkl
Mike Leo
I wrote my own terminal monitor back in the 90's ... and I included in
it some very weird stuff.
One feature I really liked was a setting that would cause the terminal
monitor to exit on any error. It would exit with the last SQL error code
as the return status.
A really goofy feature I added was the ability to process C header files
so I could put the enums in my SQL code and have them preprocessed to the
ordinal at run time. Made writing queries, interactive or not, a lot
easier.
select * from manufacturer where certification not in (ISO_9001, ISO_2000);
Roy would have puked.
Of course, 64MB of RAM was $4K and a 9GB drive was $20K.
Of course, my terminal server only needed to run on SunOS, and I'm
Cheers,
Mike Leo
Roy Hann
> A really goofy feature I added was the ability to process C header files
> so I could put the enums in my SQL code and have them preprocessed to the
> ordinal at run time. Made writing queries, interactive or not, a lot
> easier.
>
> select * from manufacturer where certification not in (ISO_9001, ISO_2000);
>
> Roy would have puked.
Not at all. What you do outside the server is your business. More power
to you. Enums as an attibute type would make me puke.
Of course full support for domain definitions would make everyone happy.
(Here we are in the 21st century and apart from DATE we're still using
only the types that the IBM/360 supported.)
Chris
> One feature I really liked was a setting that would cause the terminal
> monitor to exit on any error.
The tm/sql directive:
\nocontinue
does that :-) copydb/unloaddb make use of it to avoid long running
(un)loads when an error occurs.
> It would exit with the last SQL error code
> as the return status.
That's an interesting technique.
Chris
Mike Leo
On Mar 25, 2011, at 11:22 AM, Chris wrote:
On Mar 24, 6:12 am, Mike Leo <m...@kettleriverconsulting.com> wrote:One feature I really liked was a setting that would cause the terminalmonitor to exit on any error.
The tm/sql directive:
\nocontinue
does that :-) copydb/unloaddb make use of it to avoid long running
(un)loads when an error occurs.
[ingres@cando ~]$ cat test.sql\nocontinue\i doesnt_exist.sqldrop table doesnt_exist_1;\p\gdrop table doesnt_exist_2;\p\g[ingres@cando ~]$ sql jdemo <test.sqlINGRES TERMINAL MONITOR Copyright 2007 Ingres CorporationIngres 2006 Release 2 Linux Version II 9.1.0 (int.lnx/123)NPTL loginFri Mar 25 11:53:26 2011continue* * * * Error opening include file doesnt_exist.sql:E_CL1904_SI_CANT_OPEN SIfopen: Can't open filecontinue* * * /* SQL Startup File */drop table doesnt_exist_1;Executing . . .E_US0AC1 DROP: 'doesnt_exist_1' does not exist or is not owned by you.(Fri Mar 25 11:53:26 2011)- Terminated by ErrorsIngres 2006 Release 2 Version II 9.1.0 (int.lnx/123)NPTL logoutFri Mar 25 11:53:26 2011[ingres@cando ~]$ echo $?1[ingres@cando ~]$
Roy Hann
> drop table doesnt_exist_1;
> Executing . . .
>
> E_US0AC1 DROP: 'doesnt_exist_1' does not exist or is not owned by you.
> (Fri Mar 25 11:53:26 2011)
>
> - Terminated by Errors
> Ingres 2006 Release 2 Version II 9.1.0 (int.lnx/123)NPTL logout
> Fri Mar 25 11:53:26 2011
> [ingres@cando ~]$ echo $?
> 1
> [ingres@cando ~]$
>
> I might just be too picky .... I like to know if my code works.
Yeah, but your code worked. Dropping a non-existent table is no more an
error than deleting a non-existent row.
As you know, I am extremely laid-back about most things and have very
few pet peeves, but this is one of them.
Mike Leo
I was trying to demonstrate the issue. It was contrived.
Actually, my terminal monitor had the ability to control what was an acceptable error. As I
recall, you could specify that a zero row delete or update was a fatal error.
I no longer have he ESQL C code as it belonged to the company I worked for back then.
I wish I did. It had conditionals and all kinds of fun stuff.
Mikey
Roy Hann
> Actually, my terminal monitor had the ability to control what was an acceptable error. As I
> recall, you could specify that a zero row delete or update was a fatal error.
Now *that* is cool.
> I no longer have he ESQL C code as it belonged to the company I worked for back then.
>
> I wish I did. It had conditionals and all kinds of fun stuff.
Well as Geraint Jones was reminding me earlier today, tm has
conditionals too, though you have to read the Quel Reference Manual to
find out about them.
James K. Lowden
Roy Hann <spec...@processed.almost.meat> wrote:
> Yeah, but your code worked. Dropping a non-existent table is no more
> an error than deleting a non-existent row.
Really? What about deleting a nonexistent file?
Time was rm(1) was silent if the named file didn't exist. But lack of
feedback led to compound errors.
*Some* feedback is required. On deletion of rows, the rowcount is
available for inspection. AFAIK that's not true for a dropped table.
Or a nondropped nontable. ;-)
--jkl
Mike Leo
It was CONTRIVED. CONTRIVED.
The point was, my terminal monitor used "markers" that would allow certain statements to fail
and the script would continue.
It also implemented conditionals, allowing me to terminate execution (with an error) if
a certain condition occurred.
What just dawned on me is that if the terminal server had all the things that I put in to
mine back in the mid-90's, I would probably still use Perl DBI/DBD.
So I TAKE IT ALL BACK!!!!!!! Leave the minimalist terminal monitor alone.
Use PERL.
Mikey
On Mar 25, 2011, at 9:02 PM, James K. Lowden wrote:
> On Fri, 25 Mar 2011 19:35:50 +0000 (UTC)
> Roy Hann <spec...@processed.almost.meat> wrote:
>
>> Yeah, but your code worked. Dropping a non-existent table is no more
>> an error than deleting a non-existent row.
>
> Really? What about deleting a nonexistent file?
>
> Time was rm(1) was silent if the named file didn't exist. But lack of
> feedback led to compound errors.
>
> *Some* feedback is required. On deletion of rows, the rowcount is
> available for inspection. AFAIK that's not true for a dropped table.
> Or a nondropped nontable. ;-)
>
> --jkl
>
Roy Hann
> On Fri, 25 Mar 2011 19:35:50 +0000 (UTC)
> Roy Hann <spec...@processed.almost.meat> wrote:
>
>> Yeah, but your code worked. Dropping a non-existent table is no more
>> an error than deleting a non-existent row.
>
> Really? What about deleting a nonexistent file?
The expected outcome was for the named table not to exist. It doesn't
exist. So the "error" you might be catching is a typo in the
table name or a missing schema name. Do you expect to have an error
reported when there's a typo in the name of the table you create? How
about when you use DROP TABLE IF EXISTS and there's a typo in the
table name?
Getting an error when you attempt to drop a table that doesn't exist is
inconsistent and presumptuous.
> Time was rm(1) was silent if the named file didn't exist. But lack of
> feedback led to compound errors.
>
> *Some* feedback is required. On deletion of rows, the rowcount is
> available for inspection. AFAIK that's not true for a dropped table.
> Or a nondropped nontable. ;-)
Those are true observations but not proof that attempting to drop a
table that doesn't exist is an error in your code.
Roy Hann
> So I TAKE IT ALL BACK!!!!!!! Leave the minimalist terminal monitor alone.
>
> Use PERL.
Oh, man...
Roy Hann
> How about when you use DROP TABLE IF EXISTS and there's a typo in the
> table name?
And while I'm ranting about that, the syntax choices should really be
DROP TABLE ... which doesn't return an error if there is no table
DROP EXTANT TABLE ... which does
DROP IF EXISTS is just goofy.
James K. Lowden
Roy Hann <spec...@processed.almost.meat> wrote:
> > How about when you use DROP TABLE IF EXISTS and there's a typo in
> > the table name?
>
> And while I'm ranting about that, the syntax choices should really be
>
> DROP TABLE ... which doesn't return an error if there is no table
> DROP EXTANT TABLE ... which does
>
> DROP IF EXISTS is just goofy.
[applause]
--jkl
Martin Bowes
Ultimately Terminal Monitor is not a high level language like Perl, C etc. So there is little point giving it lots of conditionals, those things are better done by a higher level language. That being said I still think that TM can stand lots of improvements, for example (off the top of my head):
1. Report writer like formatting specification.
2. Merging all the capabilities of ABF procedures into normal SQL procedures.
Marty
-----Original Message-----
From: Mike Leo [mailto:ml...@kettleriverconsulting.com]
Sent: 26 March 2011 02:41
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical output?
Grrr .... I shouldn't have used thqt example!!!!!
It was CONTRIVED. CONTRIVED.
The point was, my terminal monitor used "markers" that would allow certain statements to fail
and the script would continue.
It also implemented conditionals, allowing me to terminate execution (with an error) if
a certain condition occurred.
What just dawned on me is that if the terminal server had all the things that I put in to
mine back in the mid-90's, I would probably still use Perl DBI/DBD.
So I TAKE IT ALL BACK!!!!!!! Leave the minimalist terminal monitor alone.
Use PERL.
Mikey
On Mar 25, 2011, at 9:02 PM, James K. Lowden wrote:
> On Fri, 25 Mar 2011 19:35:50 +0000 (UTC)
> Roy Hann <spec...@processed.almost.meat> wrote:
>
>> Yeah, but your code worked. Dropping a non-existent table is no more
>> an error than deleting a non-existent row.
>
> Really? What about deleting a nonexistent file?
>
> Time was rm(1) was silent if the named file didn't exist. But lack of
> feedback led to compound errors.
>
> *Some* feedback is required. On deletion of rows, the rowcount is
> available for inspection. AFAIK that's not true for a dropped table.
> Or a nondropped nontable. ;-)
>
> --jkl
Roy Hann
> I think that's actually a fair point Mike.
>
> Ultimately Terminal Monitor is not a high level language like Perl,
> C etc. So there is little point giving it lots of conditionals, those
> things are better done by a higher level language. That being said
> I still think that TM can stand lots of improvements, for example (off
> the top of my head):
> 1. Report writer like formatting specification.
Especially for dates. We can use SET DATE_FORMAT in recent releases but
that's not sufficiently versatile as it stands, probably because it also
controls the acceptable input formats as well as the output format.
> 2. Merging all the capabilities of ABF procedures into normal SQL procedures.
I'd settle for being able to declare "module global" temporary tables in
DBPs.
There was once talk of embedding OpenROAD in the server. I'm sure all
the OpenROADies would have liked that. In principle it would be a quick
way to add new data types and scalar functions. In practice I imagine
it would be a quick way to make a mess.
Martin Bowes
If I can get conditionals in terminal monitor... why the hell not? Whether or not I use them is really up to me. Just like using arrays in BASH, where I think to myself, if I have to use arrays in a shell script perhaps I'd be better off writing a Perl program.
Also Geraint tells me that he's looked at importing the Report Writer formatting into Terminal Monitor and he thinks it should be an achievable goal for the code sprint. I'm sure that with sufficient bribery (measured in pints) that he could be persuaded to have a crack at it.
Marty
-----Original Message-----
From: Roy Hann [mailto:spec...@processed.almost.meat]
Sent: 27 March 2011 11:28
To: info-...@kettleriverconsulting.com
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical output?
Martin Bowes wrote:
--
Roy
Roy Hann
> Actually on reflection....
> If I can get conditionals in terminal monitor... why the hell not?
Indeed.
I know you and Geraint know about the tm macros and branching, but for
anyone who doesn't, take a look at the Quel manual. They're not
documented in the SQL manual but tm is tm. Or rather, it's sql. (Or
quel.)
http://docs.ingres.com/ingres/10.0/quel-reference-guide/2200-terminal-monitor-macros
http://docs.ingres.com/ingres/10.0/quel-reference-guide/2198-branching
I ain't saying the syntax is intuitive...
> Also Geraint tells me that he's looked at importing the Report Writer
> formatting into Terminal Monitor and he thinks it should be an
> achievable goal for the code sprint. I'm sure that with sufficient
> bribery (measured in pints) that he could be persuaded to have a crack
> at it.
I'm sure the Benevolent Czarina won't object if I pass a hat round on
the day.
:-)
Roy Hann
> On Fri, 25 Mar 2011 19:35:50 +0000 (UTC)
> Roy Hann <spec...@processed.almost.meat> wrote:
>
>> Yeah, but your code worked. Dropping a non-existent table is no more
>> an error than deleting a non-existent row.
>
> Really? What about deleting a nonexistent file?
The expected outcome was for the named table not to exist. It doesn't
exist. So the "error" you might be catching is a typo in the
table name or a missing schema name. Do you expect to have an error
reported when there's a typo in the name of the table you create? How
about when you use DROP TABLE IF EXISTS and there's a typo in the
table name?
Getting an error when you attempt to drop a table that doesn't exist is
inconsistent and presumptuous.
> Time was rm(1) was silent if the named file didn't exist. But lack of
> feedback led to compound errors.
>
> *Some* feedback is required. On deletion of rows, the rowcount is
> available for inspection. AFAIK that's not true for a dropped table.
> Or a nondropped nontable. ;-)
Those are true observations but not proof that attempting to drop a
table that doesn't exist is an error in your code.
Roy Hann
> Those are true observations but not proof that attempting to drop a
> table that doesn't exist is an error in your code.
Sorry about the double posting; I don't know how that happened.
Ingres Forums
>> I'm sure that with sufficient bribery (measured in pints) that
>> he could be persuaded to have a crack at it.
> I'm sure the Benevolent Czarina won't object if I pass a hat
> round on the day.
I hope there will be no drinking from hats. Please, let's be civilised.
--
geraintjones
------------------------------------------------------------------------
geraintjones's Profile: http://community.ingres.com/forum/member.php?userid=57763
Martin Bowes
-----Original Message-----
From: Ingres Forums [mailto:info-...@kettleriverconsulting.com]
Sent: 28 March 2011 11:37
To: info-...@kettleriverconsulting.com
Subject: Re: [Info-Ingres] FW: Ingres command line client - vertical output?
_______________________________________________