hssqlppp-0.0.7: questions

here are some queries that need investigating, and possibly posted to
the appropriate mailing list.

= haskell questions

generating the default scope, the layout is awful when saved to a
file. Is there an easy way to Show this value, with nice formatting?
Is there a better way to serialize this value rather than as a haskell
source file? Todo - try Data.Binary

= ghc questions

getting
ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.4 for i386-unknown-linux):
	linkBCO: >= 64k insns in BCO

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

when compiling defaultscope with -Wall, put together a bug report or
something.

-----
getting segmentation fault when trying to run code with profiling on
- ghc --make -prof -auto-all  HsSqlSystem.lhs +RTS -K64M
then run ./HsSqlSystem

= cabal

when tried to install profiling, is there a short cut to reinstall all
the dependent libs with the profiling option on? had to do this one or
two libs at a time and it took ages.

after cabal stop complaining about libs without profiling on, tried to
build the code and got errors like HSHunit_p library not found, this
was fixed by re-cabal installing some libraries with profiling on that
cabal had missed - it picked up on some libs, and not others?

cabal haddock - top level documentation from cabal file appears to
have whitespace stripping, destroying paragraphs and lists

= uuagc

compare with aspectag - what are the upsides/downsides?
update - looks like the syntax still needs a lot of work for aspectag

= postgresql questions

is a null literal treated as a unknown string for the purposes of
function resolution, resultset resolution, etc.?

how does the function resolution work for polymorphic functions

what situations can an empty array type check successfully, and when
is it rejected.

is it possible to create a full view of all the casts that are used in
implicit, etc., resolution, i.e. including the ones that aren't in pg_cast

is it correct to use the resolve result set type algo when determining
the type of common fields in a natural or using join?

looking at postgresql-doc-8.4/html/query-path.html, it is unclear
where type checking occurs - is it mainly in a separate stage, or
intermingled in with the other stages

is the way the keyword operators are typed correct (using the function
call match algo to sort the implicit casts)?

how does the parser handle parsing operators without knowing whether
they are prefix, postfix or binary until later

when is the b_expr parser used (should just need a grep over the
grammar file)

is the handling of between, coalesce, greatest, and least correct
(delegating the checks to <= operators or whatever, coalesce uses
resultsetresolution)

why doesn't this work:
select
    att.oid,
    cls.oid,
    cls.relkind,
    cls.relname,
    att.typname
  from pg_type att
  inner join pg_class cls using(oid);

-- column "oid" specified in USING clause does not exist in left table