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 Tue, Apr 8, 2014 at 11:01 AM, Robert Haas wrote:
> On Tue, Apr 8, 2014 at 10:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Looks good, committed with a bit of further cleanup.
>>
>> I had not actually paid attention to the non-regclass parts of this, and
>> now that I look, I've got to sa
On Tue, Apr 8, 2014 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> Looks good, committed with a bit of further cleanup.
>
> I had not actually paid attention to the non-regclass parts of this, and
> now that I look, I've got to say that it seems borderline insane to have
> chosen to implem
Robert Haas writes:
> Looks good, committed with a bit of further cleanup.
I had not actually paid attention to the non-regclass parts of this, and
now that I look, I've got to say that it seems borderline insane to have
chosen to implement regproc/regoper rather than regprocedure/regoperator.
Th
On Tue, Apr 8, 2014 at 3:01 AM, Yugo Nagata wrote:
> On Mon, 7 Apr 2014 12:00:49 -0400
> Robert Haas wrote:
>> In other words, let's revert the whole refactoring of this file to
>> create reg*_guts functions, and instead just copy the relevant logic
>> for the name lookups into the new functions.
On Mon, 7 Apr 2014 12:00:49 -0400
Robert Haas wrote:
> In other words, let's revert the whole refactoring of this file to
> create reg*_guts functions, and instead just copy the relevant logic
> for the name lookups into the new functions. For to_regproc(), for
> example, it would look like this
On 2014-04-07 12:59:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > There's actually another good reason to not copy regclass's behaviour:
>
> > postgres=# CREATE TABLE "123"();
> > CREATE TABLE
> > postgres=# SELECT '123'::regclass;
> > regclass
> > --
> > 123
> > (1 row)
>
Andres Freund writes:
> There's actually another good reason to not copy regclass's behaviour:
> postgres=# CREATE TABLE "123"();
> CREATE TABLE
> postgres=# SELECT '123'::regclass;
> regclass
> --
> 123
> (1 row)
> I don't think that's fixable for ::regclass, but we shouldn't copy
On 2014-04-04 11:18:10 -0400, Robert Haas wrote:
> On Wed, Apr 2, 2014 at 11:27 PM, Amit Kapila wrote:
> > Right, it will get reset in error. However still we need to free for
> > missing_ok
> > case and when it is successful in getting typeid. So don't you think it is
> > better to just free onc
Robert Haas writes:
> In other words, let's revert the whole refactoring of this file to
> create reg*_guts functions, and instead just copy the relevant logic
> for the name lookups into the new functions.
The main discomfort I'd had with this patch was the amount of refactoring
it did; that mad
On Sat, Apr 5, 2014 at 1:10 AM, Amit Kapila wrote:
> The reason of this behavior is that in out functions (regclassout), we return
> the OID as it is incase it doesn't exist. One way to fix this is incase of
> OID input parameters, we check if the passed OID exists in to_* functions
> and return
On Fri, Apr 4, 2014 at 8:48 PM, Robert Haas wrote:
> I see. Here's an updated patch with a bit of minor refactoring to
> clean that up, and some improvements to the documentation.
>
> I was all ready to commit this when I got cold feet. What's bothering
> me is that the patch, as written, mimics
On Thu, Apr 3, 2014 at 5:43 AM, Robert Haas wrote:
> On Wed, Apr 2, 2014 at 1:41 AM, Amit Kapila wrote:
>> On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata wrote:
>>> Hi Amit Kapila,
>>>
>>> Thank you for your reviewing. I updated the patch to v5.
>>
>> I have checked the latest version and found fe
On Wed, Apr 2, 2014 at 1:41 AM, Amit Kapila wrote:
> On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata wrote:
>> Hi Amit Kapila,
>>
>> Thank you for your reviewing. I updated the patch to v5.
>
> I have checked the latest version and found few minor improvements that
> are required:
>
> 1.
> ! if (!mi
On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata wrote:
> Hi Amit Kapila,
>
> Thank you for your reviewing. I updated the patch to v5.
I have checked the latest version and found few minor improvements that
are required:
1.
! if (!missing_ok)
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
!
On Sat, Mar 22, 2014 at 1:17 PM, Amit Kapila wrote:
> On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata wrote:
>> Thanks for your a lot of comments. I revised the patch according to
>> comments from Robert Haas and Marti Raudsepp.
>
> I have started looking into this patch and below are my
> initial
On Sun, Mar 23, 2014 at 7:57 AM, Amit Kapila wrote:
> Anyone has any objection for this behaviour difference between
> usage of ::regclass and to_regclass()?
No, I think that makes a lot of sense given the behavior -- if the
object is not there, to_regclass() just returns NULL. It doesn't
require
On Sat, Mar 22, 2014 at 1:17 PM, Amit Kapila wrote:
> On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata wrote:
>> Thanks for your a lot of comments. I revised the patch according to
>> comments from Robert Haas and Marti Raudsepp.
>
> I have started looking into this patch and below are my
> initial
On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata wrote:
> Thanks for your a lot of comments. I revised the patch according to
> comments from Robert Haas and Marti Raudsepp.
I have started looking into this patch and below are my
initial findings:
1. Dependency is not recorded when to_regclass is u
On Tue, Jan 28, 2014 at 10:38 AM, Yugo Nagata wrote:
> I revised the patch. Could you please review this?
I didn't test the patch due to the duplicate OID compilation error.
But a few things stuck out from the diffs:
* You added some unnecessary spaces at the beginning of the linein
OpernameGetCa
On Fri, Jan 31, 2014 at 6:31 AM, Yugo Nagata wrote:
> Hi Amit,
>
> Thanks for your reviewing. I updated the patch.
> I fixed the oids and removed the witespace.
This patch contains several whitespace-only hunks. Please revert them.
I don't like the changes to typenameTypeIdAndMod(). The code f
t; > > This is the mail system at host sraigw2.sra.co.jp.
> > >
> > > : mail for srasce.sra.co.jp loops back to
> myself
> > > : mail for srasce.sra.co.jp loops back to myself
> > >
> > > -- Forwarded message --
> > > From: Marti
to myself
> : mail for srasce.sra.co.jp loops back to myself
>
> -- Forwarded message --
> From: Marti Raudsepp
> Date: Thu, Jan 23, 2014 at 3:39 AM
> Subject: Re: [HACKERS] Proposal: variant of regclass
> To: Yugo Nagata
> Cc: Tatsuo Ishii , pgsql-hackers
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
I would like to propose to add a variant of regclass.
Background:
Pgpool-II (http://www.pgpool.net) needs to get information of tables
by querying PostgreSQL's system catalog. For efficiency and
correctness of the info (search path consideration), pgpool-II issues
such queries piggy packing the us
61 matches
Mail list logo
