On 2022-Feb-13, Guyren Howe wrote:
> I’m back to just having no earthly idea why anyone who finds relations
> to be a productive tool for building a model would think that SQL
> being the only means to do that is Okay.
There are aspects other than technical reasons alone why some things
live on
On Tue, Feb 15, 2022 at 02:18:35PM -0600, Merlin Moncure wrote:
> Exactly. SQL is proven to be more productive and code written in it
> has longer longevity than alternatives. It's also generally more
> terse in the hands of a good author. The authors of all the 'SQL
> sucks' rants don't really
On Sun, Feb 13, 2022 at 4:00 AM Pavel Stehule wrote:
>
>
>
> ne 13. 2. 2022 v 10:45 odesílatel Guyren Howe napsal:
>>
>>
>> The MySQL autocomplete is designed without context filtering. Maybe we can
>> have this implementation too (as alternative)
>>
>> so using all column names + all table
On 2/13/22 05:00, Pavel Stehule wrote:
But there can be a valid second question - it can be nice to use
extensions with availability to define their own communication
protocol. Postgres has a special protocol for replication or for
backup. With this possibility you can do what you need without
ne 13. 2. 2022 v 10:45 odesílatel Guyren Howe napsal:
>
> The MySQL autocomplete is designed without context filtering. Maybe we can
> have this implementation too (as alternative)
>
> so using all column names + all table names + aliases.column names (when
> we know defined alias)
>
> Another
> > The MySQL autocomplete is designed without context filtering. Maybe we can
> > have this implementation too (as alternative)
> >
> > so using all column names + all table names + aliases.column names (when we
> > know defined alias)
> >
> > Another idea about column excluding. Any
ne 13. 2. 2022 v 9:29 odesílatel Peter J. Holzer napsal:
> On 2022-02-13 01:11:16 +0100, Andreas 'ads' Scherbaum wrote:
> > On 12/02/2022 22:34, Peter J. Holzer wrote:
> > > On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote:
> > > > On 12/02/2022 20:50, Peter J. Holzer wrote:
> > > > >
On 2022-02-12 20:12:02 -0500, Mladen Gogala wrote:
> On 2/12/22 19:11, Andreas 'ads' Scherbaum wrote:
>
> The complaint is not about complex queries, or CTEs, or Joins. This is
> about simple queries where a user wants to discover - surf - the database
> and look into specific tables,
On 2022-02-13 01:11:16 +0100, Andreas 'ads' Scherbaum wrote:
> On 12/02/2022 22:34, Peter J. Holzer wrote:
> > On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote:
> > > On 12/02/2022 20:50, Peter J. Holzer wrote:
> > > > On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
> > > >
On 2/12/22 19:11, Andreas 'ads' Scherbaum wrote:
The complaint is not about complex queries, or CTEs, or Joins. This is
about simple queries where a user wants to discover - surf - the database
and look into specific tables, but exclude certain columns. More
specifically,
this is when the user
On 12/02/2022 22:34, Peter J. Holzer wrote:
On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote:
On 12/02/2022 20:50, Peter J. Holzer wrote:
On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
On 10/02/2022 18:22, Peter J. Holzer wrote:
On 2022-02-09 21:14:39 -0800, Guyren
On 2022-02-12 13:23:39 -0800, Adrian Klaver wrote:
> On 2/12/22 13:17, Peter J. Holzer wrote:
> > A shell could also provide an "expand select list" function using
> > explain.
> >
> > In fact, you can sort of do that manually:
> >
> > 1) Prefix your query with explain(verbose)
> > 2) Copy the
On 2022-02-12 22:09:25 +0100, Andreas 'ads' Scherbaum wrote:
> On 12/02/2022 20:50, Peter J. Holzer wrote:
> > On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
> > > On 10/02/2022 18:22, Peter J. Holzer wrote:
> > > > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > > > Examples
On 2/12/22 13:17, Peter J. Holzer wrote:
On 2022-02-12 20:50:57 +0100, Peter J. Holzer wrote:
On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
On 10/02/2022 18:22, Peter J. Holzer wrote:
On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
Examples of small things Postgres could
On 2022-02-12 20:50:57 +0100, Peter J. Holzer wrote:
> On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
> > On 10/02/2022 18:22, Peter J. Holzer wrote:
> > > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > > Examples of small things Postgres could have:
> > > >
> > > >•
On 12/02/2022 20:50, Peter J. Holzer wrote:
On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
On 10/02/2022 18:22, Peter J. Holzer wrote:
On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
Examples of small things Postgres could have:
• SELECT * - b.a_id from a natural join b
On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
> On 10/02/2022 18:22, Peter J. Holzer wrote:
> > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > Examples of small things Postgres could have:
> > >
> > >• SELECT * - b.a_id from a natural join b
> >
> > My use case for
On 10/02/2022 18:22, Peter J. Holzer wrote:
On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
Postgres has since the outset gone beyond the SQL standard in many ways :
types, inheritance, programmability, generality are all well beyond what SQL
used to mandate and still well beyond the current
On 2022-02-10 16:13:33 -0500, Bruce Momjian wrote:
> On Thu, Feb 10, 2022 at 06:25:45PM +0100, Peter J. Holzer wrote:
> > On 2022-02-10 18:22:29 +0100, Peter J. Holzer wrote:
> > > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > > • SELECT * - b.a_id from a natural join b
> > >
> > > My
On Fri, Feb 11, 2022 at 3:16 AM Ron wrote:
> On 2/10/22 10:33 PM, Raymond Brinzer wrote:
>
> The answer is obvious to every grey beard: SQL was developed from SEQUEL,
> Structured *ENGLISH* Query Language at a company that loved English-style
> programming languages.
>
> "SELECT column FROM
On 2/11/22 09:12, Mladen Gogala wrote:
On 2/11/22 09:48, Benedict Holland wrote:
So to summarize, people are bad programmers who refuse to learn SQL
So SQL is the problem? Common. You cannot bring that to a postgres
list serve.
Look. It's not perfect. It's a pain. It is hard to generate
On 2/11/22 09:48, Benedict Holland wrote:
So to summarize, people are bad programmers who refuse to learn SQL So
SQL is the problem? Common. You cannot bring that to a postgres list
serve.
Look. It's not perfect. It's a pain. It is hard to generate queries
(oh my God why are you doing this?)
So to summarize, people are bad programmers who refuse to learn SQL So SQL
is the problem? Common. You cannot bring that to a postgres list serve.
Look. It's not perfect. It's a pain. It is hard to generate queries (oh my
God why are you doing this?) and it's hard to work with. You are describing
On 2/10/22 23:56, Guyren Howe wrote:
On Feb 10, 2022, at 17:06 , Mladen Gogala wrote:
But SQL is a terrible, no good, very bad language.
I cannot accept such a religious persecution of SQL without a
detailed explanation.
I feel like anyone who is defending SQL here isn’t aware of how
> Give me a couple million bucks, and I’ll hire some of the Postgres devs
to build a new database.
> We could crib some of the low-level code from Postgres, but everything
above the low level would need to be rewritten.
You can check the EdgeDB experiments:https://www.edgedb.com/
*"What is
Peter J. Holzer wrote:
> > My use case for such a feature are tables which contain one column (or a
> > small number of columns) which you usually don't want to select: A bytea
> > column or a very wide text column. In a program I don't mind (in fact I
> > prefer) listing all the columns
On 2/10/22 10:33 PM, Raymond Brinzer wrote:
[snip]
Here's one that I think is simple: why would we want a language where the
clauses must come in a particular order? `FROM mytable SELECT column` is
as clear an expression as `SELECT column FROM mytable`, and probably
better, in that it starts
I get all this. Give me a couple million bucks, and I’ll hire some of the
Postgres devs to build a new database. We could crib some of the low-level code
from Postgres, but everything above the low level would need to be rewritten.
I was proposing more that we at least provide higher-level,
Raymond Brinzer writes:
> Will it be accepted here? I don't know; I'm not an insider, or in a
> position to say. But it'd be a much better pitch than a pep talk, or
> speaking in generalities about SQL. And that's coming from someone who
> actually agrees with you. I'm 100% on board with the
On Fri, Feb 11, 2022 at 12:26 AM Guyren Howe wrote:
> I’m not proposing some crackpot half-baked idea here. There are
> well-defined and researched alternatives to SQL.
>
I didn't suggest that you were. Anything which was written, someone had to
actually write.
> The most fully-developed
On Thursday, February 10, 2022, Guyren Howe wrote:
> On Feb 10, 2022, at 17:06 , Mladen Gogala wrote:
>
>
> But SQL is a terrible, no good, very bad language.
>
>
> I cannot accept such a religious persecution of SQL without a detailed
> explanation.
>
>
> I feel like anyone who is defending
I’m not proposing some crackpot half-baked idea here. There are well-defined
and researched alternatives to SQL.
The most fully-developed you-can-use-today offering is Datomic, which uses
Datalog as its query language. If you know Prolog, and how that is kind of
database-like, Datomic is
On Thu, Feb 10, 2022 at 11:56 PM Guyren Howe wrote:
> I feel like anyone who is defending SQL here isn’t aware of how much
> better the alternatives are, and how bad SQL really is.
>
Have you written a language description we can read and talk about?
--
Ray Brinzer
On Feb 10, 2022, at 17:06 , Mladen Gogala wrote:
>
>> But SQL is a terrible, no good, very bad language.
>
> I cannot accept such a religious persecution of SQL without a detailed
> explanation.
>
I feel like anyone who is defending SQL here isn’t aware of how much better the
alternatives
On Thu, Feb 10, 2022 at 5:51 PM Guyren Howe wrote:
> When you dig into it, the powerful idea here is the relational algebra,
> and its equivalence to a first-orderish logic.
>
> I put up with SQL so I can use relations, and I love Postgres because it
> has the least bad SQL (by a mile!)
>
> But
On 2/10/22 4:51 PM, Guyren Howe wrote:
[snip]
I don’t really understand why folks who love the relational model aren’t
perpetually up in arms about SQL being their only option. Much better
query languages are known and well studied.
Because it's Good Enough, and everyone with the wisdom of
Please, don't top-post.
On 2/10/22 17:51, Guyren Howe wrote:
When you dig into it, the powerful idea here is the relational
algebra, and its equivalence to a first-orderish logic.
I put up with SQL so I can use relations, and I love Postgres because
it has the least bad SQL (by a mile!)
As
On Thu, Feb 10, 2022 at 3:51 PM Guyren Howe wrote:
> But SQL is a terrible, no good, very bad language.
>
No, it's not. It is also not perfect.
I don’t really understand why folks who love the relational model aren’t
> perpetually up in arms about SQL being their only option. Much better
When you dig into it, the powerful idea here is the relational algebra, and its
equivalence to a first-orderish logic.
I put up with SQL so I can use relations, and I love Postgres because it has
the least bad SQL (by a mile!)
But SQL is a terrible, no good, very bad language.
I don’t really
This is a strange post. Why is SQL bad and how do your reconcile that with
managing 99%+ of all data? It's so bad that we have systems that plug into
sql to query data outside of tables like Athena or Excel.
Why are you not using pgadmin4? Yes. Psql as a command line isn't great for
humans. It's
On Thu, Feb 10, 2022 at 06:25:45PM +0100, Peter J. Holzer wrote:
> On 2022-02-10 18:22:29 +0100, Peter J. Holzer wrote:
> > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > • SELECT * - b.a_id from a natural join b
> > > □ let me describe a select list by removing fields from a
I’d like to point out that sum types would be great.
(Sum types let you have any of two or more different types in one value)
For example, I could work around the issues with NULL by defining an
enumeration type with values like MISSING, UNKNOWN, INVALID, … and then I can
have a column that is
On Thu, Feb 10, 2022 at 10:54 AM Merlin Moncure wrote:
> On Wed, Feb 9, 2022 at 11:15 PM Guyren Howe wrote:
>
>>
>>
>
>>- *Also nested function definitions, so top-level functions can be
>> built out of local auxiliary functions.*
>>- *Other languages*
>> - *Tutorial D,
On 2022-02-10 10:13:16 +0100, Karsten Hilbert wrote:
> Am Wed, Feb 09, 2022 at 09:14:39PM -0800 schrieb Guyren Howe:
> > There are huge developer benefits available to focusing
> > more on making a great relational programming environment,
> > well outside the SQL standard.
>
> There's a
On 2022-02-10 18:22:29 +0100, Peter J. Holzer wrote:
> On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > • SELECT * - b.a_id from a natural join b
> > □ let me describe a select list by removing fields from a relation. In
> > the example, I get all fields in the join of a and
On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> Postgres has since the outset gone beyond the SQL standard in many ways :
> types, inheritance, programmability, generality are all well beyond what SQL
> used to mandate and still well beyond the current standard.
>
> There are huge developer
On Wed, Feb 9, 2022 at 11:15 PM Guyren Howe wrote:
> Postgres has since the outset gone beyond the SQL standard in many ways :
> types, inheritance, programmability, generality are all well beyond what
> SQL used to mandate and still well beyond the current standard.
>
> There are huge developer
Am Wed, Feb 09, 2022 at 09:14:39PM -0800 schrieb Guyren Howe:
> There are huge developer benefits available to focusing
> more on making a great relational programming environment,
> well outside the SQL standard.
There's a seemingly small but conceptually rather significant
difference between
On Wed, Feb 9, 2022 at 10:15 PM Guyren Howe wrote:
> There are huge developer benefits available to focusing more on making a
> great relational programming environment, well outside the SQL standard.
>
Sure
>
> Examples of small things Postgres could have:
>
>- *SELECT * - b.a_id from a
49 matches
Mail list logo
