Tom Lane wrote:
> 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.
Good point. That is why I liked having ::regclass and ::text versions
of nextval(), but prefer ::regclass _unless_ there is a ::text cast on
the function call. So, instead of removing the ::text cast (as you
said, a bad idea), let's hack up the precidence to prefer ::regclass
when there is no cast. In fact, since few functions take ::regclass,
could we make regclass prefered to text for all cases? That might be
cleaner.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073