On Wed, Apr 16, 2014 at 3:27 AM, Tatsuo Ishii wrote:
>>> Well, I noticed that, too, but I didn't think it was my job to tell
>>> the patch author what functions he should have wanted. A follow-on
>>> patch to add to_regprocedure and to_regoperator wouldn't be much work,
>>> if you want that.
>>
>
>> Well, I noticed that, too, but I didn't think it was my job to tell
>> the patch author what functions he should have wanted. A follow-on
>> patch to add to_regprocedure and to_regoperator wouldn't be much work,
>> if you want that.
>
> And here is a patch for that.
Looks good to me except du
On 22 January 2014 13:09, Tatsuo Ishii wrote:
> > I, as a user would be happier if we also have to_regprocedure() and
> > to_regoperator(). The following query looks a valid use-case where one
> > needs to find if a particular function exists. Using to_regproc('sum')
> does
> > not make sense her
On Wed, Jan 22, 2014 at 1:44 PM, Yugo Nagata wrote:
> On Wed, 22 Jan 2014 20:04:12 +0900 (JST)
> Tatsuo Ishii wrote:
> parseTypeString() is called by some other functions and I avoided
> influences of modifying the definition on them, since this should
> raise errors in most cases. This is same r
On Wed, 22 Jan 2014 20:04:12 +0900 (JST)
Tatsuo Ishii wrote:
> > On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote:
> >> Here is the patch to implement to_regclass, to_regproc, to_regoper,
> >> and to_regtype.
> >
> > + static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
> >
> On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote:
>> Here is the patch to implement to_regclass, to_regproc, to_regoper,
>> and to_regtype.
>
> + static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
>
> Minor bikeshedding, a lot of code currently uses an argument named
> "mi
On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote:
> Here is the patch to implement to_regclass, to_regproc, to_regoper,
> and to_regtype.
+ static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
Minor bikeshedding, a lot of code currently uses an argument named
"missing_ok" for
> I, as a user would be happier if we also have to_regprocedure() and
> to_regoperator(). The following query looks a valid use-case where one
> needs to find if a particular function exists. Using to_regproc('sum') does
> not make sense here because it will return InvalidOid, which will not tell
>
Hi,
I have begun the review as part of the commitfest. Below are my comments
*_guts() functions are defined as returning Datum, while they are actually
returning Oid. They should be defined as returning Oid.
Also the PG_RETURN_OID() has been still used in some of the *_guts()
f
> On Tue, Jan 14, 2014 at 4:28 PM, Yugo Nagata wrote:
>> Here is the patch to implement to_regclass, to_regproc, to_regoper,
>> and to_regtype. They are new functions similar to regclass, regproc,
>> regoper, and regtype except that if requested object is not found,
>> returns InvalidOid, rather t
Hi,
On Tue, Jan 14, 2014 at 4:28 PM, Yugo Nagata wrote:
> Here is the patch to implement to_regclass, to_regproc, to_regoper,
> and to_regtype. They are new functions similar to regclass, regproc,
> regoper, and regtype except that if requested object is not found,
> returns InvalidOid, rather th
2013/12/31 Tatsuo Ishii
> > On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
> >> Before proceeding the work, I would like to make sure that followings
> >> are complete list of new functions. Inside parentheses are
> >> corresponding original functions.
> >>
> >> toregproc (regproc)
> >> toregoper (r
> On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
>> Before proceeding the work, I would like to make sure that followings
>> are complete list of new functions. Inside parentheses are
>> corresponding original functions.
>>
>> toregproc (regproc)
>> toregoper (regoper)
>> toregclass (regclass)
>> tore
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
> Before proceeding the work, I would like to make sure that followings
> are complete list of new functions. Inside parentheses are
> corresponding original functions.
>
> toregproc (regproc)
> toregoper (regoper)
> toregclass (regclass)
> toregtype (reg
>> It seems fine to me if the new function ignores the specific error of
>> "relation does not exist" while continuing to throw other errors.
>
> Thanks. Here is the revised conceptual patch. I'm going to post a
> concrete patch and register it to 2014-01 Commit Fest.
Before proceeding the work,
>> For the pgpool-II use case, I'm happy to follow you because pgpool-II
>> always does a grammatical check (using raw parser) on a query first
>> and such syntax problem will be pointed out, thus never reaches to
>> the state where calling toregclass.
>>
>> One concern is, other users expect toreg
On Mon, Dec 16, 2013 at 8:22 PM, Tatsuo Ishii wrote:
>>> 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".
>
> Thanks. I see.
>
>>> regclass_gut
>> 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".
Thanks. I see.
>> regclass_gut is called from regclassin and toregclass and do the most
>> jo
Tatsuo Ishii 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 *stringToQualifiedNameLis
> Tatsuo Ishii writes:
>> Can I make sure that we want to keep the current behavior:
>
>> test=# SELECT 'pg_klass'::regclass;
>> ERROR: relation "pg_klass" does not exist
>
> Yeah, I think the consensus is to not change the behavior of the input
> functions, just add some new ones.
Ok, here is
Tatsuo Ishii writes:
> Can I make sure that we want to keep the current behavior:
> test=# SELECT 'pg_klass'::regclass;
> ERROR: relation "pg_klass" does not exist
Yeah, I think the consensus is to not change the behavior of the input
functions, just add some new ones.
> I'm getting less enamored of just-change-the-input-behavior myself.
> The case that occurred to me is, suppose somebody's got a table containing
> a regclass or regproc column, and he dumps and reloads it. If the input
> converter silently replaces unknown names by 0, he's at risk of unexpected
On Dec 5, 2013, at 7:52 AM, Tom Lane wrote:
> BTW, another arguable advantage of fixing this via new functions is
> that users could write equivalent (though no doubt slower) functions
> for use in pre-9.4 releases, and thus not need to maintain multiple
> versions of app code that relies on this
On 12/5/13, 10:08 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> We could invent some sneaky syntax variants, like 'pg_klass'::regclass
>> errors, but '?pg_klass'::regclass does not.
>
> Hmm ... cute idea, but shoehorning it into regoperator might be
> problematic. You'd have to pick a flag c
Robert Haas writes:
>> Another advantage of this approach is that, IIUC, type input functions
>> can't return a NULL value. So 'pg_klass'::regclass could return 0,
>> but not NULL. On the other hand, toregclass('pg_klass') *could*
>> return NULL, which seems conceptually cleaner.
BTW, another a
Robert Haas writes:
> On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane wrote:
>> I don't think new types are a good idea. If we are afraid to change
>> the behavior of the input converters, what we should do is introduce
>> new functions, eg "toregclass(text) returns regclass".
> That seems like a pret
On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane wrote:
> Pavel Golub writes:
>> I personally see two approaches:
>> 1. Implement GUC variable controling this behaviour per session
>> 2. Introduce new safe reg* variables, e.g. "sregclass", "sregtype" etc.
>
> I don't think new types are a good idea. If
Peter Eisentraut writes:
> We could invent some sneaky syntax variants, like 'pg_klass'::regclass
> errors, but '?pg_klass'::regclass does not.
Hmm ... cute idea, but shoehorning it into regoperator might be
problematic. You'd have to pick a flag character that wasn't a
valid operator character,
On 12/5/13, 9:41 AM, Tom Lane wrote:
> Pavel Golub writes:
>> I personally see two approaches:
>> 1. Implement GUC variable controling this behaviour per session
>> 2. Introduce new safe reg* variables, e.g. "sregclass", "sregtype" etc.
>
> I don't think new types are a good idea. If we are afra
Pavel Golub writes:
> I personally see two approaches:
> 1. Implement GUC variable controling this behaviour per session
> 2. Introduce new safe reg* variables, e.g. "sregclass", "sregtype" etc.
I don't think new types are a good idea. If we are afraid to change
the behavior of the input convert
Hello, Andres.
You wrote:
AF> On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
>> Tatsuo Ishii writes:
>> > I would like to add a variant of regclass, which is exactly same as
>> > current regclass except it does not raise an error when the target
>> > table is not found. Instead it returns Invalid
2013/12/5 Andres Freund
> On 2013-12-05 11:54:20 +0100, Pavel Stehule wrote:
> > 2013/12/5 Andres Freund
> > We can introduce some assert polymorphic function
> >
> > CREATE OR REPLACE FUNCTION notnull(any, message text) RETURNS any, that
> can
> > be used for check inside SQL
>
> Uh. How is tha
On 2013-12-05 11:54:20 +0100, Pavel Stehule wrote:
> 2013/12/5 Andres Freund
> We can introduce some assert polymorphic function
>
> CREATE OR REPLACE FUNCTION notnull(any, message text) RETURNS any, that can
> be used for check inside SQL
Uh. How is that going to help applications that upgraded
2013/12/5 Andres Freund
> On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
> > Tatsuo Ishii writes:
> > > I would like to add a variant of regclass, which is exactly same as
> > > current regclass except it does not raise an error when the target
> > > table is not found. Instead it returns Invalid
On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
> Tatsuo Ishii writes:
> > I would like to add a variant of regclass, which is exactly same as
> > current regclass except it does not raise an error when the target
> > table is not found. Instead it returns InvalidOid (0).
>
> I've sometimes thought
Hello, Tom.
You wrote:
TL> Tatsuo Ishii writes:
>> I would like to add a variant of regclass, which is exactly same as
>> current regclass except it does not raise an error when the target
>> table is not found. Instead it returns InvalidOid (0).
TL> I've sometimes thought we should just make a
> Tatsuo Ishii writes:
>> I would like to add a variant of regclass, which is exactly same as
>> current regclass except it does not raise an error when the target
>> table is not found. Instead it returns InvalidOid (0).
>
> I've sometimes thought we should just make all the reg* input converter
Tatsuo Ishii writes:
> I would like to add a variant of regclass, which is exactly same as
> current regclass except it does not raise an error when the target
> table is not found. Instead it returns InvalidOid (0).
I've sometimes thought we should just make all the reg* input converters
act tha
38 matches
Mail list logo
