Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> This still wouldn't put us in a place where existing dumps are
>> automatically fixed up during import. We'd parse the expressions as
>> nextval('foo'::text::regclass), which will work but it's effectively
>> still late-binding --- the actual constant is just text not regclass.
>> There's no way to fold it down to 'foo'::regclass automatically
> I am thinking we should hard-code something in the backend so if the
> function oid is nextval/currval/setval, we strip off any text casting
> internally. These functions are already pretty special in their usage
> so I don't see a problem in fixing it this way.
You have not thought about it hard. We cannot do that without breaking
existing dumps. Consider
create sequence seq;
create table foo (f1 int default nextval('seq'::text));
In current releases, there is no dependency from foo to seq and
therefore pg_dump could dump the above two objects in either order.
(With the names I used in the example, recent pg_dumps would in
fact choose to dump the table first.) If we try to force the 'seq'
literal into regclass form then the script will fail, because the
seq relation does not exist yet.
I think people missed the significance of the part of my patch that
created dependencies for regclass literals. Without that, it really
just doesn't work.
I see no prospect that we can have a transparent migration to
nextval(regclass) without breaking things left and right. Therefore
I still feel that the best solution is to introduce new functions
with different names. That has zero chance of breaking anything
that works now. If people don't want to migrate, well, they don't
have to.
regards, tom lane
