Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread Zeugswetter Andreas OSB sIT
it's look well, but I still prefer some combination with = name: = '' name: = ''' :name = '' $name = .. $name = .. I wonder about name := ''. := is used in Pascal/Ada to assign a value. Or would that again be an allowed operator in pg ? Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread Pavel Stehule
2008/12/15 Peter Eisentraut pete...@gmx.net: Pavel Stehule wrote: Because AS is signal for collecting column (or label) names. I thing so we should use AS as Tom's proposal, together with SQL/XML functionality. Yes, please implement that. I'll do it - it's better then nothing, It's

Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread Peter Eisentraut
David E. Wheeler wrote: Perhaps not, but I have to say, looking at Robert's JSON example: SELECT json(r.foo AS foo, r.bar AS bar, r.baz AS baz, r.bletch AS quux) FROM rel r; I would be pretty confused. It looks exactly like the proposed syntax for named parameters. So while syntactically

Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread Pavel Stehule
2008/12/15 Zeugswetter Andreas OSB sIT andreas.zeugswet...@s-itsolutions.at: it's look well, but I still prefer some combination with = name: = '' name: = ''' :name = '' $name = .. $name = .. I wonder about name := ''. := is used in Pascal/Ada to assign a value. Or would that again be

Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread David E. Wheeler
On Dec 15, 2008, at 11:05 AM, Peter Eisentraut wrote: In my mind, you just have to think about it hard enough to come to realize that, when viewed from the right angle, the semantic conflict might not exist after all. It's a bit tricky, but I think it's possible. Better for users not to

Re: [HACKERS] WIP: default values for function parameters

2008-12-15 Thread Peter Eisentraut
Pavel Stehule wrote: Because AS is signal for collecting column (or label) names. I thing so we should use AS as Tom's proposal, together with SQL/XML functionality. Yes, please implement that. It's only idea: default behave is using as for param name specification, seconf with flag maybe

Re: [HACKERS] WIP: default values for function parameters

2008-12-14 Thread David E. Wheeler
On Dec 14, 2008, at 6:55 AM, Tom Lane wrote: The whole relabeling thing seems like a seriously silly idea. I wouldn't say that it's silly. What I do say is that it makes no sense to imagine that it would be used at the same time as named parameters. The entire point of something like

Re: [HACKERS] WIP: default values for function parameters

2008-12-14 Thread Pavel Stehule
2008/12/14 Greg Stark st...@enterprisedb.com: On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas robertmh...@gmail.com wrote: What if relabeling support were to spread some more? The only example I can think of besides XML is JSON. There might be a few more. Basically, relabelling is a handy

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Asko Oja
On Fri, Dec 12, 2008 at 8:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Meskes mes...@postgresql.org writes: On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote: Hmm ... actually, ecpg might be a problem here anyway. I know it has special meaning for :name, but does it allow

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Peter Eisentraut
On Friday 12 December 2008 20:05:57 Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed not break any existing features. Barring better ideas I think we should go with that one. I personally

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Albert Cervera i Areny
A Dissabte 13 Desembre 2008, Peter Eisentraut va escriure: On Friday 12 December 2008 20:05:57 Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed not break any existing features. Barring

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit : On Friday 12 December 2008 20:05:57 Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Tom Lane
Dimitri Fontaine dfonta...@hi-media.com writes: Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit : I personally thought that AS was a better idea. It seems some people want to be able to overload some default parameters (but not others) and at the same time alias them to some new label.

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Bruce Momjian
Dimitri Fontaine wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 13 d?c. 08 ? 11:39, Peter Eisentraut a ?crit : On Friday 12 December 2008 20:05:57 Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread David E. Wheeler
On Dec 13, 2008, at 5:05 PM, Tom Lane wrote: However, after looking at the precedent of XMLELEMENT, it's hard to deny that if the SQL committee ever chose to standardize named parameters, AS is what they would use. The chances that : would become the standard are negligible --- that's not

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: On Dec 13, 2008, at 5:05 PM, Tom Lane wrote: However, after looking at the precedent of XMLELEMENT, it's hard to deny that if the SQL committee ever chose to standardize named parameters, AS is what they would use. The chances that : would

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread David E. Wheeler
On Dec 13, 2008, at 5:19 PM, Tom Lane wrote: I'm sure it's technically possible, but I see no redeeming social value in it ... we should pick one and quit repainting the bike shed. Well, as I've said, I'm okay with AS, though it's not my favorite. I can see the argument that it's more

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: I don't suppose that the position of the label and the value on either side of AS could be reversible, could it? No. Consider SELECT foo(bar AS baz) FROM ... If the from-clause provides columns named both bar and baz, it would be

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Bruce Momjian
David E. Wheeler wrote: On Dec 13, 2008, at 5:19 PM, Tom Lane wrote: I'm sure it's technically possible, but I see no redeeming social value in it ... we should pick one and quit repainting the bike shed. Well, as I've said, I'm okay with AS, though it's not my favorite. I can see

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Grzegorz Jaskiewicz
On 2008-12-13, at 16:19, Tom Lane wrote: I'm sure it's technically possible, but I see no redeeming social value in it ... we should pick one and quit repainting the bike shed. +1000 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Robert Haas
I personally agree that AS seems more SQL-ish, but that's in the eye of the beholder. The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT doesn't (and won't) have named parameters. But it is true that XMLELEMENT is doing something subtly different with the AS clause than

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 13 déc. 08 à 17:05, Tom Lane a écrit : I personally agree that AS seems more SQL-ish, but that's in the eye of the beholder. So do I, but I fear it's already taken for another meaning. The argument about ambiguity in XMLELEMENT is bogus

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Tom Lane
Dimitri Fontaine dfonta...@hi-media.com writes: What if relabeling support were to spread some more? Spread to what? AFAICS the way that XMLELEMENT uses AS is a single-purpose wart (much like a lot of other stuff the SQL committee invents :-(). I do not see a need to reserve AS in function

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 13 déc. 08 à 22:32, Tom Lane a écrit : Spread to what? AFAICS the way that XMLELEMENT uses AS is a single-purpose wart Ok now that explains. The common lisp inspired syntax is only nice if we're to avoid using AS, which I thought was the

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Robert Haas
What if relabeling support were to spread some more? The only example I can think of besides XML is JSON. There might be a few more. Basically, relabelling is a handy shortcut when you are serializing data and want to avoid specifying a list of columns and an (almost) identical list of labels.

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Greg Stark
On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas robertmh...@gmail.com wrote: What if relabeling support were to spread some more? The only example I can think of besides XML is JSON. There might be a few more. Basically, relabelling is a handy shortcut when you are serializing data and want to

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Robert Haas
The whole relabeling thing seems like a seriously silly idea. Why is it at all a shortcut to use AS instead of , ? Because a lot of times you don't want to relabel, so you omit the AS label part altogether, and the label is deduced from the expression itself. For example, I don't need to

Re: [HACKERS] WIP: default values for function parameters

2008-12-13 Thread Tom Lane
Greg Stark st...@enterprisedb.com writes: On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas robertmh...@gmail.com wrote: What if relabeling support were to spread some more? The only example I can think of besides XML is JSON. There might be a few more. Basically, relabelling is a handy

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote: what do you thing about? select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val) example select dosome(10,20,30, SET flaga = true, flagb = false) I think AS read more naturally because you expect the parameter to come first, not the

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Ian Caulfield
2008/12/12 David E. Wheeler da...@kineticode.com: On Dec 11, 2008, at 3:42 PM, Bruce Momjian wrote: what do you thing about? select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val) example select dosome(10,20,30, SET flaga = true, flagb = false) I think AS read more naturally

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 12 déc. 08 à 14:14, Ian Caulfield a écrit : unpopular, and '=' et al conflict with operators, would verilog-style syntax - eg function( .param(value) ) - be an idea? Ok, time to revisit the classics then ;)

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Pavel Stehule
2008/12/12 Dimitri Fontaine dfonta...@hi-media.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 12 déc. 08 à 14:14, Ian Caulfield a écrit : unpopular, and '=' et al conflict with operators, would verilog-style syntax - eg function( .param(value) ) - be an idea? Ok, time to

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: As a Perl hacker, I'm strongly biased toward =, but I guess AS isn't *too* bad. At least it's the same number of characters. Is - right out? It's just as bad as = from the perspective of usurping a probable user-defined operator name. I think the

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 2:33 PM, Dimitri Fontaine wrote: Ok, time to revisit the classics then ;) http://www.gigamonkeys.com/book/functions.html#keyword-parameters That would give us things like this: SELECT foo(1, :name 'bar', :quantity 10); As colon character does not appear in the list of

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 2:39 PM, Tom Lane wrote: So I think that really this is never going to fly unless it uses a keyword-looking reserved word. And we're not going to take some short word that's not reserved now and suddenly make it so. So, despite Pavel's objection that the AS syntax proposal

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: I'm okay with AS if that's the way it has to be, but what about a colon right at the end of the label? Hmm ... a colon isn't considered to be an operator name, so this wouldn't break any existing usage. I'm a little bit worried about what we

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Pavel Stehule
2008/12/12 David E. Wheeler da...@kineticode.com: On Dec 12, 2008, at 2:39 PM, Tom Lane wrote: So I think that really this is never going to fly unless it uses a keyword-looking reserved word. And we're not going to take some short word that's not reserved now and suddenly make it so. So,

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Rod Taylor
How about IS or INTO? param_name IS 3 param_name IS 'some string value' 3 INTO param_name 'some string value' INTO param_name On Fri, Dec 12, 2008 at 8:47 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2008/12/12 David E. Wheeler da...@kineticode.com: On Dec 12, 2008, at 2:39 PM, Tom

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
Rod Taylor rod.tay...@gmail.com writes: How about IS or INTO? IS isn't a fully reserved word, and INTO seems pretty weird for this. (IS is a type_func_name_keyword, so maybe we could make it work anyway, but it sounds a bit fragile.) regards, tom lane -- Sent via

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 2:47 PM, Pavel Stehule wrote: it's look well, but I still prefer some combination with = name: = '' name: = ''' :name = '' $name = .. $name = .. Maybe I am too conservative Given that the colon already indicates This label corresponds to that value, the other operator

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Sam Mason
On Fri, Dec 12, 2008 at 09:00:52AM -0500, Rod Taylor wrote: How about IS or INTO? param_name IS 3 param_name IS 'some string value' that wouldn't work with NULL would it? for example is: a IS NULL checking if identifier 'a' IS NULL, or if you're giving NULL to parameter 'a'. 3 INTO

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Pavel Stehule
right at the end of the label? A cast is two colons, so no conflict there: SELECT foo(1, name: 'bar', quantity: 10); it's look well, but I still prefer some combination with = name: = '' name: = ''' :name = '' $name = .. $name = .. hmm :( $name isn't possible :name is in conflict with

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
I wrote: Rod Taylor rod.tay...@gmail.com writes: How about IS or INTO? IS isn't a fully reserved word, and INTO seems pretty weird for this. (IS is a type_func_name_keyword, so maybe we could make it work anyway, but it sounds a bit fragile.) Actually, there's an obvious counterexample for

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Heikki Linnakangas
David E. Wheeler wrote: Coming to this a bit late, but it seems to me that, while it makes sense to assign a label to a value using AS, it's kind of weird to use it to assign a value to a label. SELECT foo( bar = 'ick', baz = 'ack' ); SELECT foo( bar AS 'ick', baz AS 'ack' ); We could do it

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Robert Haas
I'm okay with AS if that's the way it has to be, but what about a colon right at the end of the label? A cast is two colons, so no conflict there: SELECT foo(1, name: 'bar', quantity: 10); No doubt I'm missing something… I'd just like to mention that there are two different cases to

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Pavel Stehule
2008/12/12 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: David E. Wheeler wrote: Coming to this a bit late, but it seems to me that, while it makes sense to assign a label to a value using AS, it's kind of weird to use it to assign a value to a label. SELECT foo( bar = 'ick', baz

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote: I discussed about this form with Tom. I thing so following should be readable: name: [ optional = ] value SELECT foo( bar: 'ick', baz: 'ack' ); SELECT foo( bar: = 'ick', baz: = 'ack' ); or SELECT foo( bar: = 'ick', baz: = 'ack' );

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Gregory Stark
Pavel Stehule pavel.steh...@gmail.com writes: 2008/12/12 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: We could do it the other way round: SELECT foo( 'ick' AS bar, 'ack' AS baz); I always assumed we were talking about it this way. Everywhere else in SQL AS is followed by the

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Pavel Stehule
2008/12/12 David E. Wheeler da...@kineticode.com: On Dec 12, 2008, at 3:38 PM, Pavel Stehule wrote: I discussed about this form with Tom. I thing so following should be readable: name: [ optional = ] value SELECT foo( bar: 'ick', baz: 'ack' ); SELECT foo( bar: = 'ick', baz: = 'ack' );

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 3:57 PM, Gregory Stark wrote: In any case this is all weird. SQL isn't C and doesn't have random bits of punctuation involved in syntax. It uses whole words for just about everything. Anything you do using punctuation characters is going to look out of place. Well,

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 3:56 PM, Pavel Stehule wrote: Hrm. I can see that, I guess. In that case, though, I think I'd prefer the colon at the beginning of the parameter label: SELECT foo( :bar = 'ick', :baz = 'ack' ); this syntax is used yet

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
David E. Wheeler da...@kineticode.com writes: Hrm. I can see that, I guess. In that case, though, I think I'd prefer the colon at the beginning of the parameter label: SELECT foo( :bar = 'ick', :baz = 'ack' ); That's ugly, and incompatible with ecpg syntax, and what's the redeeming value

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 12 déc. 08 à 15:57, Gregory Stark a écrit : These don't solve anything. There's nothing stopping you from defining a unary prefix operator = or = That's why I'm preferring the common-lisp syntax of :param value, or its variant param: value.

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: We could do it the other way round: SELECT foo( 'ick' AS bar, 'ack' AS baz); Yeah, that's the direction I had always assumed that we would use, if AS is the chosen syntax for this. regards, tom lane --

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Greg Stark
On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: That's why I'm preferring the common-lisp syntax of :param value, or its variant param: value. FWIW there is no such common-lisp syntax. Colon is just a regular symbol character and :param is just a regular symbol

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Douglas McNaught
On Fri, Dec 12, 2008 at 10:31 AM, Greg Stark st...@enterprisedb.com wrote: On Fri, Dec 12, 2008 at 3:11 PM, Dimitri Fontaine dfonta...@hi-media.com wrote: That's why I'm preferring the common-lisp syntax of :param value, or its variant param: value. FWIW there is no such common-lisp syntax.

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 4:06 PM, Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: Hrm. I can see that, I guess. In that case, though, I think I'd prefer the colon at the beginning of the parameter label: SELECT foo( :bar = 'ick', :baz = 'ack' ); That's ugly, and incompatible

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Michael Meskes
On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote: Hmm ... actually, ecpg might be a problem here anyway. I know it has special meaning for :name, but does it allow space between the colon and the name? If it does then the colon syntax loses. If it doesn't No. Here's the lexer rule:

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
Michael Meskes mes...@postgresql.org writes: On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote: Hmm ... actually, ecpg might be a problem here anyway. I know it has special meaning for :name, but does it allow space between the colon and the name? If it does then the colon syntax

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread David E. Wheeler
On Dec 12, 2008, at 7:05 PM, Tom Lane wrote: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed not break any existing features. Barring better ideas I think we should go with that one. +1 Best, David

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Andrew Dunstan
Tom Lane wrote: Michael Meskes mes...@postgresql.org writes: On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote: Hmm ... actually, ecpg might be a problem here anyway. I know it has special meaning for :name, but does it allow space between the colon and the name? If it does

Re: [HACKERS] WIP: default values for function parameters

2008-12-12 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: Excellent. I checked that psql's colon-variable feature behaves the same. So it looks like the proposed name: value syntax would indeed not break any existing features. Barring better ideas I think we should go with that one. Does that mean the

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Pavel Stehule
2008/12/10 Pavel Stehule [EMAIL PROTECTED]: 2008/12/10 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: next argument - if we accept AS for param names, then we introduce nonconsistent behave with SQL/XML functions. select xmlforest(c1, c2 as foo, c3) -- there foo isn't

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Bruce Momjian
Pavel Stehule wrote: 2008/12/10 Pavel Stehule [EMAIL PROTECTED]: 2008/12/10 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: next argument - if we accept AS for param names, then we introduce nonconsistent behave with SQL/XML functions. select xmlforest(c1, c2 as

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: what do you thing about? select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val) I'm not really seeing any redeeming social value in that. It's more keystrokes than the other; and if you dislike AS because of possible confusion with other usages

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Kevin Grittner
Tom Lane [EMAIL PROTECTED] wrote: In any case, I'm not wedded to using AS for this, and am happy to consider other suggestions. But = isn't acceptable. How about using a bare equals sign (or the = characters) for parameter assignment, but require that the parameter name be prefixed with

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Pavel Stehule
2008/12/11 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: what do you thing about? select fce(p1,p2,p3, SET paramname1 = val, paramname2 = val) I'm not really seeing any redeeming social value in that. It's more keystrokes than the other; and if you dislike AS because

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Pavel Stehule
2008/12/11 Kevin Grittner [EMAIL PROTECTED]: Tom Lane [EMAIL PROTECTED] wrote: In any case, I'm not wedded to using AS for this, and am happy to consider other suggestions. But = isn't acceptable. How about using a bare equals sign (or the = characters) for parameter assignment, but require

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Peter Eisentraut
On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote: maybe this combination should be safe $name = or $name - ... it's not used everywhere Why don't you actually just implement the whole thing first using a random, simple, and nonconflicting syntax? Adjusting the syntax to

Re: [HACKERS] WIP: default values for function parameters

2008-12-11 Thread Pavel Stehule
2008/12/11 Peter Eisentraut [EMAIL PROTECTED]: On Thursday 11 December 2008 17:11:28 Pavel Stehule wrote: maybe this combination should be safe $name = or $name - ... it's not used everywhere Why don't you actually just implement the whole thing first using a random, simple, and

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Bruce Momjian
Pavel Stehule wrote: How would a user recognise which of these are legal operator names? Incidentally -- EDB selling Oracle compatibility may put me in a questionable position here -- the more Oracle incompatibilities in stock Postgres the better for us. But afaik we don't emulate =

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Bruce Momjian
Pavel Stehule wrote: PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural. And it is my goal. Well, that is interesting, but in SQL we already use 'AS' in most places where we want to assign a label to a value, so it seems AS is more logical for SQL at this point.

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Pavel Stehule
2008/12/10 Bruce Momjian [EMAIL PROTECTED]: Pavel Stehule wrote: How would a user recognise which of these are legal operator names? Incidentally -- EDB selling Oracle compatibility may put me in a questionable position here -- the more Oracle incompatibilities in stock Postgres the

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Pavel Stehule
2008/12/10 Bruce Momjian [EMAIL PROTECTED]: Pavel Stehule wrote: PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural. And it is my goal. Well, that is interesting, but in SQL we already use 'AS' in most places where we want to assign a label to a value, so it seems AS is

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/10 Bruce Momjian [EMAIL PROTECTED]: Well, that is interesting, but in SQL we already use 'AS' in most places where we want to assign a label to a value, so it seems AS is more logical for SQL at this point. Question is - what is label - is it

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: look again select c as foo from tab ... select fce(c as foo) from tab ... when you use AS as param names specification, you change meaning of some construct via used context? Uh, what's your point? AS changes the meaning too. For example in select

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Pavel Stehule
2008/12/10 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/10 Bruce Momjian [EMAIL PROTECTED]: Well, that is interesting, but in SQL we already use 'AS' in most places where we want to assign a label to a value, so it seems AS is more logical for SQL at this point.

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Pavel Stehule
2008/12/10 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: look again select c as foo from tab ... select fce(c as foo) from tab ... when you use AS as param names specification, you change meaning of some construct via used context? Uh, what's your point? AS changes

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: next argument - if we accept AS for param names, then we introduce nonconsistent behave with SQL/XML functions. select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean use it as param foo, It could be read as meaning that, I think. In any

Re: [HACKERS] WIP: default values for function parameters

2008-12-10 Thread Pavel Stehule
2008/12/10 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: next argument - if we accept AS for param names, then we introduce nonconsistent behave with SQL/XML functions. select xmlforest(c1, c2 as foo, c3) -- there foo isn't doesn't mean use it as param foo, It could

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Grzegorz Jaskiewicz
if I may request one simple change/addition, Probably trivial to add, but I don't have too much time to give away now to any other project than one that pays my debts. The default param that's in the middle. Would it be hard, or do anyone objects against adding 'default' keyword there, so

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Grzegorz Jaskiewicz [EMAIL PROTECTED]: if I may request one simple change/addition, Probably trivial to add, but I don't have too much time to give away now to any other project than one that pays my debts. The default param that's in the middle. Would it be hard, or do anyone

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Peter Eisentraut
Grzegorz Jaskiewicz wrote: if I may request one simple change/addition, Probably trivial to add, but I don't have too much time to give away now to any other project than one that pays my debts. The default param that's in the middle. Would it be hard, or do anyone objects against adding

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Peter Eisentraut
Grzegorz Jaskiewicz wrote: Ok, how about CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] default '{6,7,8,90}'); and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}'); Yeah, that could be a useful feature. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes: The default param that's in the middle. Would it be hard, or do anyone objects against adding 'default' keyword there, so one doesn't have to substitute default param 3, when he only wants to override 2nd in funct(1,2,3) ? Yes, and yes. We

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Peter Eisentraut
Decibel! wrote: On Nov 30, 2008, at 12:04 PM, David E. Wheeler wrote: Agreed, default values should not be a part of function signatures, although it might be nice if ALTER FUNCTION to allow default values to be changed. It would be VERY nice. I routinely cut and paste an entire function

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Grzegorz Jaskiewicz
Ok, how about CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] default '{6,7,8,90}'); and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}'); I have no idea what SQL standard says in that case, all I know is that keyword DEFAULT exists in it, and is used in queries for

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Grzegorz Jaskiewicz [EMAIL PROTECTED]: Ok, how about CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[] default '{6,7,8,90}'); and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}'); I have no idea what SQL standard says in that case, all I know is that keyword

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: select foo(777, three= '{1,2,3,4,5}); it's more safe and more readable. ... and it breaks an operator that's already in use. I did some test, and I thing so it is implementable. I had to solve problem with hstore module. There is defined operator =

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: select foo(777, three= '{1,2,3,4,5}); it's more safe and more readable. ... and it breaks an operator that's already in use. I did some test, and I thing so it is implementable. I had to solve problem with

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: ... and it breaks an operator that's already in use. what is acceptable workaround? I unhappy, so this symbol was used for this minor contrib module (for this operator doesn't exists regress test). If you could

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: ... and it breaks an operator that's already in use. what is acceptable workaround? I unhappy, so this symbol was used for this minor contrib module (for this operator doesn't

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: If you could prove that it were *only* being used by this contrib module then I might hold still for replacing it. But you can't. The odds are good that people have custom data types using similarly-named

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Robert Haas
it means, so we must not implement any new operator? If the operator were called [EMAIL PROTECTED], I think you could make a good argument that no one else is likely using that for anything. Surely the same cannot be said of = Of course, [EMAIL PROTECTED] is not a very convenient name for an

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: If you could prove that it were *only* being used by this contrib module then I might hold still for replacing it. But you can't. The odds are good that people have custom

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: what is problematic on GUC? Basically, it's a bad idea to have GUCs that silently make significant changes in the syntactic meaning of a query. We've learned that lesson the hard way I think. There are places where we've been forced to do it because of

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Gregory Stark
Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: 2008/12/9 Tom Lane [EMAIL PROTECTED]: ... and it breaks an operator that's already in use. what is acceptable workaround? I unhappy, so this symbol was used for this minor

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
How would a user recognise which of these are legal operator names? Incidentally -- EDB selling Oracle compatibility may put me in a questionable position here -- the more Oracle incompatibilities in stock Postgres the better for us. But afaik we don't emulate = anyways so that hardly

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural. And it is my goal. [ shrug... ] Don't be too surprised when the patch gets rejected. Oracle compatibility is nice when we can get it, but we aren't going to break existing behavior for

Re: [HACKERS] WIP: default values for function parameters

2008-12-09 Thread Pavel Stehule
2008/12/9 Tom Lane [EMAIL PROTECTED]: Pavel Stehule [EMAIL PROTECTED] writes: PL/pgSQL PL/SQL ADA so using '=' is only consistent and natural. And it is my goal. [ shrug... ] Don't be too surprised when the patch gets rejected. Oracle compatibility is nice when we can get it, but we

  1   2   >