At 12:05 6/10/00 +0900, Hiroshi Inoue wrote:
>
>Tom Lane wrote:
>
>> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>> >>>> P.S. I've noticed that get_rte_attribute_name() seems to
>> >>>> break my implementation. I'm not sure if I could solve it.
>> >>
>> >> That would be a problem --- rule dumping depends on that code to
>> >> produce correct aliases, so making it work is not optional.
>>
>> > Your change has no problem if logical==physical attribute
>> > numbers.
>>
>> But if they're not, what do we do? Can we define the order of the
>> alias-name lists as being one or the other numbering? (Offhand I'd
>> say it should be logical numbering, but I haven't chased the details.)
>> If neither of those work, we'll need some more complex datastructure
>> than a simple list.
>>
>
>I'm not sure if we could keep invariant attribute numbers.
>Though I've used physical attribute numbers as many as possible
>in my trial implementation,there's already an exception.
>I had to use logical attribute numbers for FieldSelect node.
>
Not really a useful suggestion at this stage, but it seems to me that
storing plans and/or parse trees is possibly a false economy. Would it be
worth considering storing the relevant SQL (or a parse tree with field &
table names) and compiling the rule in each backend the first time it is
used? (and keep it for the life of the backend).
This would allow underlying view tables to be deleted/added as well as make
the above problem go away. The 'parse tree with names' would also enable
easy construction of dependency information when and if that is implemented...
----------------------------------------------------------------
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 |/
