Re: Proposal: variant of regclass

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com, pavel(at)gf(dot)microolap(dot)com, pavel(at)microolap(dot)com, andres(at)2ndquadrant(dot)com
Subject: Re: Proposal: variant of regclass
Date: 2013-12-16 13:51:22
Message-ID: 13501.1387201882@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> To implement toregclass, which does not throw errors when invalid
> argument is given, src/backend/utils/adt/regproc.c is modified. I
> added two static functions:

> static Datum regclass_gut(char *class_name_or_oid, bool raiseError);
> static List *stringToQualifiedNameList_gut(const char *string, bool raiseError);

Please spell that as "guts" not "gut".

> regclass_gut is called from regclassin and toregclass and do the most
> job before regclassin did. "raiseError" flag controls whether an error
> is raised or not when an invalid argument (for example non existent
> relation) is given. For this purpose, regclass_gut wraps the call to
> oidin using a PG_TRY block.

I do not think that use of PG_TRY is either necessary or acceptable
--- for example, it will happily trap and discard query-cancel errors,
as well as other errors that are not necessarily safe to ignore.
If you don't want to risk an error on an invalid numeric string,
how about parsing the integer yourself with sscanf?

More generally, though, I don't see a great need to try to promise
that this function *never* throws any errors, and so I'm also suspicious
of the hacking you've done on stringToQualifiedNameList. I'm even
less happy about the idea that this patch might start reaching into
things like makeRangeVarFromNameList. I think it's sufficient if it
doesn't throw an error on name-not-found; you don't have to try to
prevent weird syntax problems from throwing errors.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2013-12-16 14:08:51 Assertion failure in base backup code path
Previous Message Peter Eisentraut 2013-12-16 13:21:56 Re: Heavily modified big table bloat even in auto vacuum is running