Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
>> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>>> record or hash table - it's implementation - second step. We have to
>>> find syntax and semantic now.
>
>> Why not just use some standard record syntax, like
>> SELECT(value::type name, ...)
>
> Yeah, that's one way.  It also strikes me that hstore itself provides a
> usable solution to this problem, though only for simple-string values.
> That is, you could do something like
>
>create function myfunc(hstore) returns ...
>
>select myfunc('tag1' => '42' || 'tag2' => 'foobar' || ...);
>
> Or, with the new variadic function support,
>
>create function myfunc(variadic hstore[]) returns ...
>
>select myfunc('tag1' => '42', 'tag2' => 'foobar', ...);
>
> which is just a couple of quote marks away from the syntax Pavel
> wants.
>

it's not far. I am only doesn't know if is it labeled params or named
params :). Using hstore is usable, but I dislike it. There is small
overhead and would to use named params for classic functions - with
different types and fixed count of params. I am thinking so first step
is implementation of defaults without named params like firebird. It's
less controversy.

regards
Pavel Stehule

>regards, tom lane
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new border setting in psql

[D'Arcy J.M. Cain]

On Sat, 23 Aug 2008 14:57:50 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, having now looked at the proposed patch, it seems clear that it
> isn't addressing the issue of quoting/escaping at all; so I wonder how
> this can be considered to be a safely machine-readable format.

It's not a machine readable format.  It is a simple display with more
border lines.  Just like "border 2" is like "border 1" with more border
lines.  I'm just following the progression.

> In particular, the output seems to me to not even approximate the rules
> laid down at
> http://docutils.sourceforge.net/docs/user/rst/quickref.html

And there is no reason that it should.

> So, quite aside from the question of whether we care to support ReST,
> my opinion is that this patch fails to do so, and a significantly more
> invasive patch would be needed to do it.

I suppose it is my fault for mentioning ReST.  That was the reason I
looked into this but that is not what the final proposal is.  I too
would argue against making a munged output just to match one formatting
scheme.  If I do a query and I need to modify it manually when I use it
in *any* third party program that's my personal issue.  If "border 3"
happens to get me closer to my format that's great but it has to stand
on its own merit.  I think that this proopsal does.

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

2008/8/24 daveg <[EMAIL PROTECTED]>:
> On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>
>> > Hello
>> >
>> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> >>> If we're really worried about it we can have a GUC for a few versions
>> >>> that turns off named parameter assignment. But I don't think we
>> >>> should compromise the design on the theory that some folks might be
>> >>> using that as an operator *and* can't change their application to
>> >>> wrap it's use in ().
>> >>
>> >> Even if that were a reasonable strategy, you can't use GUC parameters to 
>> >> alter
>> >> parser behavior.
>> >
>> > I thing, so it's possible - in this case. We should transform named
>> > params to expr  after syntax analyze.
>>
>> So for a bit of useless syntactic sugar we should introduce conflicts with
>> named parameters, conflicts with operators, introduce an un-sqlish syntax and
>> remove a feature users have already made use of and introduce backwards
>> compatibility issues for those users?
>>
>> At any point in this discussion has anyone explained why these labels would
>> actually be a good idea?
>
> I was missing that too. What is this for that makes it so compelling?

We are talking about two features (or three).

1. Named params (and defaults for params) - allows call function with
less params or with params in different order. - default parameters
allows decrease size of libraries (number of functions). Using default
without named params isn't comfortable (Firebird 2 do it), so we would
named params - named params specifies "some param has value ...",
developer shouldn't specify all params. sure - this functionality is
syntactic sugar and are not necessary - it only increase developer's
comfort.

2. Labeled params - put some knowledge (labels) about used params into
function. This is usable for mainly for serialization and dump
function (typical real case is SQL/XML). Other case are custom
functions in MySQL -
http://www.mysqludf.org/lib_mysqludf_json/index.php , sure - this
functionality is syntactic sugar and are not necessary - it only
increase developer's comfort. Labels params mean "for this value use
label". It same as standard keyword "AS" do it. Labeled params allows
explicit labels or implicit labels (column names).

Regards
Pavel Stehule



>
> -dg
>
>
> --
> David Gould   [EMAIL PROTECTED]  510 536 1443510 282 0869
> If simplicity worked, the world would be overrun with insects.
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new border setting in psql

[D'Arcy J.M. Cain]

On Sat, 23 Aug 2008 14:42:57 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> In general I think I prefer machine readable formats to be produces by 
> the backend so they are available through all clients, not just psql.

What do you mean by "machine readable?"  XML?

> That said, this has sufficiently low impact that I'm not going to be 
> vastly upset if we let it through.
> 
> I think we should probably confine ourselves to output formats that are 
> in very wide use or we'll be supporting a vast multitude. CSV and XML 
> both qualify here - not sure that ReST does.

It isn't ReST.  It just happens that this very simple and logical
progression of the border setting works for ReST.  The display stands
on its own.  This is not true of machine readable formats like XML.  I
guess the question is, why border 2? Border 1 seems to be enough.  In
fact border 0 has everything we absolutely need.  Why have any borders?

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

2008/8/23 Hannu Krosing <[EMAIL PROTECTED]>:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
>> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
>> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
>> >
>> >> How about we poll -general and see what people say? I'll bet Tom a
>> >> beer that no one replies saying they've created a => operator (unless
>> >> maybe PostGIS uses it).
>> >
>> > Does Oracle use => for "labeled function params" or just named
>> > arguments ?
>> >
>>
>> Oracle use it for named arguments - what I know, similar it doesn't
>> allow functionality as labeled params publicly - SQL/XML use it.
>>
>> >> If we're really worried about it we can have a GUC for a few versions
>> >> that turns off named parameter assignment. But I don't think we
>> >> should compromise the design on the theory that some folks might be
>> >> using that as an operator *and* can't change their application to
>> >> wrap it's use in ().
>> >
>> > I still think that better approach is allowing RECORD as input type and
>> > do all the things Pavel proposed with a function that iterates over
>> > record.
>> >
>>
>> record or hash table - it's implementation - second step. We have to
>> find syntax and semantic now.
>
> Why not just use some standard record syntax, like
>
> SELECT(value::type name, ...)
>
> or perhaps some extended ROW() or VALUES() syntax ?
>
> Like this :
>  SELECT * FROM FUNC(SELECT(value::type name, ...) AS r);
>

do you thing, so is it simpler?

Pavel

> -
> Hannu
>
>
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What in the world is happening on spoonbill?

[Tom Lane]

"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure all browsing setups support tooltips nicely.

> Any half way modern browser that is not text based should support tool tips.

Are we in the business of excluding text-based browsers?  Or obsolete
ones, for that matter?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[daveg]

On Sat, Aug 23, 2008 at 05:08:25PM +0100, Gregory Stark wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 
> > Hello
> >
> > 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> >> On Friday 22 August 2008 07:41:30 Decibel! wrote:
> >>> If we're really worried about it we can have a GUC for a few versions
> >>> that turns off named parameter assignment. But I don't think we
> >>> should compromise the design on the theory that some folks might be
> >>> using that as an operator *and* can't change their application to
> >>> wrap it's use in ().
> >>
> >> Even if that were a reasonable strategy, you can't use GUC parameters to 
> >> alter
> >> parser behavior.
> >
> > I thing, so it's possible - in this case. We should transform named
> > params to expr  after syntax analyze.
> 
> So for a bit of useless syntactic sugar we should introduce conflicts with
> named parameters, conflicts with operators, introduce an un-sqlish syntax and
> remove a feature users have already made use of and introduce backwards
> compatibility issues for those users?
> 
> At any point in this discussion has anyone explained why these labels would
> actually be a good idea?

I was missing that too. What is this for that makes it so compelling?

-dg
 

-- 
David Gould   [EMAIL PROTECTED]  510 536 1443510 282 0869
If simplicity worked, the world would be overrun with insects.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What in the world is happening on spoonbill?

[Joshua D. Drake]

Tom Lane wrote:

Andrew Dunstan <[EMAIL PROTECTED]> writes:
Yes, I started on it. The problem is that we have very little real 
estate available on the dashboard to display it. I tried making it 
available as a tooltip but Tom didn't like that much (in private 
correspondence), and I didn't get back to doing something else. But the 
database changes are there. So, how/where would people like member 
annotations displayed?


Hmm, well, a tooltip is certainly better than nothing at all.

I don't recall exactly what I said about tooltips in the mail you're
referring to, but the main objection I can think of right now is that
I'm not sure all browsing setups support tooltips nicely.


Any half way modern browser that is not text based should support tool tips.

Joshua D. Drake



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Tom Lane]

Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
>> record or hash table - it's implementation - second step. We have to
>> find syntax and semantic now.

> Why not just use some standard record syntax, like 
> SELECT(value::type name, ...)

Yeah, that's one way.  It also strikes me that hstore itself provides a
usable solution to this problem, though only for simple-string values.
That is, you could do something like

create function myfunc(hstore) returns ...

select myfunc('tag1' => '42' || 'tag2' => 'foobar' || ...);

Or, with the new variadic function support,

create function myfunc(variadic hstore[]) returns ...

select myfunc('tag1' => '42', 'tag2' => 'foobar', ...);

which is just a couple of quote marks away from the syntax Pavel
wants.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What in the world is happening on spoonbill?

[Tom Lane]

Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yes, I started on it. The problem is that we have very little real 
> estate available on the dashboard to display it. I tried making it 
> available as a tooltip but Tom didn't like that much (in private 
> correspondence), and I didn't get back to doing something else. But the 
> database changes are there. So, how/where would people like member 
> annotations displayed?

Hmm, well, a tooltip is certainly better than nothing at all.

I don't recall exactly what I said about tooltips in the mail you're
referring to, but the main objection I can think of right now is that
I'm not sure all browsing setups support tooltips nicely.

Perhaps another way is to include the machine description details in
the per-animal status history page, eg in or under the "System Detail"
bit at
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=spoonbill&br=HEAD

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What in the world is happening on spoonbill?

[Andrew Dunstan]

Alvaro Herrera wrote:
  
But maybe it would be nice to have some sort of "notes about this  
buildfarm member" text field that contains this information (or other  
stuff like "this is a VM running on bar" or "this is really the same  
hardware as animal bar just with configuration baz" ?



Apparently Andrew has been working on it, but it's not yet visible on
the web page anywhere.

  


Yes, I started on it. The problem is that we have very little real 
estate available on the dashboard to display it. I tried making it 
available as a tooltip but Tom didn't like that much (in private 
correspondence), and I didn't get back to doing something else. But the 
database changes are there. So, how/where would people like member 
annotations displayed?


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Greg Stark]

>>
>> At any point in this discussion has anyone explained why these  
>> labels would
>> actually be a good idea?
>>
>
> it's allows smart libraries like SQL/XML

You could always just pass the label as an additional parameter. Which  
is all this would be syntactic sugar for anyways. So it doesn't  
"allow" such libraries it just let users type foo(bar=>'baz') instead  
of foo('bar','baz'). Not much gain for all this pain. 

Re: [HACKERS] Proposal: new border setting in psql

[Andrew Dunstan]

D'Arcy J.M. Cain wrote:

On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
  

There's still the question of whether this covers any needs that aren't
met just as well by XML or CSV output formats.
  

Well, we could remove all the display formats except XML.  After all,
it can always be converted to any other format.  Of course we wouldn't
do that. User convenience is all I'm thinking of.



Well, Tom has raised a question about its need and Asko has questioned
whether it should be under a different setting but so far no one has
outright rejected the proposal.  Does anyone else have an opinion?  I am
attaching a patch for further review.  

  



In general I think I prefer machine readable formats to be produces by 
the backend so they are available through all clients, not just psql.


That said, this has sufficiently low impact that I'm not going to be 
vastly upset if we let it through.


I think we should probably confine ourselves to output formats that are 
in very wide use or we'll be supporting a vast multitude. CSV and XML 
both qualify here - not sure that ReST does.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

> So for a bit of useless syntactic sugar we should introduce conflicts with
> named parameters, conflicts with operators, introduce an un-sqlish syntax and
> remove a feature users have already made use of and introduce backwards
> compatibility issues for those users?
>
we talk only about "=>" symbol. What I googled, I never to find any
database that use AS for named params, and I don't really to create
next proprietary syntax (I would not to wait to ANSI). AS is usable,
but I don't think so it is good idea - it change sense of AS keyword
in SQL.

Oracle: fce (param => expr)
MSSQL: fce @param = expr
Firebird 2.0 allows defaults, but doesn't support named params


> At any point in this discussion has anyone explained why these labels would
> actually be a good idea?
>

it's allows smart libraries like SQL/XML
regards
Pavel Stehule

> --
>  Gregory Stark
>  EnterpriseDB  http://www.enterprisedb.com
>  Ask me about EnterpriseDB's 24x7 Postgres support!
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

2008/8/23 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I thing, so it's possible - in this case. We should transform named
>> params to expr  after syntax analyze.
>
> You're going to have a hard time making parentheses affect the behavior
> if you do it that way.
>
>regards, tom lane
>

I don't prefer this way
regards
Pavel Stehule

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> > with GRANT/REVOKE.  Peter, Tom, how is GRANT/REVOKE different?
> 
> GRANT/REVOKE behavior is specified by the standard, whereas the stuff
> we allow under ALTER VIEW is all an extension to the standard --- not
> merely syntax-wise, but functionality.
> 
> A concrete reason not to do it is that if someone writes GRANT ON VIEW,
> their code won't port to other DBs that are following the spec, and
> it'll be only because we allowed non-spec syntactic sugar, not because
> they're using functionality not covered by the spec.
> 
> We routinely complain about mysql inventing nonstandard ways to express
> things that have perfectly good spec-compliant equivalents.  How would
> this be different?

OK, so this is a standards issue, then, OK, makes sense.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] What in the world is happening on spoonbill?

[Alvaro Herrera]

Stefan Kaltenbrunner wrote:
> Tom Lane wrote:

>> Can you modify the buildfarm's description of that machine to mention
>> the special malloc debug flags?  It'd probably stop me from asking
>> you this question again ;-)
>
> hmm - would take somebody with SQL-level access to do this - the script  
> to update OS/compiler related data is only partially(ie not updating all  
> information) working...

I've changed the compiler to read gcc-malloc-FGJPZ on spoonbill.

BTW this animal has not updated in quite a few days ... is this
expected?

> But maybe it would be nice to have some sort of "notes about this  
> buildfarm member" text field that contains this information (or other  
> stuff like "this is a VM running on bar" or "this is really the same  
> hardware as animal bar just with configuration baz" ?

Apparently Andrew has been working on it, but it's not yet visible on
the web page anywhere.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new border setting in psql

[Tom Lane]

Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think we should probably confine ourselves to output formats that are 
> in very wide use or we'll be supporting a vast multitude. CSV and XML 
> both qualify here - not sure that ReST does.

Yeah, that's the core of my objection.

Also, having now looked at the proposed patch, it seems clear that it
isn't addressing the issue of quoting/escaping at all; so I wonder how
this can be considered to be a safely machine-readable format.
In particular, the output seems to me to not even approximate the rules
laid down at
http://docutils.sourceforge.net/docs/user/rst/quickref.html
which among other things requires backslashing of literal asterisk,
backquote, vertical bar, and underscore in order to avoid textual data
looking like it matches the format's inline-markup constructs.

So, quite aside from the question of whether we care to support ReST,
my opinion is that this patch fails to do so, and a significantly more
invasive patch would be needed to do it.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Bruce Momjian]

Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> >>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
> >> 
> >> The SQL standard doesn't specify it.  And there is no need for it.
> 
> > While we don't _need_ it, it would make our system more consistent;  we
> > have made similar changes for views in other areas.
> 
> I'm not sure it'd make the system more consistent.  Because the SQL
> standard says you use GRANT ON TABLE for a view. we'd have to always
> ensure that we accepted that; whereas in at least some other places
> we are trying to be picky about TABLE/VIEW/SEQUENCE actually matching
> the object type.
> 
> Given the spec precedent, I'm inclined to leave it alone.  It's not like
> there aren't plenty of other SQL quirks that surprise novices.

OK, removed from TODO.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Bruce Momjian]

Robert Haas wrote:
> >> While we don't _need_ it, it would make our system more consistent;  we
> >> have made similar changes for views in other areas.
> >
> > I'm not sure it'd make the system more consistent.  Because the SQL
> > standard says you use GRANT ON TABLE for a view. we'd have to always
> > ensure that we accepted that; whereas in at least some other places
> > we are trying to be picky about TABLE/VIEW/SEQUENCE actually matching
> > the object type.
> >
> > Given the spec precedent, I'm inclined to leave it alone.  It's not like
> > there aren't plenty of other SQL quirks that surprise novices.
> 
> I fail to understand why it's advantageous to artificially create
> surprising behavior.  There are cases where PostgreSQL now accepts
> either ALTER VIEW or ALTER TABLE where it previously accepted only the
> latter, so the situation is hardly without precedent.  I find it
> exceedingly unlikely that anyone is relying on GRANT ON VIEW to NOT
> work.

Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
with GRANT/REVOKE.  Peter, Tom, how is GRANT/REVOKE different?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Hannu Krosing]

On Sat, 2008-08-23 at 08:21 +0200, Pavel Stehule wrote:
> Hello
> 
> 2008/8/22 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
> >> On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:
> >
> >> How about we poll -general and see what people say? I'll bet Tom a
> >> beer that no one replies saying they've created a => operator (unless
> >> maybe PostGIS uses it).
> >
> > Does Oracle use => for "labeled function params" or just named
> > arguments ?
> >
> 
> Oracle use it for named arguments - what I know, similar it doesn't
> allow functionality as labeled params publicly - SQL/XML use it.
> 
> >> If we're really worried about it we can have a GUC for a few versions
> >> that turns off named parameter assignment. But I don't think we
> >> should compromise the design on the theory that some folks might be
> >> using that as an operator *and* can't change their application to
> >> wrap it's use in ().
> >
> > I still think that better approach is allowing RECORD as input type and
> > do all the things Pavel proposed with a function that iterates over
> > record.
> >
> 
> record or hash table - it's implementation - second step. We have to
> find syntax and semantic now.

Why not just use some standard record syntax, like 

SELECT(value::type name, ...)

or perhaps some extended ROW() or VALUES() syntax ?

Like this :
  SELECT * FROM FUNC(SELECT(value::type name, ...) AS r);

-
Hannu



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Robert Haas]

>> While we don't _need_ it, it would make our system more consistent;  we
>> have made similar changes for views in other areas.
>
> I'm not sure it'd make the system more consistent.  Because the SQL
> standard says you use GRANT ON TABLE for a view. we'd have to always
> ensure that we accepted that; whereas in at least some other places
> we are trying to be picky about TABLE/VIEW/SEQUENCE actually matching
> the object type.
>
> Given the spec precedent, I'm inclined to leave it alone.  It's not like
> there aren't plenty of other SQL quirks that surprise novices.

I fail to understand why it's advantageous to artificially create
surprising behavior.  There are cases where PostgreSQL now accepts
either ALTER VIEW or ALTER TABLE where it previously accepted only the
latter, so the situation is hardly without precedent.  I find it
exceedingly unlikely that anyone is relying on GRANT ON VIEW to NOT
work.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> with GRANT/REVOKE.  Peter, Tom, how is GRANT/REVOKE different?

GRANT/REVOKE behavior is specified by the standard, whereas the stuff
we allow under ALTER VIEW is all an extension to the standard --- not
merely syntax-wise, but functionality.

A concrete reason not to do it is that if someone writes GRANT ON VIEW,
their code won't port to other DBs that are following the spec, and
it'll be only because we allowed non-spec syntactic sugar, not because
they're using functionality not covered by the spec.

We routinely complain about mysql inventing nonstandard ways to express
things that have perfectly good spec-compliant equivalents.  How would
this be different?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> bruce wrote:
>> Tom Lane wrote:
>>> Currently, config.sgml still describes the new "enum" GUC variables
>>> as being of type "string" --- but pg_settings says they are "enum".
>>> This is not very consistent, but I wonder whether changing the docs
>>> would be more confusing or less so.  I note that section 18.1 doesn't
>>> mention the enum alternative either.
>> 
>> I looked into this and I think the documentation is fine.  If enums
>> didn't require quotes but strings did, we would document them
>> differently, but the fact is that enums are the same as strings except
>> enums have a limited number of possible values --- that isn't something
>> that is usually identified in a variable type definition heading.

By that logic, we should not distinguish integers and floats.  One's
just a restricted form of the other.

> Looking further, it seems we still have an inconsistency problem because
> pg_settings mentions enum;  should we just change that to 'string'?

No, and in fact pg_settings is the counterexample to your conclusion
that it's okay to pretend enums are the same as strings: since it has an
enumvals column that's populated for enums and not for strings, there
is clearly a genuine user-visible difference.


Last I checked, Magnus had promised to come up with suitable
documentation changes for this patch, but then he went off sailing...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Tom Lane]

"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I thing, so it's possible - in this case. We should transform named
> params to expr  after syntax analyze.

You're going to have a hard time making parentheses affect the behavior
if you do it that way.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Tom Lane]

Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
>>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
>> 
>> The SQL standard doesn't specify it.  And there is no need for it.

> While we don't _need_ it, it would make our system more consistent;  we
> have made similar changes for views in other areas.

I'm not sure it'd make the system more consistent.  Because the SQL
standard says you use GRANT ON TABLE for a view. we'd have to always
ensure that we accepted that; whereas in at least some other places
we are trying to be picky about TABLE/VIEW/SEQUENCE actually matching
the object type.

Given the spec precedent, I'm inclined to leave it alone.  It's not like
there aren't plenty of other SQL quirks that surprise novices.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Gregory Stark]

"Pavel Stehule" <[EMAIL PROTECTED]> writes:

> Hello
>
> 2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
>> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>>> If we're really worried about it we can have a GUC for a few versions
>>> that turns off named parameter assignment. But I don't think we
>>> should compromise the design on the theory that some folks might be
>>> using that as an operator *and* can't change their application to
>>> wrap it's use in ().
>>
>> Even if that were a reasonable strategy, you can't use GUC parameters to 
>> alter
>> parser behavior.
>
> I thing, so it's possible - in this case. We should transform named
> params to expr  after syntax analyze.

So for a bit of useless syntactic sugar we should introduce conflicts with
named parameters, conflicts with operators, introduce an un-sqlish syntax and
remove a feature users have already made use of and introduce backwards
compatibility issues for those users?

At any point in this discussion has anyone explained why these labels would
actually be a good idea?

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WITH RECURSIVE patches 0818

[David Fetter]

On Sat, Aug 23, 2008 at 03:35:52PM +0900, Tatsuo Ishii wrote:
> > > Here is new patches fixing the bug you pointed out (patches was
> > > created by Yoshiyuki). Also I added your SQL to the regression
> > > test, and now the patches is against CVS HEAD. For your
> > > convenience I also include patches against the previous version.
> > 
> > Thanks :)
> > 
> > Any progress on the READMEs for this?
> 
> I have posted kind of README (implementation.txt) along with patches
> on Aug 18. Have you read it?

Oops.  I've now put it up with some minor edits and formatting at
.  It is linked from the
Commitfest page.

> > Also, now that we are into August, would Asaba-san and whomever else
> > like to try out the git repository?  To do so, I just need a login
> > name and a public key.
> 
> I will send you later.

Thanks :)

Cheers,
David.
-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: [EMAIL PROTECTED]

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Pavel Stehule]

Hello

2008/8/23 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> If we're really worried about it we can have a GUC for a few versions
>> that turns off named parameter assignment. But I don't think we
>> should compromise the design on the theory that some folks might be
>> using that as an operator *and* can't change their application to
>> wrap it's use in ().
>
> Even if that were a reasonable strategy, you can't use GUC parameters to alter
> parser behavior.
>

I thing, so it's possible - in this case. We should transform named
params to expr  after syntax analyze.

Pavel

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new border setting in psql

[D'Arcy J.M. Cain]

On Thu, 21 Aug 2008 21:04:07 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > There's still the question of whether this covers any needs that aren't
> > met just as well by XML or CSV output formats.
> 
> Well, we could remove all the display formats except XML.  After all,
> it can always be converted to any other format.  Of course we wouldn't
> do that. User convenience is all I'm thinking of.

Well, Tom has raised a question about its need and Asko has questioned
whether it should be under a different setting but so far no one has
outright rejected the proposal.  Does anyone else have an opinion?  I am
attaching a patch for further review.  

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.


border_change.diff
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Bruce Momjian]

Peter Eisentraut wrote:
> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> > Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
> 
> The SQL standard doesn't specify it.  And there is no need for it.

While we don't _need_ it, it would make our system more consistent;  we
have made similar changes for views in other areas.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Feeding results back into select

[D'Arcy J.M. Cain]

On Sat, 23 Aug 2008 14:04:30 +0400
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> >> select 'a'=>'b';
> >>?column?
> >> --
> >>"a"=>"b"
> "a"=>"b" is a value of hstore type, so query should be:
> select '"a"=>"b"'::hstore;

Of course.  Now that I understand it's blindingly obvious that the
double quotes above are part of the string and the insert would be;
  INSERT INTO table (hfield) VALUES ('"a"=>"b"');

> " character was chosen to simplify escaping,

To prevent;
  INSERT INTO table (hfield) VALUES ('''a''=>''b''');

I guess my brain was pointed elsewhere when I asked.  Thanks for not
treating me like an idiot.  :-)

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GENERAL] Surprising syntax error

[Peter Eisentraut]

On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?

The SQL standard doesn't specify it.  And there is no need for it.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CREATE CAST too strict?

[Peter Eisentraut]

On Friday 22 August 2008 22:25:08 Bruce Momjian wrote:
> Peter, have you completed this yet?

yes

>
> ---
>
> Peter Eisentraut wrote:
> > Am Mittwoch, 9. Juli 2008 schrieb Peter Eisentraut:
> > > I propose that we relax these two checks to test for
> > > binary-coercibility instead, which is effectively what is expected and
> > > required here anyway.
> >
> > Here is the corresponding patch.
>
> [ Attachment, skipping... ]
>
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
>
> --
>   Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
>   EnterpriseDB http://enterprisedb.com
>
>   + If your life is a hard drive, Christ can be your backup. +



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] proposal sql: labeled function params

[Peter Eisentraut]

On Friday 22 August 2008 07:41:30 Decibel! wrote:
> If we're really worried about it we can have a GUC for a few versions  
> that turns off named parameter assignment. But I don't think we  
> should compromise the design on the theory that some folks might be  
> using that as an operator *and* can't change their application to  
> wrap it's use in ().

Even if that were a reasonable strategy, you can't use GUC parameters to alter 
parser behavior.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Feeding results back into select

[Teodor Sigaev]

select 'a'=>'b';
   ?column?
--
   "a"=>"b"






Branching the topic, I have a question about this.  I haven't studied
hstore extensively but this seems like a problem on it's face.
Shouldn't you be able to take the result of a select and pass it back
to a select?  I mean, what happens if you do this?



"a"=>"b" is a value of hstore type, so query should be:
select '"a"=>"b"'::hstore;

" character was chosen to simplify escaping,


I ran into a similar issue with my chkpass type (see contrib) where the
string inserted into the field is stored encrypted with functions to
test for equality basically like the Unix password model works.  If I
just displayed raw strings then a dump and reload would have trashed
all the passwords by re-encrypting them.  What I did was to make a
special case on input.  If the string started with ':' then I strip
that character and insert the string unchanged.  Then I changed the
output to prepend the ':'.  Now dump and reload work.


I see, but your problem is that password is one-way encrypted, so, you 
definitely need to distinguish already encrypted strings. Hstore hasn't that 
problem.





--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers