On Fri, Apr 26, 2024 at 2:25 PM Tom Lane wrote:
> Robert Haas writes:
> > No other programming language that I know of, and no other database
> > that I know of, looks at x.y.z and says "ok, well first we have to
> > figure out whether the object is named x or x.y or x.y.z, and then
> > after
On Fri, 26 Apr 2024 at 14:04, Robert Haas wrote:
systems have this problem. I wonder if anyone knows of another system
> that works like PostgreSQL in this regard (without sharing code).
>
In Haskell period (".") is used both to form a qualified name (module.name),
very similar to our
Robert Haas writes:
> No other programming language that I know of, and no other database
> that I know of, looks at x.y.z and says "ok, well first we have to
> figure out whether the object is named x or x.y or x.y.z, and then
> after that, we'll use whatever is left over as a field selector."
On Fri, Apr 26, 2024 at 12:54 PM Tom Lane wrote:
> But that's exactly the point: we DON'T consider the initial identifier
> of a qualified name "as a unit", and neither does the standard.
> We have to figure out how many of the identifiers name an object
> (column or table) referenced in the
Robert Haas writes:
> On Fri, Apr 26, 2024 at 12:15 PM Tom Lane wrote:
>> If I'm reading SQL99 correctly, they deny allowing the first
>> identifier to be a column name when there's more than one identifier,
>> so that you must table-qualify a composite column before you can
>> select a field
Robert Haas writes:
> On Fri, Apr 26, 2024 at 11:55 AM Tom Lane wrote:
>> Well, that would be one way of making the consistency problem be not
>> our problem, but it would be a sad restriction. It'd void a lot of
>> the arguable use-case for this feature, if you ask me. I realize
>> that
On Fri, Apr 26, 2024 at 12:15 PM Tom Lane wrote:
> > I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> > or better yet, a.b(args).c(args).d(args).e(args)?
>
> The former.
>
> ::=
>[ { }... ]
OK, nice.
> The hard part is to figure out what the
On Fri, Apr 26, 2024 at 11:55 AM Tom Lane wrote:
> Well, that would be one way of making the consistency problem be not
> our problem, but it would be a sad restriction. It'd void a lot of
> the arguable use-case for this feature, if you ask me. I realize
> that non-superusers couldn't create
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:51 PM Tom Lane wrote:
>> A different approach we could take is to implement the SQL99 rules
>> for , or at least move closer to that.
> I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> or better yet,
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:05 PM Tom Lane wrote:
>> What I'm trying to say is: given that the command "alter type T alter
>> attribute A type foo" exists, users would reasonably expect the system
>> to honor that on its own for any composite type, because that's what
>> it
On Thu, Apr 25, 2024 at 5:51 PM Tom Lane wrote:
> A different approach we could take is to implement the SQL99 rules
> for , or at least move closer to that. Our
> existing rules for resolving qualified column references are more
> or less SQL92. I think the reasons we didn't do that when we
On Thu, Apr 25, 2024 at 5:05 PM Tom Lane wrote:
> > I'm not sure I really buy this. Changing the column definitions
> > amounts to changing the on-disk format, and no data type can survive a
> > change to the on-disk format without updating the I/O functions to
> > match.
>
> What I'm trying to
I wrote:
> I could get behind offering an alternative notation, eg "a.b->c does
> the same thing as (a.b).c", if we could find a reasonable notation
> that doesn't infringe on user operator namespace. I think that might
> be hard to do though, and I don't think the existing notation is so
> awful
On Thu, 25 Apr 2024 at 17:05, Tom Lane wrote:
> > I think it's confusing and counterintuitive that putting parentheses
> > around a subexpression completely changes the meaning. I don't know of
> > any other programming language that behaves that way,
>
> I take it that you also don't believe
Robert Haas writes:
> On Thu, Apr 25, 2024 at 12:34 PM Tom Lane wrote:
>> Uh, no. My point is that if you make a custom output function
>> for "type complex (real float8, imaginary float8)", that function
>> will probably crash pretty hard if what it's handed is something
>> other than two
On Thu, Apr 25, 2024 at 12:34 PM Tom Lane wrote:
> Yes. We've heard that argument about "this only affects extensions
> that choose to use it" before, and it's nonsense. As soon as you
> extend system-wide APIs, the consequences are system-wide: everybody
> has to cope with the new definition.
Robert Haas writes:
> This thread caught my eye this morning, and I'm confused.
> On Thu, Apr 25, 2024 at 12:44 AM Tom Lane wrote:
>> The primary outcome would be to require a huge amount of new work
>> to be done by a lot of software, much of it not under our control.
> What, what is the "lot
This thread caught my eye this morning, and I'm confused.
On Thu, Apr 25, 2024 at 12:44 AM Tom Lane wrote:
> The primary outcome would be to require a huge amount of new work
> to be done by a lot of software, much of it not under our control.
What, what is the "lot of software" that would have
On Thu, Apr 25, 2024 at 10:14 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > I'm curious about composite types in PostgreSQL. By default, when we
> > create a composite type, it utilizes the "record_in" and "record_out"
> > functions for input/output. Do you think it would be beneficial to
> >
Dilip Kumar writes:
> I'm curious about composite types in PostgreSQL. By default, when we
> create a composite type, it utilizes the "record_in" and "record_out"
> functions for input/output. Do you think it would be beneficial to
> expand the syntax to allow users to specify custom input/output
Hi,
I'm curious about composite types in PostgreSQL. By default, when we
create a composite type, it utilizes the "record_in" and "record_out"
functions for input/output. Do you think it would be beneficial to
expand the syntax to allow users to specify custom input/output
functions when creating
21 matches
Mail list logo
