On 02/04/2013 04:19 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan <and...@dunslane.net> wrote:
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas <robertmh...@gmail.com>
wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan <and...@dunslane.net>
wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot of pain working toward eliminating
=> as an operator name, and if the SQL standard has commandeered ->
for some purpose or other, I'd really rather not add to the headaches
involved should we ever decide to reclaim it.
OK, but I'd like to know what is going to be safe. There's no way to
future-proof the language. I'm quite prepared to replace -> with
something
else, and if I do then ->> will need to be adjusted accordingly, I
think.
My suggestion would be ~> and ~>>. I know David Wheeler didn't like that
on
the ground that some fonts elevate ~ rather than aligning it in the
middle
as most monospaced fonts do, but I'm tempted just to say "then use a
different font." Other possibilities that come to mind are +> and +>>,
although I think they're less attractive. But I'll be guided by the
consensus, assuming there is one ;-)
I suspect both of those are pretty safe from an SQL standards point of
view. Of course, as Tom is often wont to point out, the SQL standards
committee sometimes does bizarre things, so nothing's perfect, but I'd
be rather shocked if any of those got tapped to mean something else.
That having been said, I still don't see value in adding operators at
all. Good old function call notation seems perfectly adequate from
where I sit. Sure, it's a little more verbose, but when you try to
too hard make things concise then you end up having to explain to your
users why \ditS is a sensible thing for them to type into psql, or why
s@\W@sprintf"%%%02x",ord($&)@e in Perl. I recognize that I may lose
this argument, but I've worked with a couple of languages where
operators can be overloaded (C++) or defined (ML) and it's just never
seemed to work out very well. YMMV, of course.
I also basically feel this way, although I know I tend more towards
notational brutalism than many. I think we shouldn't kid ourselves
that non-default operators will be used, and for
current-implementation reasons (that maybe could be fixed by someone
determined) it's not really at the pleasure of the author to use them
via CREATE OPERATOR either.
So, I basically subscribe to view that we should investigate what
total reliance on prefix syntax looks like. I guess it'll make nested
navigation horribly ugly, though...positively lisp-esque. That' s one
consideration hstore doesn't have that may make use of infix notations
considerably more useful for json than hstore.
We don't have the luxury of designing things like this in or out from
scratch. Creation of operators has been a part of PostgreSQL for a good
while longer than my involvement, and a great many people expect to be able
to use it. I can just imagine the outrage at any suggestion of removing it.
I am only referring to referring the restriction that the planner
can't understand that fetchval() and '->' mean the same thing for,
say, hstore. Hence, use of non-default CREATE OPERATOR may become
more useful some day, instead of basically being a pitfall when
someone reasonably thinks they could use either spelling of the same
functionality and the optimizer will figure it out.
I'm not suggesting removal of any feature.
My reference to "total reliance of prefix syntax" refers only to the
JSON operators, since the previous correspondence from Robert was
about how function call syntax alone may be sufficient. This phrase
refers to the same idea he is proposing.
I also included a weakness to that idea, which is that nesting in JSON
makes the situation worse than the common compared case, hstore.
I see. OK, sorry for misunderstanding.
I suspect, BTW that mostly people will use get_path*() (or rather, its
equivalent operator ;-) ) rather than operator chaining:
select myjson->>'{"authors",0,"name"}'::text[];
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
