Обсуждение: pg_dump of regression (again)
Continuing to try to use format_type to output all types, I get the
following in the regression database:
CREATE AGGREGATE newavg ( BASETYPE = integer, SFUNC = int4_accum, STYPE = "numeric[]", INITCOND = '{0,0,0}',
FINALFUNC= numeric_avg
);
where the original source was:
CREATE AGGREGATE newavg ( sfunc = int4_accum, basetype = int4, stype = _numeric, finalfunc = numeric_avg,
initcond1= '{0,0,0}'
);
The problem is the "numeric[]" type. Does this mean I should go back to
just using typnam for aggregates? For all but table definitions? Or is
there an alternate solution.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
> Continuing to try to use format_type to output all types, I get the
> following in the regression database:
> CREATE AGGREGATE newavg (
> BASETYPE = integer,
> SFUNC = int4_accum,
> STYPE = "numeric[]",
> INITCOND = '{0,0,0}',
> FINALFUNC = numeric_avg
> );
> where the original source was:
> CREATE AGGREGATE newavg (
> sfunc = int4_accum, basetype = int4,
> stype = _numeric,
> finalfunc = numeric_avg,
> initcond1 = '{0,0,0}'
> );
> The problem is the "numeric[]" type.
numeric[] is a correct display of the type (and more intelligible than
_numeric IMHO), but quoting it is not correct. If you are feeding the
output of format_type through something that believes it's quoting a
single identifier, you are going to have lots of problems. It looks
to me like format_type will supply quotes when needed, so you shouldn't
add more.
Unfortunately, this won't work anyway for CREATE AGGREGATE, because I'm
pretty sure the parser only accepts simple identifiers and literals as
arguments in the list of keyword = value items. The type-declaration
parser isn't invoked here, mainly because the grammar doesn't know
anything about the semantics of the individual keyword items. So you
have to give the raw type name, no fancy fandangoes ...
regards, tom lane
At 11:44 14/09/00 -0400, Tom Lane wrote: > >> The problem is the "numeric[]" type. > >numeric[] is a correct display of the type (and more intelligible than >_numeric IMHO), but quoting it is not correct. If you are feeding the >output of format_type through something that believes it's quoting a >single identifier, you are going to have lots of problems. It looks >to me like format_type will supply quotes when needed, so you shouldn't >add more. You're quite right - I left the original pg_dump ID quoting stuff in place. >So you have to give the raw type name, no fancy fandangoes ... OK - I'll use typname in CREATE AGGREGATE, and see how it hangs together. Do you know if the type parser is invoked in function declarations? If not I probably just need to limit use of format_type to table declarations. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
> OK - I'll use typname in CREATE AGGREGATE, and see how it hangs together.
> Do you know if the type parser is invoked in function declarations?
Sort of --- it looks like the production is for SimpleTypename not a
full typename. This is something that needs to be cleaned up in the
backend. In the very short run maybe you should avoid format_type here,
but I'm thinking this is something we need to fix for 7.1.
It looks like the main reason for avoiding full typename here is that
the production for Typename will fail on bogus types such as "opaque".
There are cleaner ways to deal with that --- and even more importantly,
gram.y should not be doing table access under any circumstances,
per our prior discussions about being able to syntax commands after
the current transaction has aborted. My thought at the moment is
to postpone the check for "setof" until later in parse analysis.
Thomas, any comments?
regards, tom lane
Philip Warner <pjw@rhyme.com.au> writes:
>> So you have to give the raw type name, no fancy fandangoes ...
> OK - I'll use typname in CREATE AGGREGATE, and see how it hangs together.
> Do you know if the type parser is invoked in function declarations? If not
> I probably just need to limit use of format_type to table declarations.
BTW, type parsing is now done "properly" in CREATE FUNCTION, CREATE
AGGREGATE, etc, so you should be able to use format_type more freely
now.
regards, tom lane